自动化运维三大基础及常用工具对比自己申请资源，点点滴滴发布应用；应用运维人员眼中的自动化运维，可以自动监控每个应用的状态。如果有简单的问题，按照约定的动作自愈，复杂的问题通知我，我去处理或清理过期日志等；在基础资源运维人员眼中，自动化运维可能就是硬件服务的自助系统安装、环境自动初始化、垃圾文件清理等。这些理解没有错，但是这些都是一点一点的，没有形成一个整体，没有从方法论的角度理解和构建自动化运维，所以今天我们就来说说我眼中的自动化运维。什么是维度？1、什么是自动化运维？你有什么误解吗？文章开头我说了自动化运维对于不同的人意味着什么。从领导的角度理解是没有问题的，但是运维一个领导的理解如果只理解以上几个层次，就有点欠缺了。在我看来，至少它缺乏更抽象的认识，缺乏理论知识。支持。让我们把这个缺失的理论放在一边。在运维领域，有人会说运维经历了人性化、脚本化、运维工具自动化、平台化几个阶段（图1）。这个说法有错吗？？也不。但是如果你仔细看，你会发现这里所说的演化过程仍然是一个纵向演化过程。说白了就是通过技术的更新来推动运维的进步，而这样的演进过程很容易让人陷入技术实现的细节之中。跳出来从宏观角度分析自动化运维应该做什么？不应该做什么？边界在哪里？图1下面说说我所理解的自动化运维的方法论或者抽象理论。大家仔细想想开头说的场景，是自己要开发的资源的自助申请和自动释放，还是运维项的自动安装，自助初始化环境，自愈故障等，或者我们通过需求分析从项目入手。设计、编码、测试、运维、运营、反馈等等，我们在做什么？对了，我们都是做端到端的交付！接下来想想它的系统建设是为了什么？业务服务，也就是说，业务功能实现了，业务系统才能带来收益，大家都能吃饭，所以问题就简单了。最简单的场景就是系统架构设计好后，所有的工作都围绕业务实现展开。投入，其他非功能需求（这里不是说非功能需求不需要），投入的人力越少越好！至此，自动化运维理论的内涵和外延已经得到，即：为非业务功能提供端到端交付的过程，以实现全自动化（图2）。图2最近流行的ServiceMesh在微服务领域就有这个意思。今天我们主要讲的不是ServiceMesh，这里就不展开了。2.实施自动化运维的实践基础。在上一章中，我们讲清楚了自动化运维理论的核心和外延是什么。下面开始讲自动化运维理论的实现需要什么样的基础。或者如何更好的贯彻自动化运维的理论。笔者曾就职于国内一线互联网公司，也曾在传统行业工作。我个人体会到，无论是技术结构还是人员能力，一线互联网公司的自动化运维都比传统行业好不了一个数量级。思考问题后得出的结论是，一线互联网公司对端到端交付的自动化运维理念落地的非常好，推动他们落地自动化运维理论的主要有3点端到端交付和维护：首先是绝对遵守既定规范；二是所有资源的抽象；三是各种标准化（图3）。下面图3分别介绍了这三点：第一，绝对遵守既定规范。在一线互联网公司，运维团队接手开发的系统时，会有一个级别的接入要求。这个需求是为了发展，比如你要满足什么要求，我会给你相应的运维保障。这里的需求包括对业务系统重要性级别的描述，对业务系统运行时间的描述，以及业务系统不能依赖底层业务系统。系统不能有单点故障，因为站在运维团队的角度，你只要满足我不同的要求，而对我来说，你实现端到端的自动化运维是不同的保证。比如一个很重要的业务系统，但是在开发中有很多单点故障问题没有解决，很多健康检查和监控没有实现，那我的运维就不能打破规则游戏，我会单独为你的系统做一个特殊的高级保证，消耗我的人力资源，甚至有后续被指责的风险。大多数情况下，开发会按照既定的规范遵守游戏规则。对于非要玩特殊游戏的玩家来说，也很简单，两边的boss比拼。有了规范，对于运维团队来说，只需要为固定数量的保障等级准备相应的自动化运维方法，避免过多的个性化需求。二是资源的抽象。一线互联网公司的很多物理资源都是抽象（编码）的，比如机房名称、不同硬件配置的服务器等。这种优点一方面好记，另一方面统一了术语，大家在交流的时候也不容易出错。最重要的是经过抽象表示，对于运维场景来说非常简单。这里的抽象可能很多传统行业的同学都理解不了。我会在这里举几个例子。例如，上海某联通机房的名称可能为cnshu01。简单说明一下，cnsh代表中国上海，u代表中国联通。,01代表数字；再举个例子，我们在购买传统行业的硬件服务器时，可能每次都会根据不同的需求选择硬件配置，然后选择品牌。互联网公司一般先把服务器的用途分类，比如Computation-intensive,memory-intensive,io-intensive等等，每一种都会有一个代码，比如C42就是calculating-intensive的意思，这样的好处是即需要使用机器的部门只需要将他们需要的机器的代码和数量发给采购方的部门即可，不用担心其他任何事情。资源编码的另一个好处是，当一个程序需要用来管理资源时，编码是最容易处理的。三是各类标准化。每个公司都会面临软件版本管理的问题。从操作系统版本到软件版本，不同软件版本的运维还是存在一些差异的。版本一般都有比较严格的一致性要求，特别是在生产环境中。一段时间后，软件版本的升级实际上促进了自动化运维的发展。试想一下，如果没有高效的自动化运维保障，每一次操作系统或软件版本的升级都是一项浩大的工程。正是这种相互促进的关系。当整个公司使用统一的操作系统版本和软件版本时，很多工作的难度都会降低。此外，一线互联网公司对操作系统（主要指linux操作系统）的目录结构也有规范的要求。要求的内容。综上所述，绝对遵守既定规范，资源的抽象化和标准化，是实现端到端自动化运维交付的有力起点。3、在自动化运维和流程控制的部分，我们来谈谈自动化运维和流程控制的关系。我们知道，在运维工作中，任何一个需求的执行，都是由一个相应的流程来控制的。如果没有流程来管理自动化运维的动作，那么自动化做了什么样的运维工作，为什么要执行这些运维任务，谁执行了这些运维任务，如果管理员不知道或无法检查，那将是可怕的。ITIL规范对流程控制也有非常详细的描述，但据笔者了解，在实际企业中，尤其是业务变化很快的企业中，能够完全遵循ITIL流程的企业少之又少。ITIL流程还是比较繁重的，根据公司自身情况量身定制ITIL流程才是正确的做法。在流程管控方面，传统行业无论是否使用ITIL，目前都存在以下问题：一是流程还不够完善，即流程尚有欠缺，不能全面覆盖所有场景；二是流程完善，但没有全部制度化；三是改进了流程，也实现了制度化，但流程之间没有衔接，还存在一些孤立点。以上三种场景，很难对流程进行强控制。好的流程控制应该这样做：第一步是结合工作的实际情况，梳理出我们需要做流程的场景。这一步可以先让每个同事把自己认为需要管控的场景整理成一个通用的需求池，然后通过会议和讨论的方式对需求进行合并或者去重。经过这样一个流程，输出的是一个需要流程控制的文档；第二步，对第一步整理出来的文件，标记出每个流程中最关键的点。该点称为要素点。例如，新采购的机器在上架过程中，包括送机房、签约、上架前准备、上架上电、更新机房信息等几个步骤。已经上架了。使用最有影响力的步骤，则此步骤成为关键点；第三步，为第一步整理出来的流程，找到流程之间的连接点，也是为了解决流程孤岛问题。在这个步骤中，如果发现有一个进程不能连接在一起，但是有故障，需要在这个步骤中解决。第四步是系统的实现。这一步无论是自研还是外包，需要考虑的一点就是如何对接现有的自动化运维系统和资源管理系统，因为过程控制过程肯定会涉及到资源。生命周期管理，这里的资源可以是真实的物理资源，如服务器、防火墙、路由器和交换机等，也可以是软件资源，如安全策略、4/7层负载均衡等。这样的过程管控平台涉及与cmdb、云平台、容器平台的对接工作。这一步通常是耗能的。系统都是自研系统，对接难度可能会低一些。毕竟都是自己公司的团队。如果涉及到对接外包系统，这里的时间段就很难控制了。根据笔者的经验，这里如果是对接外包系统，建议每个系统预留一个月。第五步是过程控制平台上线后与自动化运维平台的磨合优化阶段。这个阶段要注意观察自动化运维平台、资源平台、流程控制平台之间的数据交互是否正常。这里可以引入敏捷迭代的方式，及时处理问题（图4）。图44自动化运维常用工具对比分析各位书友，现阶段主要介绍一下自动化运维工具的三个概念。x86服务器级别。自动化运维工具实现的三个思路：第一个是完全自研。比如阿里巴巴集团的所有物理机都安装了经过验证的强大代理staragent。阿里巴巴集团的所有物理机都在那个时候安装了staragent，直到生命周期结束才会卸载staragent。这里的问题是并不是所有的公司都能像阿里巴巴一样开发出非常强大的代理，所以就有了第二种和第三种思路。第二种思路是利用市场上已有的自动化运维工具，基于这些工具构建自动化运维平台。目前市面上常见的自动化运维工具主要有以下几种，Puppet、Chef、Ansible、Salt。下面是四款产品的对比介绍：Puppet应该是市面上使用最多的，无论是操作，模块，接口。换句话说，它是最全面的，Puppet呈现了数据中心协调的全貌，为所有主要操作系统提供了深入的工具，初始设置简单，只需在每个需要管理的系统上安装客户端代理软件，CLI简单直观，允许通过puppet命令下载和安装模块，您可以对配置文件进行必要的修改，使模块适合所需的任务，当客户端收到指令联系主服务器时，配置文件会发生变化，也可以是客户端主动与服务器通信获取新的配置文件。还有一些模块可以提供和配置云服务器实例和虚拟服务器实例。所有模块和配置都是使用基于Ruby的Puppet专用语言或Ruby本身构建的。因此，除了系统管理技能之外，还需要编程专业知识。Chef的整体概念与Puppet类似，因为代理软件安装在被管节点上，但实际部署不同。除了主服务器之外，安装的Chef环境还需要一个工作站来控制主服务器。Agent软件可以通过SSH部署的knife工具从工作站安装，减轻安装负担。被管节点使用证书完成与主服务器的验证。与Puppet一样，Chef受益于大量的模块和配置方法，而这些又严重依赖于Ruby。因此，Chef非常适合以开发为中心的基础架构。Ansible与Salt非常相似，不像Puppet或Chef。Ansible注重简单和速度，可以选择在节点上不安装代理软件。Ansible可以通过SSH执行所有功能，Ansible基于Python开发，这对熟悉Python的人来说是一大福音，由RedHat运营。Ansible可以在不使用配置文件的情况下从命令行运行。对于更复杂的任务，Ansible配置是通过名为playbook的配置文件中的YAML语法处理的。Playbook还可以使用模板来扩展它的功能。目前playbook的模板还是很丰富的。Salt与Ansible类似，它也是一种基于CLI的工具，使用推送方法进行客户端通信。它可以通过Git或通过包管理系统安装到主服务器和客户端。客户端将向主服务器发出请求。请求在主服务器上被接受后，就可以控制客户端了。网上对这四种自动化运维工具的比较比较多，但是很难说哪一种一定比另一种好多少。换句话说，您可以使用您的团队拥有的任何人才。如果非要选一个，我个人推荐ansible，因为它是基于python实现的，开发者比较容易找到，而且社区资源活跃，相关的资源和组件也比较丰富。第三种思路是购买市场上商用的自动化运维平台。这种思路对于很多甲方企业来说还是很现实的解决方案。对于这种思路，采购方需要梳理自己的需求，梳理自己真正需要的自动化运维场景。这里的建议是在选择商用自动化运维平台时，与平台卖家协商以下三点。首先，甲方结合实际工作中遇到的自动化运维场景，将需要立即满足的自动化运维场景梳理出来，作为第一个模块，即确定要完成的功能模块；二是要求平台卖家提供编写自动化运维工具的接口，支持shell和python两种语言。这个需求是为了考虑一些后续的运维场景，一开始没有考虑到，或者增加了一些新的场景，自己的人员可以在这个平台上写脚本实现；三是要求平台卖方向买方提供在产品层面积累的现有运维场景。并且支持后续的产品更新，新的运维场景，应该免费提供给采购商。5、云平台的自动化运维应该是什么样的？目前，云平台仍是热门话题。最后这一章主要讲私有云iaas和paas平台的自动化运维应该是什么样子。先说iaas平台。iaas平台主要涉及计算、存储、网络、安全（图5）。图5计算资源应该划分为几种固定的规格（计算密集型/io密集型/内存密集型），由开发和运维团队协商定制。如无特殊情况，无论谁申请，都不会增加新车型。同时，不管计算资源是开发者自己申请的，还是开发者通过运维人员申请的，都应该在申请完成后自动完成系统的初始化环境。是的，这里的初始化环境包括但不限于IP地址、内核参数、文件目录结构、计算机名、磁盘卷挂载等。对于存储资源，需要能够实现容量警告和扩容提醒。当触发容量警告需要扩容时，可以通知存储管理员。同时，在存储管理员提出扩容需求和计划后，可以通过流程平台和购买动作通知存储购买者。在存储资源的服务能力上，理想的情况是同时具备块、文件、对象存储能力，以满足云环境下的应用需求，尤其是对象存储现在越来越受到重视注意力。作者举了一个小例子，因为之前的标准化之后要求各个云主机的文件目录结构是统一的，所以当应用需要进行文件操作的时候，使用基于S3协议的对象存储是非常方便的，省去了需要通过nfs或smba挂载磁盘使用nfs或smba挂载的方式会增加运维人员的维护成本，差异化也有悖于自动化运维的标准化理念。实际情况是笔者发现很多传统行业还在使用nfs挂载为应用程序提供文件。每个人都经历过痛苦，所以现在开始逐渐迁移和转型。网络资源，理想的iaaS云平台网络资源首先要能够提供各种虚拟网络设备，如路由器、交换机、4/7层防火墙、4/7层负载均衡和ip资源池管理等，其次，这些虚拟网络设备不仅要能够在管理界面上创建，同时还必须能够支持API调用，能够通过代码进行管理。安全资源，云平台上的安全资源主要是指安全组能力（防火墙放在网络资源中），通过安全组可以隔离不同租户的主机，即使是小公司也可以使用安全组在云平台上隔离测试环境、预部署环境和生产环境，大大降低了基础设施的成本。PaaS平台方面，根据笔者的实际经验，目前主要有两种应用：一种是基于容器和ci/cd进行狭义的devops流程，以适应当下火热的敏捷开发；另一种是提前定制中间件资源（这里主要是消息队列、缓存、分布式锁等），供开发者直接使用。这些中间件资源可以是基于虚拟机定制的模板，也可以是基于容器技术制作的镜像。无论是iaaS平台的自动化运维，还是PaaS平台的自动化运维，要想实现自动化，都必须为每种资源类型提供相应的API。只有提供API，我们才能对其进行编码和自动化。否则很多场景还是无法摆脱人工处理的困境。人工参与的场景越多，出错的概率就越大，离理想的自动化运维也就越远。6.总结本文从五个方面介绍了自动化运维。很多场景也是根据笔者的实践经验来对比一线互联网公司和传统行业的做法。再强调一下我认为自动化运维的理论内涵和外延：对于非业务的功能需求，在提供端到端交付的过程中，尽可能实现全自动化。
