大型互联网环境的运维自动化理论和实践
By 钟红军@大众点评
运维行业现状
纵观行业，互联网业务经过最近10年的发展，已经进入了大平台，大纵深的阶段。业务量巨大，交易额破千亿乃至万亿，日订单超过百万甚至千万，主流APP 的月活达到数亿，网页PV 更是一个巨大的值。可以想象，在这巨额的访问量、点击量后面，是大规模的服务器、虚拟机、存储空间、网络拓扑在支撑。在这大规模的网络背后，则是频繁的发生着各种网络请求、大量的系统变更、网站和应用发布，以及众多待修复的BUG或者不同等级的运维故障。而运维团队和研发团队则是围绕这一切辛勤的忙碌着，24小时待命。
这大规模的网络以及频繁的变更、发布，如何才能做到高效和稳定？显然，这背后的方法论已经不是十年前的系统运维理论可以支撑的了。
运维通用问题
要回答这个问题，我们可以先从运维人员最直面的问题开始。
运维人员日常操作众多，非常繁琐。如果对这些日常操作进行汇总分类，操作种类大概可以分为这些：部署，安装，上线，检测，管理文件，备份，扫描日志，配置，下线，初始化，部署监控，收听监控，应急等。这些操作具有一些共同的特点：
操作繁琐，不统一
每次操作由于人不一样，极有可能出现操作不一致。大量操作（比如：同时上线1000台服务器）时尤其危险，很可能出现其中千分之一的机器部署或配置有差异，从而导致问题。
容易出错，毫无成就感
操作由手工命令或者shell脚本完成。这些脚本写的并不严谨，容易出错而且不可完全依赖，有时还需要临时修改。大量重复的操作，毫无成就感，而一旦操作出错，运维人员就要背锅。
没有办法做到快速交付
什么叫快速交付？这个快速交付有两层含义。一个是资源的快速交付，比如说突然有个大促，要扩容，但是做不到一个小时或半天把它扩完，而可能要几天。业务是等不急的，只能靠运维团队加班。另一个是支持的快速交付，比如说周末运维不在岗，出问题了，很多时候就一群研发等着运维出现。此时运维团队承担了大量的压力，然而，并不能得到和压力相对应的成就感。
解决思路
运维自动化
面对这个情况，大多数互联网公司，大多数的运维团队，想到的解决方案基本相同，就是开发运维工具。通过使用网页操作的运维工具来辅助全手工操作，以降低操作的繁琐程度，提高操作效率，减轻运维人员的压力。
开发运维工具也是有注意点的。很多运维团队的工具，开发的不是很成功，就是他们缺少正确的运维工具开发思路。简单来说，运维工具化要想达到目的，需要注意下面三点：
1. 工具的用户
虽然是运维工具，但如果只将使用用户局限于运维人员的话，则是一种失败。在设计之初，就应该将公司所有研发队伍设定为运维工具的使用者。这样一来，研发人员很多运维工作，可以自助通过运维工具完成，而无需要运维人员介入。这是一个既提高运维工作效率，又降低运维人员工作量和压力的好招；
2. 工具的开发
说到开发，很多运维团队会觉得比较困难，因为涉及到软件设计和编码，这块通常不是运维技术人员的特长。因此，很多团队，都会建设相应的运维工具开发组，招聘专门的开发人员。这当然是合理的。然而，如果将运维工具的开发，完全局限在工具开发组，则是另一个失败。
因为工具开发组的同学，通常不具备完整的运维经验和思考。他们并不能完全理解所开发的运维工具的定义、用途和痛点，只能按照需求来。这种开发，虽然在编码方面效率很高，然而在工具最终的用户体验方面通常比较差劲。
因此，正确的做法，是要形成层次化的开发，将底层的、核心的部分，交给编码更专业的工具开发组，而将上层的、面向最终用户的、包含更多运维逻辑的部分，请普通运维人员参与进来开发。这样的开发模式，可以综合保证开发的质量和产品的用户体验，既保证了工具的核心代码可靠，同时保证了工具的业务逻辑和操作体验是非常贴近用户需求的。
3. 工具的自动化比例
自动化听起来往往是个很厉害，又很难的东西。对很多运维团队来说，既向往，又觉得神秘，觉得很难驾驭。其实，自动化很实在。对于运维工具的设计来说，如果没有实现较大比例的自动化，而仅仅是主要实现了自助化和网页操作，那么，对于运维团队的工作量减轻和压力减少的作用有限。这样的工具，由于对运维操作人员的吸引力不大，因此最终可能因为无人使用或者使用率太低而失败。至于这里的自动化比例，建议一开始就设定在80%以上，即：团队所有运维操作的80%，应该实现自动化操作。
构建运维自动化工具体系
那么，对于一家互联网公司来说，大体上需要哪些运维工具呢？
根据对BAT等一线互联网公司的总结，高度抽象，运维工具体系，基本可以概括为以下四个重点组成部分：
1. 流程系统
流程系统可以实现运维操作流程。他应该可以支持很多流程，包括自动化的，也包括非自动化的，纯粹审批的，等等。工具开发人员也可以随着业务的发展对流程系统不断迭代，将其中一些流程环节自动化掉。
2. 操作程序库
将众多的运维操作元子化后，可以积累很多操作程序。每个操作程序应该是完成一个特定的、固定的功能，比如重启服务器，比如防火墙配置，比如监控软件安装，比如将服务器加入某个监控名单，等等等等，不一而足。这些操作程序定义了具体的运维操作，由运维人员不断开发、补充。操作程序库对这些程序进行管理，包括版本管理、使用情况监控、代码double check 和审核等。
3. 监控体系
之所以称之为监控体系，而非一个简单的监控工具，是因为，监控需要层次化、体系化。通常来说，监控至少包含这些层次：系统监控，业务监控，用户（第三方监控），智能监控。系统监控是：对服务器、网络硬件的特征进行监控，包括CPU，内存，硬盘空间，IOPS，网络包数，丢包数，包平均大小，连接数等等常见指标的监控。此类监控准确的反映了硬件系统的运行状态，然而非常不足的是，它并不能和业务的实际情况划等号。一台服务器负载高不代表业务一定有问题，负载低也不代表业务正常（网站如果完全不能访问了，此时服务器负载会很低）。所以，第二个层次是业务监控，对业务详细的指标进行监控。比如，对于一个电商网站来说，一下指标的监控就属于业务监控：用户登录次数，登录失败次数，登录时触发图片验证码次数；用户领取优惠次数，其中新用户领取次数，领取成功次数，领取后使用数和未使用数，等等等等。这些指标详细监控了业务的细节，一旦某个地方出现问题，可以快速发现。
第三个层次，用户（第三方）监控，可以是部署第三方的监控系统，也可以是自己APP上报的用户真实数据，或者公司客服系统提供的客诉数变化，都属于第三个层次。第三个层次相比业务监控来说，它也是监控业务情况，同时它更宏观，也更直观。它是对第二个监控层次的一个有力补充。
第四个层次，智能监控，则是在综合前面三个层次的监控数据的情况下，智能地去定位问题或者发现、处理问题。譬如，当业务监控发现用户登录失败次数增多了，然后技术人员并不能马上知道问题的ROOT Cause 在哪里，无法立即进行处理。此时，智能监控可以通过结合1、2、3 监控的海量监控数据，来在数据间建立联系，尝试找出此一时刻各种监控数据之间的关系，来尝试定位出问题的环节，某台机器或某个网络。
4. CMDB
CMDB全程为配置管理数据库。它是运维自动化体系的核心。这里的配置管理数据，应该是广义的，包含所有用于详细描述我们所管理的大型网络环境的资源和属性。硬件来说，服务器要详细到CPU个数，CPU型号，CPU核数，是否超线程；内存条数，内存型号；硬盘个数，每个硬盘的型号，大小，转速；网卡个数，每张网卡的型号，速率，等等。软件来说，要详细到操作系统，版本，等。所有东西都可以进入CMDB，作为一个实体来描述。譬如运维管理人员可以是一个实体；具体的某个软件可以是一个实体；环境（测试环境、集成环境、PPE环境、正式环境等）可以是一个实体。CMDB同时要记录关联关系，比如，服务器的某张网卡，链接到了某个交换机的某个端口；某个软件，被安装到了某台虚拟机上；某个运维人员，负责对应的某几千台服务器；等等等等。详细的资料属性加上明确的关联关系，可以纯粹根据CMDB数据来生成准确、详尽的网络拓扑。这些详尽的信息，为流程系统、监控体系、运维脚本库的工作提供了准确的自动化基础。
完善的运维自动化，基于准确、详尽的CMDB信息。而同时，如果该信息出现错误，则会出现灾难性结果。自动化程度越高，则这个灾难越大。譬如，由于某几台数据库服务器在CMDB里面被错误的标识为备份服务器，而导致自动扩容流程（它正好缺少足够服务器，于是按照预定程序，它将空闲备份的服务器自动初始化并用于上线）将其上的数据删除并下线。这并不是一个虚拟场景，事实上，在互联网公司的运维实践中，多多少少会出现过。某一线OTA互联网公司，就2015年就曾经出现过自动发布系统错误地将所有线上程序删除，导致该公司几乎所有服务24小时不可用的严重事故。
管理运维自动化工具体系
在确定了运维自动化工具的体系和开发方法后，将不得不面对下一个问题，即大量工具所导致的工具管理失控问题，以及对该问题的解决思路。一般来说，根据前面的方法，一个中型互联网公司的运维团队，经过2年左右的发展，将会生产出一系列的工具，覆盖到上面所说的四个方面。而此时，自动化问题进入新的阶段。一方面，工具太多了，越做越多；另一方面，工具的开发管理开始失控，版本管理，使用管理，众多权限的管理，新员工的管理，等等。概括来说，出现以下三种情况：
1. 工具开发管理的失控
软件开发有其生命周期和开发管理规律。通常来说，如果正确的遵循这些规律和要求，则不可避免的产生软件开发失控，诸如开发延期，需求变更紊乱，设计脱节，代码质量不高，代码check in check out 混乱，新旧代码混杂，子分支众多并不一致，等等。在运维工具开发中，由于多层次开发引入了普通运维人员参与开发，他们在软件开发本身的素养方面是欠缺的，因而在失控方面表现得更严重。
2. 工具使用的失控
自动化工具由于带来了方便，也就必然导致一些问题。比如权限控制问题，一个初级运维人员操作了一个关键的变更，可能会是一个灾难。而如果要求所有操作都引入高级管理人员的审核，那么审核动作本身会成为瓶颈。谁能使用，谁不能使用；何时该审核，何时不应该审核，这是个问题。
3. 工具所产生的大量信息的管理失控
除了CMDB信息外，每个工具不可避免的产生大量信息，譬如，工具自身运行的信息，运行日志，成功失败记录；工具所操作的资源对象（如服务器、网络）的变更信息。这些信息由于在整个运维工具体系内的 信息同步延迟或甚至在同步过程中的信息丢失（如日志上传失败或者未上传，或采集的信息不全等），将最后导致体系内的信息不一致。譬如，一个工具重启了一台服务器，而此时，另一个工具可能正在对该服务器进行上线，由于这两个信息可能没有及时互相同步到，或者工具没有去check该信息，这两个操作必然发生冲突，导致不可预料的结果。
解决以上三大失控的方法，就是工具的产品化。即：使用公司业务产品的开发管理和运营思路，来进行运维工具的开发管理、使用和运营。
- 管理模式，使用标准的业务研发管理流程和手段
- 整体架构，采用标准的SOA体系
- 数据实现服务化，各工具之间通过接口访问数据，而非直接读取DB
- 工具自带统计运营报表，可以直接看到工具的运营情况
- 注重用户使用体验
互联网公司的业务产品开发，涉及到大量开发人员，产品经理和运营团队。其需求变更频繁，代码量大，需要持续迭代。其所涉及到数据众多，并且由于是业务数据，因此必须做到数据一致和准确。这些特点，相比运维工具来说，都要复杂得多。因此，通过学习和引入他们的开发管理模式，显然是能有效地改变运维工具开发的局限，实现较好的管理，避免失控。
总结来说，我们在本文中，分析了大型互联网公司当前所面临的大规模运维管理的现状和难点。根据这些难点，我们提出了运维自动化的解决方案。然后我们剖析运维自动化方案所要解决的问题，提出了自动化的三点方法论，自动化工具体系的四大模块，以及为了解决大量自动化工具应用后所带来的自动化失控问题，所引入的工具产品化解决方法。以上就是本文针对大型互联网环境下的所建立的运维自动化理论和实践指导。谢谢大家。