怎样设计并实现一个通用应用运维管控平台.docxVIP

UCLoud中国云三强: 如何设计并实现一个通用的应用运维管控平台 一、问题背景： 大部分的应用运维工作随着服务器数量和产品数量的增长而增加，而运维人数的不足导致单个运维人员所承担的工作任务较为繁重，同时运维工作的不标准、无自动化使得应用运维任务十分复杂，耗费的大量的人员成本、时间成本和沟通成本。 应用运维工作说白了大体可以分为两种情况：1. 在某个或某些服务器上执行某个脚本或命令；2.将某个或某些文件传输到某个或某些特定的服务器的特定位置上。在服务器数量较少的情况下，可以通过ssh或scp命令实现上面两个操作；服务器数量较多的情况下，我们可以通过包装ssh或者使用批量ssh工具，如pssh，ansible等来解决问题，但这种方式大多数都是一次性的方式，无论使用方法以及后续跟踪来看都并不友好。 还有，由于一系列历史原因，现网的服务环境也较为繁杂，现网的服务器上的代码、配置、软件包、脚本等文件没有进行统一的版本管理与配置管理，比如某个产品的代码版本多种多样；现网的代码和文件几乎都是通过一台复制到另一台的方式来实现；由于代码版本、配置版本等问题导致的现网质量事件也并不在少数。 另外，应用运维也需要一个统一的资源管理系统，对现网的服务的数据进行业务维度的资源管理，系统运维的CMDB系统只在静态资源维度进行了管控，动态的业务数据等资源需要应用运维团队自行来管理。 因此，针对上面所述的各种问题，需要一个运维管控系统，来解决包括：资源管理、配置管理、任务管理、文件发布等一些列常用的运维跟踪，通过简单高效、自动化的方式将繁琐的应用运维工作通过管控系统来完成，即可以降低运维的难度，也可以提高运维的效率，同时可以提高运维操作的成功率，并实现运维任务的持续跟踪和管理，甚至在不远的将来可以实现移动运维。 二、功能结构： 经过上述的分析和整理，我们将整个管控平台的功能细化到如下几个大功能，如图所示： 、 三、详细设计： 这里围绕上面功能结构图中的4个大功能，进行详细的分析和设计，其中移动运维功能为附加功能，这里暂时不介绍。 3.1 资源管理 先说资源管理，资源管理是一切后续自动化运维功能的前提，也是所有自动化功能的数据依赖。 资源管理的功能可以较为薄弱，但是对数据的要求比较高，可以基于系统运维的CMDB系统进行二次构建，主要的功能可以分为： 物理机资源管理：物理机资源管理功能，需要将CMDB中所有交付到应用运维的物理机资源进行重新整理，按照二级业务产品线进行管理，支持多种服务器状态（如部署中，备用池等等）标注。可以基于物理机资源管理系统进行服务器初始化管理操作，加快服务初始化部署工作的效率。物理机资源管理对于后续的配置管理和作业管理来说是尤为重要的，是后续两个功能的数据基础。 管理虚机资源管理：所有的管理服务都部署在管理虚机上，因此我们也需要对管理虚机进行管理，管理虚机的数据和物理机资源管理一样，可以依赖系统运维的CMDB中的数据进行二次管理，功能和物理机资源管理类似，这里不再阐述。 虚拟资源管理：虚拟资源管理就是在每一台物理机上的虚拟机/业务DB的资源管理，可以基于业务管理数据库中的数据进行二次整合，或者通过数据采集上报的方式实现，尽可能的做到虚拟资源数据的有效性和状态一致性。 虚拟资源数据在进行后续的虚拟资源管理、虚拟资源迁移等功能上会有较大帮助，可以基于虚拟资源管理完成自动化的实例迁移工作，节省大量的手动实例迁移任务。另外虚拟资源管理对宕机恢复或机房、机架断电等问题也会有较大的帮助。 整个资源管理比较简单，可以优先完成物理机资源管理功能，再实现虚拟资源管理功能。 3.2 作业管理 作业管理是应用运维管控系统的核心功能，也是应用运维工作中经常使用到的功能，作业管理功能也可以分为如下子功能，如图所示： 下面将分别对上面几个子功能进行详细介绍： 1. 脚本执行： 脚本执行和文件分发是整个作业功能的基础功能，其他的功能都是通过对着两个功能进行组装和装饰来实现的。 脚本执行的表现形式就是运维人员在页面中提交一个脚本，脚本建议支持shell和python两种形式，可以通过三种方式： 1）手动书写；也就是在页面上的编辑器中编写脚本； 2）上传脚本；也就是通过浏览器将本地的脚本上传到系统中； 3）克隆系统脚本；所谓的系统脚本就是运维人员通过上面两个步骤提交到系统中的脚本，可以分为基础系统脚本和用户系统脚本，基础系统脚本就是那些我们明确可能会多次执行的脚本，比如服务器初始化等脚本；用户系统脚本就是用户自定义的脚本，可以实现任何功能。 脚本的编写要依赖一定的语法规范，我们可以为shell和python语言提供基础的类包和函数库，同时所有的脚本的执行结果都会根