今天和大家聊一聊自动化运维这个话题，当你把自动化运维这个话题抛给不同的角色，他们的反应也一定是不一样的，程序员眼中的自动化运维可能是可以自助申请资源，可以点点点的进行应用发布；应用运维人员眼中的自动化运维可能是自动的监控每个应用的状态有简单的问题就按照约定的动作去自愈，复杂的问题通知给我，我去处理或者是过期的日志清理等；基础资源运维人员眼中的自动化运维可能是硬件服务的自助系统安装，自动的环境初始化，垃圾文件清理等，这些理解都没有错，但是这些都是一个一个的点，没有形成一个整体，没有从方法论的角度去理解自动化运维，去建设自动化运维，那么今天我们就来谈一谈我眼中的自动化运维是什么？

一、自动化运维是什么？你是不是有什么误解？

开篇的时候说了对于不同的人眼中的自动化运维意味着什么，这些理解站在点的角度上或者说站在非领导的角度上理解都是没有问题的，但是如果作为一个运维方面的领导理解仅仅理解到以上层面那就有点欠缺了，在我看来至少是缺乏了更为抽象的理解，缺少了理论的支持，我们先抛开这个缺少的理论不说，在运维领域，有人会说，运维经历了人肉化，脚本化，自动运维工具以及平台化几个阶段（图一），这个说法有错吗？也没有。但是细心地你会发现，这里提到的演化过程还是一个纵向的演化过程，说白了是通过技术的更新来推动运维的前进，而且这样的演化过程很容易让人陷入技术实现的细节，不能跳出来从宏观的角度分析自动化运维到底该做什么？不该做什么？边界在哪里？

图一 

接下来我就说下我理解的自动化运维的方法论或者说抽象的理论应该是什么，大家仔细回想开篇提到的场景，无论是开发想要的资源自助申请，自动发布，还是运维项要的自动装机、自助初始化环境以及故障的自愈等，还是我们从立项开始通过需求分析，详细设计，编码，测试，运维，运营，反馈等，这些我们都是在干嘛？对了，我们都是在做端到端的交付！接下来再想，it系统建设是干嘛的，是为业务服务的，也就是说业务系统实现了业务功能就能带来收益，大家才有饭吃，那么问题就简单了，最简单的场景是系统架构设计好了以后所有的工作都围绕业务实现来投入，其他的非功能性需求（这里没有说非功能性需求不需要）投入的人力越少越好！到此，自动化运维理论的内涵和外延都有了，那就是：对于非业务的功能性需求，在提供端到端交付的过程中能够尽量的全自动化（图二）。

图二 

最近很火的service mesh在微服务领域就有点这个意思，今天我们不是主要讲service mesh，这里先不展开。

二、自动化运维落地的实践基础

我们在第一个章节里交待清楚了什么自动化运维理论的内核和外延，下面开始接地气的谈一谈要想落地自动化运维理论，需要有什么样的基础或者说如何才能更好的落地自动化运维理论。笔者曾工作于国内某一线互联网公司，同时也是传统行业工作过，切身体会到抛开技术架构和人员能力不谈，一线互联网公司的自动化运维比传统行业好的不是一个量级，笔者对整个问题进行过思考，得到的结论是：一线互联网公司对端到端交付的自动化运维理念落实的很到位，而促使他们很好落实端到端交付的自动化运维理论的主要抓手有三个：一是对既定规范的绝对遵守；二是所有资源的抽象化；三是各种标准化（图三）。

图三 

下面分别介绍一下这三点：

一是对既定规范的绝对遵守，在一线互联网公司，运维团队在接手开发的系统时，会有一个准入的等级要求，这个要求是对开发提的，例如你要满足我的哪些要求，我才会给你提供相应的运维保障，这里的要求有业务系统重要性等级说明、业务系统运行时间说明、业务系统不能依赖低等级的业务系统、业务系统不能有单点故障等，因为在运维团队看来，你只有符合我不同的要求，对我而言对你实现端到端的自动化运维保障难度也是不同的。例如，一个非常重要的业务系统，可是开发有很多单点故障问题都没有解决，很多健康检查监控都没有实现，那么我运维不可能破坏游戏规则，单独为你一个系统做特殊高等级的保障，来耗费我的人力资源，甚至后续的背锅风险。绝大多数情况下，开发都会按照既定规范来遵守游戏规则，对于非要玩特殊化的，那也很简单，两边老大pk。有了规范，对于运维团队而言只需要针对固定数量的保障等级准备相应的自动化运维手段就可以，而避免的过多的个性化需求。

