第 1 章 绪论
1.1 论文的研究及背景
随着计算机软件的飞速发展，各行各业对软件的需求量也越来越大，因此，IT行业的运维服务也显得尤为重要。当 IT 应用系统突然发生故障的时候，将对我们带来毁灭性的打击[1]。例如自百度发生运维故障之后，微软 Azure 也遭受了一场突如其来的运维灾难，因此使得应用软件能否稳定运行已经成为影响一个行业至关重要的因素。
1.1 论文的研究及背景
随着计算机软件的飞速发展，各行各业对软件的需求量也越来越大，因此，IT行业的运维服务也显得尤为重要。当 IT 应用系统突然发生故障的时候，将对我们带来毁灭性的打击[1]。例如自百度发生运维故障之后，微软 Azure 也遭受了一场突如其来的运维灾难，因此使得应用软件能否稳定运行已经成为影响一个行业至关重要的因素。
因此，在我们享受 IT 行业所给我们带来的各种便利的同时，IT 系统的正常运转也显得尤为的重要。不过目前各行各业对应用软件已经投入了越来越大的成本于后期的运维中。但是，却一直让人担忧他的稳定性和可维护性[2]。为此，中国电信、中国移动等许多家通信行业也都纷纷为运维监控服务做成出了许多尝试，并取得了一定的成果。
纵观运维管理工作的发展流程与现状，现阶段还有许多的运维工作是通过人工方式处理的模式来完成的。该模式早已无法满足运维的高标准要求，同时手工操作将给运维人员带来大量繁琐、重复的工作，运维技术人员也将为此付出大量低效甚至无效劳动。而且也有大量事实表明许多安全事件均由人工操作不当引发。因此，许多运维风险并没有得到根本性的解决。而且许多运维工作并没有一套集中性的管理方案，从而进一步增加了技术人员的工作量。因此，该阶段的运维工作对人员工作量的消耗巨大，一套规范、统一、流程化的运维管理手段显得尤为重要。为尽量弥补人工管理方式的缺点，迫切需要一款运维管理平台协助运维人员完成运维管理工作[3,4]。
纵观运维管理工作的发展流程与现状，现阶段还有许多的运维工作是通过人工方式处理的模式来完成的。该模式早已无法满足运维的高标准要求，同时手工操作将给运维人员带来大量繁琐、重复的工作，运维技术人员也将为此付出大量低效甚至无效劳动。而且也有大量事实表明许多安全事件均由人工操作不当引发。因此，许多运维风险并没有得到根本性的解决。而且许多运维工作并没有一套集中性的管理方案，从而进一步增加了技术人员的工作量。因此，该阶段的运维工作对人员工作量的消耗巨大，一套规范、统一、流程化的运维管理手段显得尤为重要。为尽量弥补人工管理方式的缺点，迫切需要一款运维管理平台协助运维人员完成运维管理工作[3,4]。
近年来，已有大量的运维管理平台应运而生。但是，大多数运维管理平台仅仅实现了对单一服务器或服务器所部署的应用服务的监控，对于一些需要监控的具体项目来说，缺乏一定的针对性和系统性。而且，近年来随着互联网产品的不断普及，各种应用系统及用户数量的不断增多，对服务器资源合理有效的利用成为了当今比较关注的话题之一，目前的运维管理平台很少能够实现对各种应用系统的合理部署与调度，从而未能使服务器、网络等资源得到有效利用。
.......................
1.2 国内外研究现状及发展趋势
1.2.1 国内研究现状
目前，国内已有了许多公司开始投入到 IT 运维工作中，但由于技术等原因，许多运维平台仍处于有待提高阶段。不过，总结我国运维管理的来龙去脉，可以将其分为如下 4 个阶段。该 4 个阶段的发展状况如图 1-1 所示。
1.2 国内外研究现状及发展趋势
1.2.1 国内研究现状
目前，国内已有了许多公司开始投入到 IT 运维工作中，但由于技术等原因，许多运维平台仍处于有待提高阶段。不过，总结我国运维管理的来龙去脉，可以将其分为如下 4 个阶段。该 4 个阶段的发展状况如图 1-1 所示。
由图 1-1 可以看出，在第一阶段几乎全部的运维工作均靠运维人员人工完成，而且没有一套制度化的运维管理方案，即在此阶段不仅运维人员的工作量消耗巨大，工作效率也非常低下，而且大量的运维等问题频繁出现。到了第二阶段已经逐渐意识到了前期运维工作中的问题，许多制度化的运维管理方案开始逐渐出现，使得运维管理工作的效率逐渐好转。随着第二阶段的不断发展，以及运维管理制度的不断完善，到了第三阶段之后已基本形成了制度化的运维管理方案，受运维人员的影响程度已逐渐减小。但是，此阶段运维管理工作的应变能力显得有待提高。发展到了第四阶段后计算机开始成为了 IT 运维的一部分，从而使得计算机运维管理平台得到了不断快速的发展。
纵观我国运维平台的发展现状，目前我国也出现了一些比较成熟的运维平台，比较熟知的有监控宝、阿里云监控、盛大云监控、运行宝等。其中监控宝是一款为用户提供 IT 性能监控的产品，包含了网站监控、基础设施监控（硬件及网络）、应用服务性能监控、平台 API 健康检查及监控、业务平台性能测试及诊断等功能。阿里云推出的云监控（CloudMonitor）可实现对阿里云资源以及互联网应用的监控，根据监控指标和监控数据，还可以实现警报等功能。盛大云监控是盛大云计算推出的一款针对互联网的自助运维监控产品，也提供了多种运维监控服务。例如当服务器发生故障时，该监控平台能够及时以发送邮件或短信报警的方式反馈给运维管理人员。除此之外，目前我国还出现了许多其他的运维监控平台，而且也都表现出了各种各样的优缺点。
..........................
图 2-1 中 xml 资源配置文件包含了所需要采集的应用的名称和采集周期。在该运维数据采集过程中，需要首先读取并解析该 xml 资源配置文件，然后根据 pid 实现对该应用（或服务器）运维数据的采集[6]。之后将采集到的运维数据以及采集时间、应用 id 等信息封装成 Json 格式，通过 Http 实现对该数据的上报。完成每次数据的上报后根据 xml 资源配置文件中的数据采集周期 T 进行下一周期数据的采集与上报。
该数据采集 SDK 需运行于每个需要监控的服务器上，为减少该 SDK 对服务器资源的占用，本课题在设计该 SDK 时尽量减少了对服务器资源的消耗，使该 SDK对服务器资源的影响程度几乎很小。
.......................
2.2 运维数据上报设计
常用的通信方式包括 Http、TCP、UDP 等，在不同类型的数据通信中都表现出了各自的优点[7,8-10]。该平台将采集到的运维数据封装成 Json 的形式，采用 Python中 urlib 模块 Http 通信方式实现了对运维数据的上报。该平台运维数据上报的技术路线图如图 2-2 所示。
平台在数据上报之前，运维数据采集程序需首先读取一次服务器资源配置文件并解析，获取该服务器及所需采集的应用 id 作为所上报的运维数据字符串中数据 id字段，然后程序将实时获取数据采集的日期（年月日）和时间（时分秒），连同所采集到的运维数据封装成 Json 格式通过 Http 方式上报至平台的运维数据上报接口[11]。在上报的过程中，本文采用 Post 请求方式实现了数据采集 SDK 与平台服务端运维数据上报接口的交互。
........................
第 2 章 运维数据采集与上报设计
2.1 运维数据采集
SDK 设计 根据教学直播系统实际业务需求，确定了此运维管理平台所需要采集的运维数据类型包括服务器和应用的在线状态、服务状态、内存使用情况、CPU 利用情况、网络发送流量、网络接收流量等。其中，“应用”是指在该教学直播系统在运行的过程中所需要占用的 tomcat、数据库管理系统等服务资源及其他所需要占用的应用服务资源等。
本文利用 Python 中 psutil 模块设计了一套运维数据采集 SDK，实现了对上述运维数据的采集[5]。psutil 作为 Python 的一个模块，全称为 process and system utilities，是一个跨平台的库，可较好的用于检索有关运行进程和系统的资源利用信息，在系统监控、流量等运维资源监控等方面得到了很好的应用。本文利用该模块设计了一套运维数据采集 SDK，其技术路线图如图 2-1 所示。
2.1 运维数据采集
SDK 设计 根据教学直播系统实际业务需求，确定了此运维管理平台所需要采集的运维数据类型包括服务器和应用的在线状态、服务状态、内存使用情况、CPU 利用情况、网络发送流量、网络接收流量等。其中，“应用”是指在该教学直播系统在运行的过程中所需要占用的 tomcat、数据库管理系统等服务资源及其他所需要占用的应用服务资源等。
本文利用 Python 中 psutil 模块设计了一套运维数据采集 SDK，实现了对上述运维数据的采集[5]。psutil 作为 Python 的一个模块，全称为 process and system utilities，是一个跨平台的库，可较好的用于检索有关运行进程和系统的资源利用信息，在系统监控、流量等运维资源监控等方面得到了很好的应用。本文利用该模块设计了一套运维数据采集 SDK，其技术路线图如图 2-1 所示。
图 2-1 中 xml 资源配置文件包含了所需要采集的应用的名称和采集周期。在该运维数据采集过程中，需要首先读取并解析该 xml 资源配置文件，然后根据 pid 实现对该应用（或服务器）运维数据的采集[6]。之后将采集到的运维数据以及采集时间、应用 id 等信息封装成 Json 格式，通过 Http 实现对该数据的上报。完成每次数据的上报后根据 xml 资源配置文件中的数据采集周期 T 进行下一周期数据的采集与上报。
该数据采集 SDK 需运行于每个需要监控的服务器上，为减少该 SDK 对服务器资源的占用，本课题在设计该 SDK 时尽量减少了对服务器资源的消耗，使该 SDK对服务器资源的影响程度几乎很小。
.......................
2.2 运维数据上报设计
常用的通信方式包括 Http、TCP、UDP 等，在不同类型的数据通信中都表现出了各自的优点[7,8-10]。该平台将采集到的运维数据封装成 Json 的形式，采用 Python中 urlib 模块 Http 通信方式实现了对运维数据的上报。该平台运维数据上报的技术路线图如图 2-2 所示。
平台在数据上报之前，运维数据采集程序需首先读取一次服务器资源配置文件并解析，获取该服务器及所需采集的应用 id 作为所上报的运维数据字符串中数据 id字段，然后程序将实时获取数据采集的日期（年月日）和时间（时分秒），连同所采集到的运维数据封装成 Json 格式通过 Http 方式上报至平台的运维数据上报接口[11]。在上报的过程中，本文采用 Post 请求方式实现了数据采集 SDK 与平台服务端运维数据上报接口的交互。
........................
3.1 平台需求分析 ······························ 13
3.2 平台业务架构与模块设计 ····················· 15
第 4 章 资源调度与方案评估模型设计 ·················· 27
4.1 运维资源关联规则挖掘模型设计 ··················· 27
4.1.1 资源利用情况关联规则挖掘模型设计 ··········· 27
4.1.2 运维资源时间关联规则挖掘模型设计 ··················· 30
第 5 章 资源调度与方案评估模型实验测试 ······················· 41
5.1 直播系统简介与实验环境选取 ··················· 42
5.2 资源关联规则挖掘实验测试与分析 ··························· 42
第 5 章 资源调度与方案评估模型实验测试
5.1 直播系统简介与实验环境选取
本文实验所用服务器的主服务站包括用户登录、轮奖、中奖、中心交换、batch交换、系统任务服务、房间服务等多个功能模块组成。上述功能模块可能多台服务器中，这些服务器通过内网完成通信，且对 CPU、内存等资源占用并不是很明显，因此，本文对模型的测试实验并未选取上述主服务站进行实验。
本文实验所用服务器的主服务站包括用户登录、轮奖、中奖、中心交换、batch交换、系统任务服务、房间服务等多个功能模块组成。上述功能模块可能多台服务器中，这些服务器通过内网完成通信，且对 CPU、内存等资源占用并不是很明显，因此，本文对模型的测试实验并未选取上述主服务站进行实验。
该教学直播系统的音视频服务对资源的利用需求较高，而且 与用户数量等因素关联性较强。该业务系统音视频服务中共包含了 Domain 域服务器和 Media 媒体服务器。其中域服务器部署于阿里云服务器中，本文实验不将其作为参加调度的应用进行实验。该系统的媒体服务器中分为了电信媒体服务器、联通媒体服务器、移动媒体服务器和其他代理服务器，本文采用了联通媒体服务器中的业务功能作为了拟参加调度的应用，对其进行了实验测试。选取了分别部署不同应用（调度前对 CPU、内存、带宽利用不同）的 8 台服务器作为参加该应用调度的服务器，完成了对本文资源调度与方案评估模型的实验测试。
...........................
第 6 章 工作总结与下一步规划建议
6.1 本文主要工作总结
随着互联网应用产品的不断普及，为提高运维工作的效率，减少运维人员的工作量，提高对服务器 CPU、内存及网络带宽等资源的利用率，本课题以教学直播系统作为业务系统，设计并实现了一款运维管理平台，本课题的主要研究内容包括如下方面。
（1） 运维数据采集 SDK 与上报协议涉及 该课题选取了 CPU 利用率、内存使用情况等几种需要采集的运维数据指标，设计了一套运维数据采集 SDK，实现了对运维数据的采集。本文设计了一套统一的数据上报协议，将运维数据信息封装成了 Json 格式，通过 Http 方式完成了运维数据的上报。
（2） 运维管理平台设计与实现 本课题设计并实现的一套教学直播系统运维管理平台。本文对平台进行了功能架构设计、模块设计、数据存储中间件设计等设计工作，平台按照“高内聚、低耦合”的设计思想对平台进行了功能模块设计，采用 SOA 架构完成了平台的架构设计，通过 My SQL 数据库管理系统实现了对平台基础数据的存储与管理，采用 Mongo DB 实现了对运维历史数据的存储与管理，通过Redis 完成了对运维实时数据的缓存管理。平台将所有业务逻辑封装到了后台接口中，采用 SSM 框架实现了后台接口的开发。
（3） 资源调度与方案评估模型设计 为提高对服务器及带宽等资源的利用率，本课题利用历史运维数据，设计了一套资源调度与方案评估模型。模型首先通过 Apriori 算法实现了对服务器和预调度应用运维数据的关联规则挖掘，根据关联规则挖掘结果改造了资源调度预选模型和资源调度决策模型，实现了资源调度方案的设计。为提高调度方案的可行性，设计了一套资源调度方案评估模型，在调度方案执行前实现了对调度方案可行性的评估。本文所设计的资源调度模型实现了对业务资源的调度，提高了服务器 CPU、内存以及网络带宽等资源的利用率。
参考文献（略）
...........................
第 6 章 工作总结与下一步规划建议
6.1 本文主要工作总结
随着互联网应用产品的不断普及，为提高运维工作的效率，减少运维人员的工作量，提高对服务器 CPU、内存及网络带宽等资源的利用率，本课题以教学直播系统作为业务系统，设计并实现了一款运维管理平台，本课题的主要研究内容包括如下方面。
（1） 运维数据采集 SDK 与上报协议涉及 该课题选取了 CPU 利用率、内存使用情况等几种需要采集的运维数据指标，设计了一套运维数据采集 SDK，实现了对运维数据的采集。本文设计了一套统一的数据上报协议，将运维数据信息封装成了 Json 格式，通过 Http 方式完成了运维数据的上报。
（2） 运维管理平台设计与实现 本课题设计并实现的一套教学直播系统运维管理平台。本文对平台进行了功能架构设计、模块设计、数据存储中间件设计等设计工作，平台按照“高内聚、低耦合”的设计思想对平台进行了功能模块设计，采用 SOA 架构完成了平台的架构设计，通过 My SQL 数据库管理系统实现了对平台基础数据的存储与管理，采用 Mongo DB 实现了对运维历史数据的存储与管理，通过Redis 完成了对运维实时数据的缓存管理。平台将所有业务逻辑封装到了后台接口中，采用 SSM 框架实现了后台接口的开发。
（3） 资源调度与方案评估模型设计 为提高对服务器及带宽等资源的利用率，本课题利用历史运维数据，设计了一套资源调度与方案评估模型。模型首先通过 Apriori 算法实现了对服务器和预调度应用运维数据的关联规则挖掘，根据关联规则挖掘结果改造了资源调度预选模型和资源调度决策模型，实现了资源调度方案的设计。为提高调度方案的可行性，设计了一套资源调度方案评估模型，在调度方案执行前实现了对调度方案可行性的评估。本文所设计的资源调度模型实现了对业务资源的调度，提高了服务器 CPU、内存以及网络带宽等资源的利用率。
参考文献（略）