共计 6739 个字符，预计需要花费 17 分钟才能阅读完成。
转自 @twt 社区【作者：王洋】
前言
当你把自动化运维这个话题抛给不同的角色，他们的反馈也肯定是不一样的，程序员眼中的自动化运维可能是能够自助申请资源，能够点点点的进行利用公布；利用运维人员眼中的自动化运维可能是主动的监控每个利用的状态有简略的问题就依照约定的动作去自愈，简单的问题告诉给我，我去解决或者是过期的日志清理等；根底资源运维人员眼中的自动化运维可能是硬件服务的自助零碎装置，主动的环境初始化，垃圾文件清理等。
这些了解都没有错，然而这些都是一个一个的点，没有造成一个整体，没有从方法论的角度去了解自动化运维，去建设自动化运维，那么明天咱们就来谈一谈我眼中的自动化运维是什么？
一、自动化运维是什么？你是不是有什么误会？
开篇的时候说了对于不同的人眼中的自动化运维意味着什么，这些了解站在点的角度上或者说站在非领导的角度上了解都是没有问题的，然而如果作为一个运维方面的领导了解仅仅了解到以上层面那就有点欠缺了，在我看来至多是不足了更为形象的了解，短少了实践的反对。
咱们先抛开这个短少的实践不说，在运维畛域，有人会说，运维经验了人肉化，脚本化，主动运维工具以及平台化几个阶段（图一），这个说法有错吗？也没有。然而细心地你会发现，这里提到的演化过程还是一个纵向的演化过程，说白了是通过技术的更新来推动运维的后退， 而且这样的演化过程很容易让人陷入技术实现的细节，不能跳进去从宏观的角度剖析自动化运维到底该做什么？不该做什么？边界在哪里？
接下来我就说下我了解的自动化运维的方法论或者说形象的实践应该是什么，大家认真回忆开篇提到的场景，无论是开发想要的资源自助申请，主动公布，还是运维项要的主动装机、自助初始化环境以及故障的自愈等，还是咱们从立项开始通过需要剖析，具体设计，编码，测试，运维，经营，反馈等，这些咱们都是在干嘛？对了，咱们都是在做端到端的交付！
接下来再想，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，咱们才可能将其代码化，从而自动化，否则很多场景还是解脱不了人工手动解决的困境，人工参加的场景越多，出错的概率也就越大，间隔现实的自动化运维也就越远。
六、总结
本文从五个方面对自动化运维做了一个介绍，其中很多场景也是笔者依据实践经验对一线互联网公司和传统行业的做法进行了比照论述。最初，我再强调一下我认为的自动化运维的实践外延和内涵： 对于非业务的功能性需要，在提供端到端交付的过程中可能尽量的全自动化。