二是资源的抽象化，一线互联网公司很多物理资源都是抽象化表示的（编码化），例如机房名字、不同硬件配置的服务器。这样的好处一方面便于记忆，另一方面统一了术语大家在交流的时候不容易出错，最重要的是抽象表示后很对运维场景也变的简单的。这里的抽象对于很多传统行业的同学可能不太理解，我在这里举几个例子，例如一个在上海的联通机房，他的命名可能是cnshu01，简单解释下，cnsh代表中国上海，u代表是联通，01代表编号；再举一个例子，我们在传统行业购置硬件服务器的时候，可能是每次根据需求不同选好硬件配置后再选品牌，在互联网公司一般会首先对服务器的用途进行分类，例如计算密集型，内存密集型，io密集型等，针对每种会有一个编码，例如C42代表计算密集型，这样的好处是需要使用机器的部门只需要将自己需要机器的编码和数量发给采购部门就行了，别的就不用关心了。资源编码化还有一个好处是当需要用程序来管理资源的时候，编码化最容易处理。

三是各种标准化，每个公司都会面临一个软件版本管理的问题，从操作系统版本到软件版本参差不齐，不同的软件版本在运维时还是有一些差别的，在一线互联网公司对于软件的版本一般会有比较严格的一致性要求，尤其是生产环境，过一段时间的软件版本升级工作其实也促使了自动化运维的发展，试想如果没有高效的自动化运维保障，每升级一次操作系统或者软件版本都是一项巨大的工程，恰恰是这样相互促进的关系，当整个公司都使用统一的操作系统版本和软件版本时，很多工作的难度就降低了。另外，一线互联网公司还对操作系统的目录结构（主要是指linux操作系统）有着标准化的要求，目录结构标准化的好处是无论谁来处理问题，都能根据标准化的路径到达目的地，找到自己所需的内容。综上所述，既定规范的绝对遵守、资源的抽象化和标准化，是落地端到端自动化运维交付的有力抓手。

三、自动化运维和流程管控

这一部分，我们来聊下自动化运维与流程管控的关系。我们知道，运维工作中的任何一个需求的执行都是有相应的流程在进行管控的。如果自动化运维的动作没有流程来进行管理，那么自动化做了哪些运维工作，为什么要做这些运维工作，是谁做了这些运维工作，对于管理员来说如果都不知道或者不可查，那就太恐怖了。ITIL的规范里面也对流程管控有很详细的描述，但是根据笔者了解到的情况，在实际企业中，尤其是业务变化比较快的企业能够完全按照ITIL流程来的还真是少只又少，ITIL流程还是比较重的，针对ITIL流程做裁剪来适合企业自身情况这才是正确的方式。在流程管控方面，传统行业无论是用了ITIL还是没有用的，目前都存在以下几个问题：

一是流程不完善，即流程还是欠缺的不能完全覆盖所有场景；
二是流程完善了，但是没有全部系统化；
三是流程完善了，系统化也有了但是流程没有串起来，还都是一些孤立的点。

以上三种场景都很难对流程做出较强的管控，好的流程管控，应该这样做：

第一步结合工作的实际情况梳理出我们需要做流程的场景，这一步可以首先让每位同事把自己认为需要做流程管控的场景梳理出来，作为总的一个需求池，然后通过开会讨论的方式将需求进行合并或者是去重，经过这样一个过程，产出物是一个需要做流程管控的文档；

第二步针对第一步梳理出来的文档，标注出每一个流程中最关键的点，这个点称之为要素点。例如新购机器上架这个流程里，包括送达机房，签收，上架前准备，上架并加电，更新已上架设备信息等几步，在这个流程中，上架并加电是最核心也是对后续实际使用最有影响的一步，那么这一步就成为要素点；

第三步就是针对第一步梳理出的流程，找到流程之间的衔接点，这也是为了解决流程孤岛的问题。在这一步中如果发现有不能连接在一起而断层的流程，就需要在这一步解决。

