前言

近几年来，随着云计算、大数据、人工智能技术的高速发展，DevOps、AIOps等新文化、新理念的冲击，几乎所有企业的信息技术部门都在谋求变革，不仅仅是为了跟上技术潮流，更是为了能适应随着业务而一起发展的IT系统的运维复杂度和体量，有的走的比较靠前的企业信息部门甚至完成了从支撑业务到引领业务、技术输出的转型。在这场席卷全球企业的变革中，自动化运维体系建设就是非常重要且基础的一部分内容。

在日语中“动”与“働”是两个不同的汉字，发音和意义都不相同。“动”是直接从中文引进的，“働”则是日本造的汉字，主要用于工业工程领域。自働化是让设备或系统拥有人的"智慧"。当被加工零件或产品出现不良时，设备或系统能即时判断并自动停止。通过"自働化"改善的设备或系统，可以达到两个目的，一个是不生产不良品（实现零缺陷），即用简便的机械替代人的劳作,减轻作业强度,提高工作效率;另一个是可以节省监控设备运行的看护人（实现省人化）,既异常发生时的自动停机功能。

自动化所表达的只是设备自动运转，如果为了防止设备故障、外观破损、不良品产生等，则需要有专门的作业者负责监视；而自働化是有人字偏旁的,强调的是人机最佳结合,而不是单单的用机械代替人力的自动化。所以，"自働化"与一般意义上的自动化不一样。
笔者认为，我们需讨论的自动化运维，实际上应该称之为“自働化”运维，整个体系里面，人的作用，或者说运维专家的作用，在目前的技术背景下是不可或缺的。但为了表述和理解方便，下文仍以自动化表述。

针对自动化运维平台，已经有许多技术专家撰文专门论述，其中大部分内容偏重于平台建设本身。而自动化运维体系则不仅仅包括自动化运维平台，还包括与之结合紧密的企业运维管理制度、运维专家的作用、运维流程的演进等内容，仅仅完成平台建设是不足以达到自动化运维的目标的。

本文将以某大型金融企业自动化运维平台建设为例，结合管理制度、企业文化和未来发展方向，与读者一同探讨自动化运维体系的建设。

1、自动化运维体系综述

一个相对完整的自动化运维体系中至少应包括三类平台或功能组件：自动化变更平台、监控平台、数据平台（CMDB）。另一方面还需要包括一个契合企业实际的管理体系。这四个组成要素缺一不可。如果将自动化体系比作一个健康的人体的话，那么这四要素可以分别比作如下几个组织和器官：

手：自动化变更平台。变更平台是触发变更的工具和平台，它代替运维人员行使变更的职责，如同人手进行的工作，它会实实在在影响企业的业务系统和基础平台；

眼：监控平台。这是一个容易被忽视的建设要素，许多人会认为它和自动化无关，其实不然。深入思考一下，我们的变更动作实际上只有两类来源：业务需求和自身稳定性要求。前者的变更结果需要得到反馈需要监控平台的介入，而后者则能清楚明白地告诉变更平台或运维专家有什么变更可能需要去完成。

血液：CMDB。自动化体系里面数据的流动是前面二者准确交互的前提，而CMDB就承载了这一任务，就好比人体中的血液，健康而充足的血液是各器官运转正常的前提。

神经系统：管理体系。俗话说，事在人为。管理体系的配套建设，就是一个自动化体系是否能保持运转高效的核心。另一方面，许多人认为自动化是双刃剑，它能带来便利也可能带来灾难。一套契合企业实际的管理体系，能将这柄双刃剑当做单刃刀来发挥作用。

下文将结合企业实际，围绕这四个要素进行阐述。

就笔者所在企业而言，直接的建设需求有如下方面：
A.同时满足系统自动化运维和应用自动化运维两部分内容；（笔者注：系统运维指操作系统、数据库、中间件等基础环境运维；应用运维指应用系统的部署和发布）
B.同时适应标准化和非标准化两类变更;
C.支持多个操作系统平台，包括LINUX\UNIX\WINDOWS;
D.可由运维专家灵活定制运维流程；
E.变更平台需要具备4A系统的特点，即集中认证（Authentication）管理、集中账号（Account）管理、集中权限（Authorization）管理和集中审计（Audit）管理。

非功能需求有如下方面：
A.高可用。不仅仅是自动化平台本身提供的服务需要高可用，其执行通道，即平台与生产服务器之间的命令通道也必须是高可用；
B.对外提供API或服务总线式的接口，以便更好地与其他运维系统，如CMDB相融合。

