前言

这些年来，大家都在谈运维自动化。但是否也会困惑于“只见树木、不见森林”？或者说，做了几年的运维自动化，但依然不能确定还有哪些工作没做？还有，怎样更优雅的实施运维自动化？

另外，运维自动化是万能的么？有哪些潜在问题？想了解大故障的独家剖析？且听本文分解~

本文实际上包括两部分，关于运维自动化的一些观点（前3部分）和运维自动化的痛点（第4部分）。如果已是运维自动化的专业人士，可以跳过前面内容，直接鉴赏第4部分——运维自动化之殇。

依惯例放上目录，请享用：

1. 什么是运维自动化？
2. 运维自动化的三个阶段
3. 怎么做运维自动化？
4. 运维自动化之殇

好吧我们正式开始。

1. 什么是运维自动化？

有人从实用性的角度来表述运维自动化，就是把运维日常需要登录机器的操作，完全Web化，以后只需要点一下鼠标就搞定。然后，和监控结合，就有自动扩缩容，自动告警分析，自动故障发现，自动流量切换。

这种说法正确么？实际上，Web化只是最基础的工作（而且这更多是运维自助化），我们不能将Web化和运维自动化画上等号。

在了解运维自动化之前，让我们回到起点，先看看什么是运维。运维应包括如下：

• 环境定义：开发环境、测试环境、类生产环境、生产环境等；
• 部署：能够将部署包有效的部署到不同的环境；
• 监控：能够监控部署后的系统和应用；
• 告警响应：出现问题时的响应和处理机制；
• 性能优化：系统各个服务如Nginx、Java、PHP、DB或网络等的优化
• SLA保障：通常要和业务相关部门讨论确定

所以，运维自动化，应该包括上述这些内容。我们结合起来，略举几例：

1）环境定义自动化：

很多公司采用的是数据中心+虚拟机，团队需要某种环境的时候，必须要走流程申请，申请就意味着和不同部门打交道，挨个部门进行层层审批，很浪费时间。

所以环境/基础设施能否自动化很重要，负责开发、管理基础设施的部门，一定要提供方便的接口，帮助其他团队能自动创建资源。

2）部署自动化：

这部分的进化过程大抵如此：Scripts -> Auto tools -> Cloud -> Container，略作说明如下：

1. 最早的部署方式，都是ssh到目标机器上，下载部署包，拷贝到指定的位置，重启服务。如果应用频繁升级，操作人员就会很痛苦，所以就想办法自动化。于是大家来写Shell脚本，自动化部署过程。虽然，Shell脚本好用，但是读起来代码量大，不好维护。

2. 随着工具的发展，客户的部署脚本迁移到了Chef/Puppet，使用起来方便，而且容易维护。

3. 再往后有了私有云，公有云，部署方式又发生变化，这时候面对的层次不一样，部署包也不一样，以前的war包，rpm包，现在到了IaaS层，都变成了image，虽然部署简单了，但考虑的问题更多了，怎么管理image，怎么用好image，怎么更快的scale？都是问题。

4. 现在，Container来了，部署在Image的基础上，又变化了，部署自动化现在解决的已经不仅仅是部署本身了，还包括怎么能更快scale，更容易管理artifact，更容易屏蔽底层的不同。

3）监控自动化：

现在一般都用Zabbix做问题发现，但得考虑做告警归并，以解决特殊情况下告警泛滥的问题，例如机房断网造成的批量服务器报警。

监控自动化是运维自动化的起点之一，这个又包括了部分故障恢复的自动化，即故障自愈。后者又往往借助于故障树等机制，至少对诸如503错误，可通过自动重启应用服务器程序来恢复。

2. 运维自动化的三个阶段

站得高，所以看得更远。也许我们还在给一个小的业务环节搭建运维自动化，但从更高层次了解运维自动化的各个阶段，不无裨益。

1）操作自动化：

这个层次的特征是，把运维一系列的手工执行的操作，用脚本或工具简单串起来。最简单的例子就是，把多个Shell脚本串在一起执行实现某个特定的操作目的。

诚如前文所说，这个层次的自动化只部分解决了运维手工执行的问题，但一旦操作的条件发生了变化，可能Shell脚本也得变，运维的压力还是很大，而且容易出错。管理的服务器越多，出错的概率越大得多。

2）场景自动化：

这个层次的特征是，工具会根据外部环境判断如何运行，而这些判断条件是事先运维定义好的。此层次的运维系统需要各类环境数据来做为判断条件，同时还要能够变化操作行为（比如不同的执行步骤）。

因此，此层次的运维系统需要跟很多其他系统对接（比如对接了配置系统、网管系统等），最好还要有流程引擎；

