本文摘要：一、问题背景：大部分的应用于运维工作随着服务器数量和产品数量的快速增长而减少，而运维人数的严重不足造成单个运维人员所分担的工作任务更为艰巨，同时运维工作的不标准、无自动化使得应用于运维任务十分复杂，花费的大量的人员成本、时间成本和交流成本。应用于运维工作说白了大体可以分成两种情况：1．在某个或某些服务器上继续执行某个脚本或命令；2．将某个或某些文件传输到某个或某些特定的服务器的特定方位上。

一、问题背景：大部分的应用于运维工作随着服务器数量和产品数量的快速增长而减少，而运维人数的严重不足造成单个运维人员所分担的工作任务更为艰巨，同时运维工作的不标准、无自动化使得应用于运维任务十分复杂，花费的大量的人员成本、时间成本和交流成本。应用于运维工作说白了大体可以分成两种情况：1．在某个或某些服务器上继续执行某个脚本或命令；2．将某个或某些文件传输到某个或某些特定的服务器的特定方位上。在服务器数量较较少的情况下，可以通过ssh或scp命令构建上面两个操作者；服务器数量较多的情况下，我们可以通过纸盒ssh或者用于批量ssh工具，如pssh，ansible等来解决问题，但这种方式大多数都是重复使用的方式，无论用于方法以及先前追踪来看都并不友好关系。还有，由于一系列历史原因，现网的服务环境也更为繁复，现网的服务器上的代码、配备、软件包、脚本等文件没展开统一的版本管理与配置管理，比如某个产品的代码版本多种多样；现网的代码和文件完全都是通过一台读取另一台的方式来构建；由于代码版本、配备版本等问题造成的现网质量事件也并不在少数。

另外，应用于运维也必须一个统一的资源管理系统，对现网的服务的数据展开业务维度的资源管理，系统运维的CMDB系统只在静态资源维度展开了管控，动态的业务数据等资源必须应用于运维团队自行来管理。因此，针对上面所述的各种问题，必须一个运维管控系统，来解决问题还包括：资源管理、配置管理、任务管理、文件公布等一些佩常用的运维追踪，通过非常简单高效、自动化的方式将繁复的应用于运维工作通过管控系统来已完成，即可以减少运维的可玩性，也可以提升运维的效率，同时可以提升运维操作者的成功率，并构建运维任务的持续追踪和管理，甚至在不远处的将来可以构建移动运维。二、功能结构：经过上述的分析和整理，我们将整个管控平台的功能细化到如下几个大功能，如图所示：三、详细设计：这里环绕上面功能结构图中的4个大功能，展开详尽的分析和设计，其中移动运维功能为可选功能，这里继续不讲解。

3．1资源管理再行说道资源管理，资源管理是一切先前自动化运维功能的前提，也是所有自动化功能的数据倚赖。资源管理的功能可以更为脆弱，但是对数据的拒绝较为低，可以基于系统运维的CMDB系统展开二次建构，主要的功能可以分成：1、物理机资源管理：物理机资源管理功能，必须将CMDB中所有交付给到应用于运维的物理机资源展开重新整理，按照二级业务产品线展开管理，反对多种服务器状态（如部署中，可用池等等）标示。

可以基于物理机资源管理系统展开服务器初始化管理操作者，减缓服务初始化部署工作的效率。物理机资源管理对于先前的配置管理和作业管理来说是尤为最重要的，是先前两个功能的数据基础。

2、管理虚机资源管理：所有的管理服务都部署在管理元神机上，因此我们也必须对管理虚机展开管理，管理虚机的数据和物理机资源管理一样，可以倚赖系统运维的CMDB中的数据展开二次管理，功能和物理机资源管理类似于，这里仍然阐释。3、虚拟世界资源管理：虚拟世界资源管理就是在每一台物理机上的虚拟机／业务DB的资源管理，可以基于业务管理数据库中的数据展开二次统合，或者通过数据采集请示的方式构建，尽量的做虚拟世界资源数据的有效性和状态一致性。

本文来源：南宫28圈官网-www.kubernetek.com