2、自动化运维的手：自动化变更平台

2.1 代理选择

自动化变更平台，目前有saltstack、puppet、ansible等一些开源软件能很好地完成自动化变更任务，对于一些中小企业而言，采用这些软件并进行一些定制化开发是最直接、简单的建设方式，能极大地缩短平台建设周期，降低建设成本。但对于一些大型企业而言往往不采用这些开源软件，而采用自研代理的方式进行建设，主要有如下原因：

A.开源软件的不确定性。在变更系统中采用开源软件，如遇到问题，则必须要解决，而解决的途径往往是通过开源社区（企业能投入大量精力研究源码除外）。这种将变更平台稳定性和开源社区热度变相捆绑在一起的方式，对于大型企业一般是不能接受的，变更平台是企业的手，必须保持绝对可用。
B.大型企业里操作系统种类较多，大部分开源软件对不同操作系统的支持并不完整。如要全部支持，势必要进行一些改造，或者采用两种以上的不同开源软件，在顶层自行封装。
C.开源软件提供的UI或功能页面往往不能满足大型企业的需求。在此情况下，企业要么全新针对其代理接口自研一套前端，要么在其基础上进行代码开发。无论采用哪种方式，其建设成本都是很高的。

笔者所在企业的自动化变更平台项目组，以java语言为基础，自研了一套适配所有主流操作系统的代理，作为自动化变更平台的命令通道，经验证，命令执行并发数量可以达到2000以上。而文件传输通道，仍旧采用FTP的方式进行，可以满足目前的需求。当然，如果企业大量采用容器化技术，大规模文件分发场景就成为一种必然，自动化变更平台就需要重新考虑文件传输通道的选择了，阿里巴巴自研的DragonFly（蜻蜓）就是一款比较优秀的基于P2P的文件分发系统，已经开源（https://github.com/alibaba/Dragonfly），有兴趣的读者可以自行深入研究。

2.2 CaaS—Change as a Service(变更即服务)的探索

一如前文需求所述，自动化变更平台需要同时满足系统运维和应用运维的需要，项目组对该情况进行了深入的分析，并做了大量的行业调研，发现这两类变更有如下四个特点：

A.都是基于操作系统的变更，系统运维一般采用的是高权限操作系统用户，应用运维则一般是低权限用户。
B.多数情况下都需要在多个节点上批量执行，而执行的范围一般会根据实际情况有调整。例如，针对某部分节点的重启和整个集群的重启。
C.都由多个变更步骤组成，例如系统安装某个补丁需要分为环境检测、安装、完成度检测等步骤，应用部署需要分为停止服务、程序包部署、启动服务、验证等步骤。
D.较难将这些变更提炼成少数几套固化下来的变更流程，尤其是在非标准化还大量存在的情况下。

针对上述四个特点，我们提炼出一套可由用户，即运维专家进行自主变更流程定制的功能框架。概括而言，有如下特点：

A.从主机衍生出来的变更节点。变更节点是在主机的基础上添加了操作用户、节点属性两类新特性的全新概念。添加操作系统用户主要是为了区分执行角色，例如linux环境的系统管理员使用root账号执行变更，而应用运维人员采用非root账户。
B.应对非标准化的节点属性。节点属性可定义可不定义，在平台后端以KEY-VALUE的数据形式存放。设计这个属性的初衷是为了应对非标准化的情形。例如，软件安装路径在不同节点上不一致，就可以定义一个软件安装目录（app_directory）的属性，其值就是该节点上软件的绝对路径，这样就可以通过脚本对同一属性名称的引用，来完成对所有节点中软件安装目录的遍历。当然，如果路径都统一，这些个性化属性就可以不定义，直接存放在统一脚本中。非标准化情况越多，需要定义的属性内容就越多，我们通过这种形式变相地鼓励运维人员去尽量地完成标准化工作。
C.原子化的流程步骤。我们约定，每个步骤里只放置一个功能上尽可能单一的脚本，选择对应的节点（含属性）与其绑定，组成变更流程的基本单元之一。原子化的好处很明显，就是易于理解、维护和更新。另外，我们还将人工审核、确认等操作步骤也定义为可选的变更流程基本单元，以提高变更流程的灵活度。下图展示了一个用于启动应用的流程步骤。

