迈向智能化运维的第二步：自动化运维

企业数字化转型，科技先行。国际知名咨询机构如麦肯锡、埃森哲、IDC、IBM等，都在解读数字化定义时提及智能化运营。但要实现智能化，我们还有很长的路要走。

运维部门作为企业科技部门的一部分，在信息化时代的今天，所承受的压力日益渐增。传统的运维模式越来越难以适应业务和IT架构的扩张，运维团队需要寻求突破，来跟上企业变化的步伐。通常来说，企业的运维管理体系分为规范化运维、自动化运维、敏捷化运维和智能化运维四个阶段，其中规范化运维到自动化运维的过渡阶段是大多数企业所在阶段。

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

01. 自动化运维的定义

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

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

自动化运维并不是孤立建设和运行的，笔者认为自动化运维是ITOM中的一部分，如下图。

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

02. 自动化运维的分类

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

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

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

2. 面向应用的自动化

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

3. 面向业务的自动化

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

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

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

03. 自动化运维的组织模式

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

1. 组织模式一：分散式

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

2. 组织模式二：集中式

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

3. 组织模式三：平台式

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

平台式的组织模式对技术平台的基础功能和核心框架要求之高，让很多企业望而却步，苦于难以找到合适的技术平台，自研开发又极不现实。嘉为蓝鲸数据中心运维自动化解决方案，是基于强大的腾讯蓝鲸PaaS平台，通过作业平台（作业执行能力）、配置平台（CMDB）、管控平台（海量接入管控）、集成平台（开放与集成能力）、标准运维（灵活调度编排引擎）等能力，帮助企业实现从资源交付上线、巡检维护、日常变更及批量操作、安全管理等各种自动化运维的场景。