3）智能化：

此层次的运维系统具备数据核心（大数据存储，所有运营中的数据都会按关联关系集中存储），具备根据数据自己分析和判断、并自我决策和执行的能力。

在此层次，运维的主要工作是为系统增添分析策略、运营和维护此智能运维系统，以及在系统执行的关键节点上介入做人工判断；

3. 怎么做运维自动化？

很多运维同仁实施运维自动化时，谋求设计一个完备的系统，来自动化完成几乎所有运维工作——但与此同时，又往往被其复杂程度所困惑、踌躇不前。在我们思考怎么做运维自动化之前，我们需认识到的是：

“企业的架构不是设计出来的，是演变而来的。”

这可以近似作为指导思想。这也表明，除非是成熟的大公司，否则不要一开始想着我怎么做个大一统的自动化平台，然后千辛万苦找公司要到资源，然后大半年不出成果（然后绩效还得了个C）。

1）先解决痛点

如果登录服务器部署更新程序非常频繁、经常为此起夜或因响应不及时常被业务投诉，那就先做Web部署自助化（例如Jenkins + Ansible）。至于说是否基于CMDB，反而不太重要，特别是如果业务系统并没那么大，服务器变动也没那么频繁的话。

日常工作中，对常见问题进行分类和梳理，能做成工具的就工具化，能程序化操作的，就避免人为干预。

这样各种工具越来越多，小工具组装起来，发挥更大的效能。对于复杂的自动化任务需求，也可以用多个小的、单一功能的模块，组合起来完成复杂的操作，类似于先造零件，再拼装（后文再详细介绍）。

2）选择正确的阶段

运维自动化一般沿袭这样的阶段：

手动支撑 => 线上标准规范化 => 运维工具化 => 平台自助化/自动化。

选择适合自己当前业务发展阶段的运维自动化方式，很重要哦，不要图谋一口吃成胖子，呵呵。

也有人说，运维自动化平台就是一个任务执行系统，如果确保准确执行是整个系统的核心所在。

所以，标准化是运维自动化的前提，如Ngnix/JAVA/PHP/MySQL这些常见服务的应用初始化流程、部署更新流程等，得提前固化下来；另外同理，业务流程和操作顺序也不能乱来。

另外，对于大中型运维自动化平台而言， CMDB和配置系统依然不可或缺。

CMDB即配置管理数据库，一般用于统一管理IT数据、服务器数据资产等。CMDB数据的准确性和权威性，关系到运维自动化是否走在正确的路上——毕竟系统不是人，无法加入感性判断，只能基于冰冷的数据进行触发式处理。

需要注意的是，解决痛点和标准化/CMDB不是矛盾互斥的：

解决痛点而搭建的运维自助部署平台，和基于标准化/CMDB而部署的高大上运维自动化平台，可以共存。毕竟前者实施起来快，后者建设周期长。

3）原子件 & 复合件

上好佳的运维自动化平台需要融入一些架构设计的思想。这里最重要的就是原子件和复合件的设计，我们先看一下Zachman，企业信息化架构创始人怎么说的：

1. 只有拥有大量原子模型时，才可能大规模重用和组装。也就是在你得到订单之前你就应该在仓库里拥有东西，这样你才能做到大规模客户定制和按订单生产。

2. 复合件的数量是无限的，原子件的数量是有限的；原子件可用于一个以上的实施。

这可以作为我们的指导思想。我们来看一下腾讯游戏基于此的最佳实践。

腾讯游戏在底层设计并封装很多原子件，这些原子件可被多次调用。例如原子件“DB容量管理”就应用到复合件“数据决策自动缩扩容”、“运营活动自动开关”等。

4. 运维自动化之殇

运维自动化是我们的必经之路，那么，一定就是解决所有问题的灵丹妙药么？可能不尽然哦。潜在问题包括如下：

1）忽略权限和基线

运维自动化平台通常由DevOps开发（例如Python + Shell），更多的是以实现功能为主，可能对账号权限或服务器操作权限，未做特殊限制，这样问题就来了，例如：

1. 是否针对运维自动化平台的服务器账号做了特殊限制，使得这个账号只能操作指定目录，只能重启Nginx、不能重启PHP？

2. 是否做了超限检查？例如，对部分特殊请求如“rm -Rf”或超高数值调整做了二次过滤？

3. 是否做了关键操作的双保险？例如，数据库合并类的危险操作，增加了一个检查人审核机制？

另外，运维自动化发布平台是否保存有程序基线，并有一键恢复功能？