D.基于BPMN2.0规范的图形化流程编排。目前业界大部分的变更流程引擎都是串行流程，无法适应并行流程等复杂情况，且没有图形化界面很不方便。我们发现主要是为业务流程服务的BPMN2.0的规范很符合我们的需求，因此项目组基于此自研了一套拖拽式的图形化流程编排界面，结合前面提到的节点和脚本定义，可以应对绝大部分的变更场景。例如，给一款应用所在的服务器进行操作系统补丁升级的流程图如下所示：

这套功能框架非常灵活，但极大地依赖于运维专家的深度使用。节点、脚本、流程的定制全部需要用户来完成。但该项工作属于一次性工作，且可以交由专门的专家工作小组来完成。提前定义变更流程不仅仅意味着将变更动作在真正执行前固化下来，更便于审批和复核；更意味着可以将运维动作定义为服务（CaaS），由除定义服务以外的人员(如ECC值班人员)或其他系统（如AIOPS）调用。
当然，项目组也基于此预定义了一些常用的变更流程，例如常用软件的部署、单节点或集群的临时重启流程等。

3、自动化运维的血液：CMDB和数据

CMDB的全称是配置管理数据库，CMDB是IT架构中设备的各种配置信息，与服务支持和交付流程紧密相连。CMDB应该是整个运维体系中最底层的数据库，它包含服务器信息、业务信息、机房信息等，与其他的系统相关联，上层的系统变更信息反馈到CMDB中，其他的系统能够获取这份变更并对自己再进行更新。

CMDB建设几乎是所有企业IT建设的难点，人人都知道CMDB数据重要，但就是建设不好，数据不准、不全，使用起来有难度等。笔者认为主要有如下两个原因：

A.数据是死数据，没有流动起来，导致数据准确性下降。通过管理手段施加压力不是一个确保数据准确性的好方法。
B.数据模型没有跟随企业实际而更新。
就自动化运维体系而言，并不是所有CMDB中的信息都需要用到。例如，一个应用变更流程是不需要知道其服务器所在的机柜、机房信息的，但应用系统包括哪些主机，其操作系统类别和版本号是什么，却是需要的。反过来说，自动化运维体系中各个平台会产生一些配置项，这些数据可以同步到CMDB供其他系统共享。例如，应用系统的版本号、各类基础软件的版本号、运维人员的服务器权限集等。

因此，我们期望能建设一个“联邦式”的CMDB，各类运维平台都从中获取自己无法产生的数据，但同时又将自己产生的数据同步到CMDB中。这样一来，由于各个运维平台直接面向生产，在使用平台时，用户有维护数据准确性的动力，CMDB的整体数据质量也会因此得到提升。

本小节我们讨论的配置项范围不包括应用系统配置本身，应用配置和其他配置相比有其特殊性，不适合放在CMDB中管理。淘宝中间件专家坤宇撰文详细描述了这一概念及其管理方式和管理平台（http://jm.taobao.org/2016/09/28/an-article-about-config-center/），可参阅。

4、自动化运维的神经系统：管理体系

抛开平台建设而言，要让自动化运维体系高效运转，一个能持续改进的管理体系是十分必要的。许多企业现有的运维管控流程是是基于ITIL开发的，往往长时间不进行更新。在自动化运维普遍替代传统人工运维的背景下，一些管控流程实际上可以被优化。那么优化的指导原则又是什么呢？笔者认为，可以归纳为一句话：仅让需要审核的步骤被最适合审核的人审核，且不断根据实际优化或在可控范围内勇于试错。

例如，变更具体内容被平台固化了，其内容的审批实际上就应该前置到固化之前，而执行审批就可以将审批注意力集中在实施时间、关联变更上。再比如，一些常规的紧急变更，往往要经过层层审批，而这些审批动作几乎是清一色的“同意”，那么审批就没有存在的必要了，反而会在时间上阻碍变更的执行。自动化平台在数据上可以给审批者提供类似风险分级的参考，以便进行管控流程的优化。

从系统建设层面，流程管理平台实际可以和变更、监控平台将部分功能集成到一起。例如，可以将事务类步骤和运维步骤结合到一个复合流程中予以展现。下图是一个常规告警触发变更自愈的流程界面：

此外，自动化运维体系还需要增设一些人员角色。