第四步就是系统实现了，这一步无论是自研实现还是外包实现，都需要考虑的一点是如何与现有的自动化运维系统以及资源管理系统进行对接，因为流程的管控过程肯定会涉及资源的生命周期管理，这里的资源可以是实实在在的物理资源，例如服务器、防火墙、路由器和交换机等，也可以是软件资源，例如安全策略，4/7层的负载均衡等，这样的流程管控平台就涉及到与cmdb、云平台和容器平台等的对接工作，这一步一般是比较消耗精力的，倒不是说这里的技术难度有多难，而是这里一般都涉及接口的调试工作，如果这些系统都是自研的系统，那对接起来的难度可能还低些，毕竟都是自己公司的团队，如果涉及到与外购系统的对接，这里的时间周期就很难控制了，根据笔者经验，这里如果是与外购系统对接，每个系统最好预留1个月的时间。

第五步就是流程管控平台上线后的与自动化运维平台磨合和优化的阶段了。在这个阶段，要留意观察自动化运维平台、资源平台与流程管控平台的数据交互是否正常，这里可以引入敏捷迭代的方式来及时处理问题（图四）。

图四 

四、实现自动化运维常用的工具对比分析

各位看官，在这个阶段我主要介绍下实现自动化运维工具的三种理念，为了严谨期间说明下这个环节说的自动化运维工具是要是指x86服务器层面。实现自动化运维工具的三种理念：

第一种是完全自研，例如阿里巴巴集团的所有物理机上都安装有一个久经考验并且功能强大的代理staragent，阿里巴巴集团所有物理机在系统初始化的时候就安装了这个staragent，直到生命周期结束，这个startagent才会被卸载。这里有个问题就是，不是所有的公司都能像阿里巴巴一样自研一个功能非常强大的agent，因此就有了第二种和第三种理念。

第二种理念是使用市面上已有的自动化运维工具，并基于这些工具做成自动化运维平台。目前市面上常见的自动化运维工具主要有以下几种，Puppet、Chef、Ansible和Salt，下面对四种产品做一个对比介绍：

Puppet应该是市面上使用最多的，就操作、模块、界面而言，它是最全面的，Puppet呈现了数据中心协调的全貌，为各大操作系统提供了深入的工具，初始设置简单，只是需要加以管理的每个系统上安装客户端代理软件，CLI简单直观，允许通过puppet命令下载和安装模块，你可以对配置文件进行需要的修改，让模块适合所需的任务，接到指令的客户端与主服务器联系时，会更改配置文件，也可以是客户端主动与服务端通信来获取到最新的配置文件，还有一些模块可以提供和配置云服务器实例和虚拟服务器实例，所有模块和配置都使用基于Ruby的Puppet专属语言或者Ruby本身构建而成，因而除了系统管理技能外，还需要编程专业知识。

Chef的总体概念类似Puppet，因为在被管理的节点上安装代理软件，但实际部署又不一样。除了主服务器外，安装的Chef环境还需要工作站来控制主服务器。代理软件可以借助使用SSH来部署的knife工具从工作站加以安装，减轻了安装负担。被管理的节点通过使用证书，完成与主服务器之间的验证。与Puppet一样，Chef得益于一大批的模块和配置菜谱，那些模块和配置菜谱又高度依赖Ruby。由于这个原因，Chef非常适合注重开发的基础设施。

Ansible极其类似Salt，而不太类似Puppet或Chef，Ansible关注的重点是力求精简和快速，而且不需要在节点上安装代理软件也可以选择安装。Ansible能通过SSH执行所有功能，Ansible基于Python开发对于熟悉python的人而言是一大福音，并且是由红帽进行运营。Ansible可以从命令行来运行，不需要使用配置文件。至于比较复杂的任务，Ansible配置通过名为Playbook的配置文件中的YAML语法来加以处理。Playbook还可以使用模板来扩展其功能，目前playbook的模板还是非常丰富的。

Salt类似Ansible，因为它也是基于CLI的工具，采用了推送方法实现客户端通信。它可以通过Git或通过程序包管理系统安装到主服务器和客户端上，客户端会向主服务器提出请求，请求在主服务器上得到接受后，就可以控制该客户端了。这四款自动化运维工具网上的比较很多，但是很难说谁就一定比谁好很多，还是那句话，你的团队具有哪方面的人才就使用哪个，如果非要选出一个我个人推荐ansible，因为基于python实现，开发人员比较好找，同时社区资源活跃，相关的资源和组件也是比较丰富的。

