转载

运维自动化之殇 | 高效运维最佳实践05

专栏介绍

“高效运维最佳实践”是InfoQ在2015年推出的精品专栏，由触控科技运维总监萧田国撰写，InfoQ总编辑崔康策划。

前言

这些年来，大家都在谈运维自动化。但大家是否也会困惑于“只见树木、不见森林”？也就说做了好久的运维自动化，但也不能确定是否就是全集，或者说，不能确定还有哪些运维自动化的工作没做？

运维自动化的价值在于，将运维从繁琐的、例行、容易发生人为事故的工作中脱离出来，做更有价值的业务运维和服务运维。所以，从这个角度来看，运维自动化既不是起点，也不是终点。

本文不是很长，如果已经是运维自动化的专业人士，可以跳过前面内容，直接鉴赏第3部分，运维自动化之殇。依惯例放上目录，请享用。

什么是运维自动化？

运维自动化的三个阶段

怎么做运维自动化？

运维自动化之殇

好吧，我们正式开始。

1. 什么是运维自动化？

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

但实际上，Web化只是最基础的（而且这更多是运维自助化），我们不能将Web化和运维自动化画上等号。在了解运维自动化之前，让我们回到起点，先看看什么是运维。运维应包括如下：

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

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

1）环境定义自动化

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

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

2）部署自动化

这部分的进化过程大抵如此：Scripts -> Auto tools -> Cloud -> Container。

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

于是随着工具的发展，客户的部署脚本迁移到了Chef/Puppet，使用起来方便，而且容易维护啦。再往后，有了私有云，公有云，那么部署方式又发生变化了，这时候面对的层次不一样，部署包也不一样，以前的war包，rpm包。

现在到了IaaS层，都变成了Image，虽然部署简单了，但考虑的问题更多了，怎么管理Image，怎么用好Image，怎么更快的Scale？都是问题。

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

3）监控自动化

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

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

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

也许我们还在给一个小的业务环节搭建运维自动化，但从更高层次了解运维自动化的各个阶段，有助于我们看得更远、做得更好。

1）操作自动化

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

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

2）场景自动化

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

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

3）智能化

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

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

需要补充说明的是：

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

所以，在做之前一定要弄清楚我们的目标，不要为了做而做，如果这样，就不必期待实现预想的效果了。

3. 怎么做运维自动化？

很多运维同仁都在追求自动化，谋求设计一个完备的系统，来自动化完成大部分运维工作——但往往被其复杂程度所困惑、踌躇不前。在我们思考怎么做运维自动化之前，我们需认识到的是： “企业的架构不是设计出来的，是演变而来的。”

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

先解决痛点。

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

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

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

运维自动化之路

做着做着，你可能会发现自己沿袭这样的道路：

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

需要注意的是，在此过程中，选择适合自己当前业务发展阶段的运维自动化方式，很重要哦，不要图谋一口吃成胖子。

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

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

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

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

4. 运维自动化之殇

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

1）忽略权限和基线

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

例如高权限账号可以执行任意系统命令，如“rm -Rf /var/www/html/”，而且自动化运维平台并未做特殊校验。嗯，然后呢？

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

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

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

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

2）缺乏安全机制

运维自动化平台一般由非专业开发人员来做，而且是给内部人员使用，所以往往忽略了代码安全和系统安全。

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

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

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

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

你的运维自动化平台是基于通用框架如Django么，越是流行的框架，已知或0day漏洞就越多哦。

3）忽略专业性

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

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

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

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

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

4）忽略人文关怀

运维自动化平台往往能减轻对技术的依赖，运维人员两极分化，变成平台的使用者或创造者，大量中级运维人员不再需要。

这或许会让管理者（技术VP或CTO）产生一种错觉，运维人员可以靠边站了？

这种意识层的错觉或者说自我心理暗示，会导致各种多米诺骨牌式的效应。

说明

本文与其说是我编著，还不如说是高效运维系列微信群朋友们集体智慧的结晶。其中第1部分“什么是运维自动化”，主要来自王磊@thoughtworks的观点；第2部分“运维自动化的三个阶段”，主要来自刘栖铜@腾讯游戏的观点，另外张冠宇@大众点评及其他专家群友对本文的形成亦有重要贡献。在此一并谢过。

关于作者

运维自动化之殇 | 高效运维最佳实践05 萧田国 ，男，硕士毕业于北京科技大学，ACMUG核心成员，目前为触控科技运维负责人。拥有十多年运维及团队管理经验。先后就职于联想集团（Oracle数据库主管）、搜狐畅游（数据库主管）、智明星通及世纪互联等。从1999年开始，折腾各种数据库如Oracle/MySQL/MS SQL Server/NoSQL等，兼任数据库培训讲师若干年。