A.专家审核团队：脚本在高度共享化以后，其准确性就不应该全部由其撰写人来承担责任了，而应该有专门的专家团队来审核脚本的准确性和安全性。例如，weblogic有关的脚本应由组织内中间件团队进行审核，甚至直接由其编写通用脚本模板。
B.平台建设团队：自动化平台建设是一件及其复杂且耗费精力的事情，而且需要持续地改善，不是一竿子买卖。如有专业团队来承建、优化、推广，会使得建设历程更为顺畅。
C.标准化团队：传统企业里往往有着沉重的历史包袱，有大量的技术债需要清偿。纳管新的资源、应用时，也需要建立特定的标准才能“放行”，这些工作是繁杂且耗时的。完成这些工作，让运维对象统一易于管理，是一件人人都认为很有必要，但人人都望而却步的事情，因为这类工作往往不能有亮眼的、直接的成果物，此时就需要领导层的理解和支持了。

5、自动化运维的眼：监控平台

自动化运维体系是一条集监、管、控一体的能力链，而其中监控告警是其中的基础环节，监控本身也需要形成对故障的采集、处理、发现、定位、解决的一个闭环。定位和解决这两个环节，以往依赖于人工，而今自动化变更平台和AIOPS平台也越来越多地承担了这部分工作。

从事过监控平台建设的读者可能有体会，监控平台建设是会随着IT组织结构、基础架构演进、业务应用架构发展而需要不断投入的项目。目前一个完备的企业监控平台包括了操作系统、日志、安全、中间件、数据库、网络、应用等不同维度的监控范畴。一次生产故障的产生可能会在许多范围出现互相呼应的告警信息。

笔者认为，建设一个精准、高效的监控平台，应注意如下几点：

A.只提供有效告警信息。这意味着要在告警信息归并、告警阈值范围、告警指标设定方面进行持续不断地改进，确保有告警则必须要处理，有故障则必须有告警。
B.提供API或其他类型接口供CMDB\自动化变更平台调用，避免监控平台成为一个信息孤岛。
C.将平台建设为半自助式的用户模式，以充分调动运维人员，即监控平台用户参与监控平台建设的积极性和主动性。平台开发只是其中一个方面，更多的时候定义监控指标、调整告警阈值等工作也需要完成，这些工作需要系统和应用知识，全部交由平台开发人员完成往往会得不到很好的效果。

6、自动化运维和DevOps、AIOps的关系

一言以蔽之：自动化运维的实现，是DevOps和AIOps的前提条件之一。

DevOps其本质上是一种文化，强调自动化一切可以自动化的过程，而在这些过程里，环境部署、应用部署、部署反馈等都依赖于自动化运维，没有实施好自动化运维，DevOps只能是纸上谈兵。反过来说，自动化运维做好了，DevOps也不见得能完全成功，涉及到组织、工具、流程、文化的变革，非本文重点，此处不再赘述。

AI近两年如火如荼，几乎每个企业都在深入研究机器学习等AI相关技术的落地应用。AIOps作为运维从业者绕不过去的话题，也被许多企业技术部门纳入建设范围。笔者曾就此向华为云BU副总裁朱照生先生请教过建设思路，其表示AI理论上适用的场景有三类：效率提升、专业传承、突破极限。就AIOps而言，效率提升和专业传承是比较符合实际的实施目标，同时，深度学习这个时下最热门的的机器学习分支，实际上并不适合于运维场景。因此，可以在积累专家运维数据的同时，进行一定范围内的专家决策模型输入，并进行优化。例如，一次故障发生后，AIOps可根据同类型历史专家的运维恢复记录进行快速尝试恢复。这就意味着需要将专家运维数据进行结构化记录，这时自动化运维的必要性就体现出来了。

结语：自动化运维的初心：用尽可能少的投入更好地服务好企业

不忘初心，方得始终。自动化运维可以提高运维效率、安全、适度降低成本，但业务实际上期望远不止这些，业务功能的快速、稳定上线，迅速占领市场先机才是企业所需要的。需要运维和研发部分深度配合实施DevOps才能实现这一目标。作为运维人，先踏实做好自动化运维等于为其铺平了道路。

技术永远在更新换代，而信息建设的初衷永远没有变：服务和带动业务发展。自动化运维体系建设也是一样，每个企业的情况都各不一样，没有一种通用技术或解决方案可以适用所有企业情况，使用一门新技术前要深刻理解其技术含义、使用场景，不能人云亦云。企业也需要根据自身已有技术实力、技术投入、未来建设目标来选择自己的建设路线