第三种思路是采购市面上商用的自动化运维平台，这种思路对于很多甲方公司还是很现实的一种方案。对于这种思路，需要采购方切实梳理清楚自身的需求，整理出自己真实需要的自动化运维场景。这里的建议是，在选择商用自动化运维平台时和平台销售方协商好以下三件事，一是甲方结合实际工作中遇到的自动化运维场景，把需要马上满足的自动化运维场景梳理出来，作为第一个模块，即确定要完成的功能模块；二是要求平台销售方提供自动化运维工具的编写接口，并支持shell和python两种语言，这个要求是考虑到后续有些运维场景开始没有考虑到，或者新增了一些场景，自己的人员可以自行通过编写脚本在这个平台上实现；三是要求平台销售方对于产品层面积累的已有的运维场景实现要提供给采购方，并且支持后续当产品有新运维场景更新时，要免费提供给采购方使用。

五、云平台的自动化运维该是什么样的

目前云平台还是比较热的一个话题，最后这个章节主要来聊下私有云iaas和paas平台的自动化运维该是什么样的。先说iaas平台，iaas平台主要涉及计算、存储、网络、安全这四大块（图五）。

图五 

计算资源应该是分为几种固定的规格（计算密集型/io密集型/内存密集型），这些规格由开发和运维团队协商定制。没有特殊情况下，无论是谁申请都不会新增新的机型，同时计算资源无论是开发人员自助申请，还是开发人员通过运维人员申请，申请完以后系统的初始化环境应该是已经自动完成的，这里的初始化环境包括并不限于IP地址、内核参数、文件目录结构、计算机名称、磁盘卷挂载等。

存储资源，要能够做到容量预警和扩容提醒，当触发容量预警需要扩容时能够通知到存储管理员，同时存储管理员提出扩容需求和方案后可以通过流程平台通知到存储采购人员，并进行采购动作。在存储资源的服务能力方面，最佳情况是同时具备块、文件和对象存储能力，这样才能满足云环境下的应用需求，尤其是对象存储现在越发受到重视，笔者举一个小例子，由于经过前面的标准化要求，每台云主机的文件目录结构都是统一的，那么当应用程序需要进行文件操作的时候，使用基于S3协议的对象存储就很方便，免去了通过nfs或者smba进行盘挂载的方式，使用nfs或者smba进行挂载的方式会额外增加运维人员的维护成本，并且差异化也是与自动化运维的标准化理念相违背的。实际情况是，笔者发现现在很多传统行业还是在使用nfs挂载的方式把文件提供给应用程序使用，其中的痛苦大家也都体会过，所以现在也开始逐步进行迁移改造工作。

网络资源，理想的iaas云平台网络资源首先要能够提供多种虚拟网络设备，例如路由器、交换机、4/7层防火墙、4/7层负载均衡和ip资源池管理等，其次这些虚拟网络设备不但要能够在管理界面创建，同时还要能够支持api调用，能够通过代码进行管理。

安全资源，云平台上的安全资源主要是指安全组能力（防火墙放在了网络资源里），通过安全组可以将不同租户的主机进行隔离，在小公司甚至可以通过安全组在一个云平台上隔离出来测试环境、预部署环境和生产环境，这样就大大降低了基础设施的成本。

在paas平台方面，根据笔者实际经验，目前主要是两块应用的比较多：一块是基于容器和ci/cd进行狭义的devops流程来适配当下很火爆的敏捷开发；另外一块是提前定制好一些中间件资源（这里主要是消息队列、缓存、分布式锁等），来供开发人员直接使用，这些中间件资源可以是基于虚拟机定制好的模板，也可以是基于容器技术制作好的镜像。无论是iaas平台的自动化运维还是paas平台的自动化运维，要想实现自动化，各个资源类型提供相应的api是必不可少的，只有提供了api，我们才能够将其代码化，从而自动化，否则很多场景还是摆脱不了人工手动处理的窘境，人工参与的场景越多，出错的概率也就越大，距离理想的自动化运维也就越远。

六、总结

本文从五个方面对自动化运维做了一个介绍，其中很多场景也是笔者根据实践经验对一线互联网公司和传统行业的做法进行了对比阐述。最后，我再强调一下我认为的自动化运维的理论内涵和外延：对于非业务的功能性需求，在提供端到端交付的过程中能够尽量的全自动化。欢迎大家后续交流。