自动化运维的价值

对于大型的计算集群或者线上（测试）环境，有成千上万台服务器在运行，单凭SRE进行手动变更或者运维是远不能支持平时工作的，所以这里就要讲到自动化运维的价值：

一致性

大型集群在硬件层面很难做到完全统一，但是在系统层面、软件层面和服务层面是可以通过认为影响达到一致的。生产环境的一直能很大程度上标准化生产环境，以降低环境差异化带来的人力成本或者其他附加成本。比如在生产环境中，机器可以通过群组的方式进行批量管理，每个群组内的机器试用相同的环境配置，对于配置试用repo进行统一管理，由此可以把机器的管理粒度从单机提升到群组（但是同时带来一个隐患，如果对群组进行配置变更，如果配置失败影响面就会从单机上升到大批量）

硬件层面比较难做到一致化或者统一化（主要问题来源于设备供应商不同，不同设备的管理方式也不大一样），所以在设计自动化的时候尽量兼容更多的硬件平台或者指定CFI（以上两个选择一个就好，后者可能更贴合当前实际），同样在设计时也尽量使用通用管理方式，比如ipmi协议。

平台化

对于变更或者运维操作具象成平台上操作的一个对象，对象可以是单机，也可以是集群，也可以是自定的群组。平台化是自动化运维的上层构建，通过平台对于下层管理的资源进行自动化运维，降低操作时间和操作量。同样也可以化解很多模式化或者重复性高的工作。

同样，一个成熟的环境不会只有一个平台进行运维支撑，所以设计平台时一般都会流出很大的横向扩展的裕量（比如API或者通用化模板）。

修复速度快，行动敏捷，时间和人力成本有效节省

自动化运维主体就是通过代码的方式解决很多的手动才能解决的问题，代码的执行效率总是高于人工的，所以在一些工作上面能显著提高效率。而且自动化可以针对一些常规故障的自动修复，或者在系统变更错误甚至系统崩溃时能进行快速回滚，实现MTTR指标提升。

自动化运维软件的定义

自动化运维软件可以定义为一个元软件。自动化软件通常是进行操作其他软件以达到全流程自动化的目的，其主要原理其实就是把人的机械性操作转换成软件。所以在自动化软件中经常能看见使用shell调用其他脚本或者命令，比如常见的useradd。

在我就职于小米的时候，我的主要工作就是进行硬件层自动化的软件研发。因为采购的服务器品牌较多，比如dell的服务器使用的带外管理工具是idracadm，但是浪潮又使用的是其他自研工具。程序的通用性就不是很大，所以在真正的代码中基本都是使用命令行在调用厂商提供的管理工具（有些数据采集或者操作ipmi实在是做不了）。对照上边的三个价值review这项工作，可以很明了的看出自动化的价值在实际生产中的意义。

自动化分级

自动化分级通常也是使用的L5分级法，即L1是全无自动化，所有工作都需要认为干预，L5是自动化的最高等级，一切工作都无需认为干预，运维支持系统能完全实现自动化运维。

人工智能分为三个阶段，自动化、智能化、智慧化。目前人工智能只是实现了自动化，正在向智能化发展。 –沃兹基硕德

运维也是一样的。运维目前整个行业都在逐渐构建自动化运维体系，且国内没有一个规范的建设标准，都是以google为标杆建设自己的自动化运维系统。近年有公司的自动化已经趋于完善，开始实现AIOps（智能运维），但是始终离L5的运维支持系统还有很大差距。

集群运维自动化

集群运维自动化，通常是要依赖于强大的基础设施的，比如：

稳定安全的数据中心以及网络中心（排除非人为和不可抗外力）
强大的数据托管平台（比如CMDB）及其他的支持数据和资源
稳定良好的基础服务环境（比如无污染的DNS）
等等……

林子大了什么鸟都有

难免自动化在集群中应用时会出现部分机器故障或者自动化失败，这个在上线以后是很致命的。所以可以引入一个Prodtest的概念，在上线之前进行测试，验证：

服务器依赖是不是都可用，配置是不是想要的
一致性怎么样
是否能确定“例外”都是合理的

比如对于一个基础设施服务的Prodtest就可以以如下方式进行：

机器基本环境检查，装包检查，配置一致性检查
双线检查 a. 服务线：服务是否可用，稳定 b. 监控线：监控是否健康，稳定，数据是否准确（我确实见过监控数据和人工查数据不一致的情况的）

注意，以上测试都是链式的，任何一个节点出问题都要停下来解决完成再向后推进。