大公司的业务系统，运行十多年，开发人员你来我往数以千计，而发布平台每次仅更新部分代码（类似缝缝补补）。这样的后果是，可能根本没有人有一套完整的业务系统代码。

如果执行任意系统命令+缺乏基线，两者兼备，刚好又有人触发了执行操作，那么灾难性的后果就会突然来临。

毕竟，对于历史悠久的大型业务系统而言，老代码往往没人敢动，而且严重SOA化，从零重建的难度之大，也许需要几十个小时。而又因为这种极端情况下，很难形成一个强一致性的版本，所以重建成功往往只是灾难的开始，之后就是开发、客服和DBA陷入长期的疲于奔命之中。

2）缺乏安全机制

运维自动化平台一般由非专业开发人员实施，而且是给内部人员使用，主观上容易忽略代码安全和系统安全。

“上帝节点”是安全灾难的起点。

之前没有运维自动化，小米加步枪的时代，上千台服务器相对独立，还有各种堡垒机、动态令牌或私钥登录服务器等安全措施，想一个命令删除大批量服务器的程序，还真不容易实现。

运维自动化平台已然是“上帝节点”，天然的实现了连接到大批量服务器（甚至可能直接是root权限）。这样，为广大的黑客朋友带来了无限想象空间。

有朋友可能会说，我放在公司内网了非常安全。其实，现在黑客可以很容易的扫描到内网所有域名，识别到疑似运维自动化平台的域名，然后用常规或非常规手段入侵，然后就“一锅端”了。例如：

你的运维自动化平台是基于通用框架如Django么。一个常识是，越是流行的框架，已知漏洞、甚至0day漏洞越多哦。

3）忽略专业性

运维自动化越是充分的公司，隐藏的风险就越大。

即使一个再优秀的运维自动化平台，也不能解决所有运维问题。所以，如果忽略了对人员专业能力的培养，那么在某些需要人工操作的场景（例如机房迁移这类重大调试），问题就会报复性的反弹和爆发。

一次专业的调试，体现在对调试时长和调试效果的掌控上。调试时长必须可接受、并可控。

例如一次跨机房迁移，停业务10小时甚至以上，是很难被接受的；停业务10分钟以下，则是很令人愉快的。但这个的专业化要求很多，包括如充分的演练、更多的任务前置，保证只有必须的操作在调试期间进行。

可控性主要体现在调试节奏的把握，例如是否有快速可操作的回滚措施，保证如果预计调试不能如期完成，能提前预警并快速切回之前的系统状态。

当有重大调试需求时，突然发现中级运维人员没那么多了，初级运维人员缺少专业化锻炼和练手机会，“手生”，主管不敢用之；高级运维人员都已“金盆洗手”多年，自己不敢上手。

4）自得和忽略人文关怀

运维自动化平台上线后，运维人员可能会产生一种主观的优越感，并严重阻碍后续工作的开展。以前是开发追着运维打，运维往往疲于奔命，心力憔悴。现在神器在手，容易“多年的媳妇熬成婆”。。。

其实运维自动化只是解决了运维部分工作效率的问题，远没有解决运维的全部问题，外部门对运维的不满，可能涛声依旧，例如经常容易犯的“老板着个脸，说话直接不拐弯；需求老不及时完成，完不成也不说”等等。

运维自动化越是充分的公司，高层管理者（技术VP或CTO）可能产生一种错觉，运维人员是否可以靠边站了？甚至夸张些说，是否可以“卸磨杀驴”了？这种意识层的错觉或者说自我心理暗示，会导致各种多米诺骨牌式的效应。

如果高层忽略人为关怀，在某些极端情况下，运维自动化平台的高权限人员，可能“有意”利用上述提及的平台缺陷，进行极具破坏性的事情。。然后灾难性的后果，可能长时间难以补救。

结语

运维自动化的价值在于，将运维从繁琐的、例行、容易发生人为事故的工作中脱离出来，做更有价值的业务运维和服务运维。

所以，从这个角度来看，运维自动化既不是起点，也不是终点。运维自动化不是万能的，我们需要看清楚它的位置。

运维自动化，终归只是一个高级工具而已。运维的价值最终是要体现在业务上的：

体现的方式就是运维服务化，所以运维自动化（智能化）最终都要为运维的服务化服务。所以如何构建你的自动化系统最终要看你所支撑的业务需要什么样的服务。

所以，在做之前一定要弄清楚我们的目标，不要为了做而做，如果这样，结果就只能是呵呵了。

 

---

关于作者

萧田国，高效运维社区发起人，开放运维联盟主席，复旦大学客座讲师，互联网专栏作者《高效运维最佳实践》