关于自动化运维的那些事儿

随着近年全球运维大会的火热举办，自动化运维话题被推向了前所未有地热度。自动化运维并不是炒作的概念，而是随着信息技术发展的必要趋势。“大数据”“容器”“DevOps”“微服务”……，不断涌现出新的技术，而它们都有共同的特点，大大增加了运维管理的操作单元数量的同时对系统可用性有更高的可用性要求。从IBM、BMC、HP等传统厂商各类工具产品纷纷面市到Puppet、Ansible、Saltstack等开源解决方案风起云涌，自动化运维已经势不可挡。

一、 自动化运维的定义

什么是自动化运维？很多人尝试给自动化运维下定义，“数据中心自动化（DCA）”、“开发运营一体化（DevOps）”……，始终无法形成被统一认可的概念。这里笔者对Garter对自动运维的定义进一步引深：“通过运维工具或平台，实现IT基础设施及业务应用日常任务处理和运维流程的自动化，从而提高效率和降低风险，促进运维组织的成熟和各种能力的升级”，其中：

• 日常任务处理包括：设备发现、脚本执行、操作系统安装、配置备份、配置检查、配置变更、补丁分析和分发、作业调度等
• 运维流程包括：应用发布流程、应用部署流程、变更流程、故障处理流程、灾备切换流程、资源交付流程等
• 能力升级包括：变化适应能力、风险应对能力、合规遵从能力、业务运营能力、事件应对能力等

自动化运维并不是孤立建设和运行的，笔者认为自动化运维是ITOM中的一部分，如下如。“自动化”、“配置管理”、“监控”是运维管理建设的三驾马车，三者之间即相互独立，也相互联系。笔者在走访很多企业交流过程中，很多人认为这三者之间存在着依赖关系，一定要先落地其中一个才能建设另外一个。这种理解是片面的，三者的建设路径并没有严格的先后顺序，最好的做法的共同建设，共同迭代。

二、 自动化运维的分类

我们常听到面向业务的监控或者面向应用的监控，笔者认为自动化也是一样的，可以区分为“面向基础架构的自动化”、“面向应用的自动化”、“面向业务的自动化”。三个分类既有一定的关联性，也是相互独立的，有着各自的目标和场景。

1）面向基础架构的自动化

这里基础架构主要指的是IASS和PAAS这两层。面向基础架构的自动化运维是相对比较容易落地建设的，往往自动化运维也是从基础架构这个类别开始建设的。这个类别的自动化建设的主要目标是解放运维人员的工作量，如把运维工作中的日常巡检、补丁管理、资源创建等内容实现自动化、自助化。

2）面向应用的自动化

顾名思义面向应用的自动化的对象就是以应用为单位，应用中包含了各类的基础架构资源。然而面向应用的自动化并不依赖于基础架构自动化完全落地之后才能建设，在笔者为某单位落地自动化运维时，迈出的第一步就是核心应用系统的更新部署自动化，当时还没有任何基础架构层面的自动化。当然也不是说应用的自动化完全不依赖基础架构，如自动缩扩容、自动部署与配置等对基础架构的自动化程度有较强的依赖性。

3）面向业务的自动化

面向业务的自动化是IT自动化的最终目标，归结到底IT还是为业务提供服务。如果能够将IT自动化建设与业务关联起来，IT服务的价值也能很好的体现出来。当然，面向业务的自动化也有非常高的建设难度，对业务流程、业务关联性的系统化梳理往往不是IT部门能够独立完成的。

很多企业都在探索自动化运维应该怎样开展，目前仍然没有形成相对权威的自动化运维建设路线图。笔者结合“面向基础架构的自动化”、“面向应用的自动化”、“面向业务的自动化”的理念，以及过往的项目经验，妄自菲薄的为自动化运维总结一个成熟度模型，如下图。这个层级图表达了一种迭代建设的理念：每部分内容建设都不是一蹴而就的，各部分内容建设也不是强依赖关系。同时笔者认为自动运维的建设的初期应该从下面两点出发：

• 优先考虑可以立即产生影响的工具，如那些解决重复性工作或冗余性的自动化工具；
• 衡量自动化应该关注：提高维护效率、降低风险或提高敏捷性。

三、自动化运维的组织模式

很多公司都在招聘或培养DevOps工程师，组建自己的自动化运维团队，每家企业的组织思路都不一样。回归本质思考自动化运维并不神秘，与ERP、OA、监控一样都是一套软件系统，同样存在“需求提出者”、“软件开发者”、“最终使用者”，将这三者由谁去扮演是自动化运维组织模式的关键。笔者借鉴工行侯志荣《一体化一体化和自动化运维体系探索》一文中的观点，在企业自动化运维建设的组织模式，大致有如下几种情形：

组织模式一：分散式

由各领域、各部门根据需求自行建设，“需求提出者”、“软件开发者”、“最终使用者”都是同一组人。这种自给自足的建设方式没有统一规划，可能使用不同的技术站，也会出现重复建设。很难形成合力，各自为营的局面往往会产生维护成本高，也可能会带来生产系统稳定性风险。

组织模式二：集中式

这是一种中央集权的组织方式，独立组织一组人员投入自动化运维建设，其他团队作为需求提出者提出需求。这种模式可以统一规划和设计，也相对更专业。但集中式的组织模式不容易调动其他团队的积极性，繁杂的运维需求很难准确收集，无法快速应对不断变化的运维需求。

组织模式三：平台式

这种模式综合了分散式和集中式的特点，组织一个团队负责自动化基础平台建设，各域、各部门根据需求自行在平台上开发工具。既可以发挥多方的积极性，又可以形成统一的合力，较好兼顾了个性和共性。但这种平台式的组织模式对平台本身的建设提出了极高的要求，平台本身要求能够提供统一架构、统一认证、统一调用，并且实现自动化工具的敏捷和快速迭代。

平台式的组织模式对技术平台的基础功能和核心框架要求之高，让很多企业望而却步，苦于难以找到合适的技术平台，自研开发又极不现实。往往一些拥有大量的DevOps工程师的大型互联网企业才采用这种组织方式。好消息是腾讯已经将自己的蓝鲸智云平台开放、开源出来，腾讯蓝鲸是一个非常强大的自动化运维Paas平台，有兴趣做自动化运维的朋友就快点去下载体验吧

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。