警惕！运维自动化之 “暗礁”

导语

印象中关于“运维自动化”，人们一般会想到减少重复性工作、全面的配置一致性、高效的响应和交付等优点。虽然运维自动化带来了很多好处，但也并非完美无缺。如果自动化系统本身存在漏洞或故障，一旦出现问题可能会影响整个系统的运行。根据“墨菲定律”，我们更应该对运维自动化有一定的风险意识，防患于未然！

风险点

配置一致性，即确保所有服务器和系统的配置保持一致，减少因人为错误导致的配置差异。例如，通过自动化工具可以统一管理服务器的操作系统版本、软件安装、安全设置等，避免因不同人员操作带来的不一致性。

为什么配置一致性会有风险呢？因为目标资产的范围可能出现误判，我们先从需求或场景进行分析下。

默认情况下运维类操作多分为覆盖多个场景的自动化流水线，如：

基础组件安装，如：各类agent、探针、filebeat等；
环境初始化，如：操作系统、java环境、python环境、go环境等；
安全基线，如：密码复杂度、防暴力破解等；
版本发布；
等等
但是运维类日常操作除了以上，还有很多杂乱的需求需要我们临时通过自动化工具进行批量操作，如：

临时统计类需求；
参数调整需求；
补充安装/卸载需求；
无论哪种需求或场景 ，一般情况底层使用的自动化工具都是一样的，例如：Ansilble、SaltStack等，那么操作的目标资产范围如果出现管理不善，那后果将会不堪设想。

这时你可能想到，批量工具会有幂等性，即无论对一个系统执行多少次相同的操作，其结果总是相同的，并且不会产生额外的影响。借助幂等性，虽然在很大程度上规避部分风险，帮助我们更加可靠、高效地管理和配置系统，但是变更中的小概率事件也可能暴雷。

预防方案

为避免因目标资产范围错判导致生产事故，以Ansible为例，我们觉得可以通过以下几方面进行规避：

目标资产范围应细分，例如应用、大数据、数据库或者更细分的范围；
自动化操作和日常操作资产进行分离，避免操作同一对象；
自动化资产调整权限，默认禁止修改；
新建剧本针对不同测试场景应进行多次演练，对不同情形应进行判断跳过；
剧本变更应进行多人复核，做到事前检查、事中观察、事后确认；
自动化执行过程钉钉通知，包含job名称、执行结果、执行内容、执行IP量等；
流水线单独使用应用类资产文件，避免多资产混用；
各应用剧本按组件或需求单独编写，避免直接复用，应按tag编排；
执行计划，大批量操作时先执行计划 ，然后在根据执行计划做变更；
危险操作命令告警，根据任务/关键字的内容发送至告警群；
事前我们可能对以上预案不觉明历，事中如若出现后背发凉、全省冷汗等症状，那么事后这剂药可能会让你药到病除！