变更审核时我们审什么

变更是运维工程师最经常参与的一项活动，在重要变更进行之前，我们往往需要在组织内部进行变更评审，那变更评审的作用是什么，我们应当进行变更评审，本文与大家一起探讨。

当运维的组织超过一定规模后，一定要通过变更流程来进行管理，从而实现风险的有效控制，避免出现删库跑路的情况。变更管理的目标是提高变更实施的计划性，规范生产变更实施的活动，这块如果要详细阐述内容非常多，大家可以参考 ITIL 相关流程设计。

不管采用什么样的变更管理流程，变更分析评审是变更顺利实施的重要保障，本文从以下几个方面来做变更评审。

• 变更影响评估是否清晰
• 变更窗口是否合适
• 变更时长控制是否合适
• 变更操作步骤是否清晰、简便
• 变更验证是否完备
• 变更回退方案是否完善

变更影响

在执行一个变更之前，我们首先要非常确切的知道变更的影响，例如是否会引起联机业务中断，会影响哪些用户，和批量业务的时间是否冲突，是否会影响上下游的系统。

这就要求我们运维一个系统时，不管要知道自己运维的技术组件，还要深刻理解系统之上运行的各项业务。

变更影响的分析结果，会直接影响我们的「变更窗口」和「变更时长」的选择。如果是对一个集群模块进行维护，例如 Apache 组件，因为支持优雅重启，我们甚至可以选择在业务高峰时段进行变更。如果是一个需要停机的版本变更，我们则只能选择没有业务或者业务低峰的时候执行。

操作步骤

变更方案是指导我们具体实施变更的最后一份材料，我所在的单位会将变更方案体现为变更控制表，变更控制表的基本格式包括以下要素。

阶段	操作内容/目的	目标主机/目标网址	用户名	详细操作步骤	开始时间	完成时间	操作人	验证方法	复核人
准备阶段	备份应用	hostname_ap1001	root	cp x x.bak	xx	xx	A	diff xx	B
实施阶段
验证阶段
应急回退

按照这个格式整理变更方案的好处是步骤和操作内容非常清晰，任何人拿到控制表都可以操作。当然，按照这个标准准备控制表会耗费时间，有些人觉得投入太不值得，很简单的变更，可能两个人沟通几句话就可以说明白，要是写出来则要很久的时间。

从运维的严谨性上来讲，我们要保证99.99%的系统可用性，除了在技术上不断完善提高高可用外，在操作中一定要贯彻「审慎、细致、严格、踏实」的原则，唯有这样，才能形成良好的运维习惯，确保在自己的运维工作中不犯低级错误，避免损失。

验证方案

验证方案是在变更控制表中验证阶段执行的步骤，版本投产往往是开发项目组进行功能上的验证，这就包含很多的方法本文不再赘述。对于非版本类的变更，运维人员尽量将验证方案规范化、细致化，例如本次变更是对一份有问题的数据进行清理，那就需要明确本次执行的SQL会影响多少条数据，实际执行完后，检查是否确实修改了多少条数据。

严丝合缝的完成整个变更过程。

回退方案

任何变更都有失败的可能，也随时有可能收到回退的指令。因此一个没有考虑回退方案的变更是不完整的。

在某些极特殊的场景下，可能确实没有办法做到完全回退，例如我们要对用户系统的ID生成规则做一次转换的变更，当数据转换完成开始接收新的业务时，就可能无法再回退了。这种情况下，我们需要设置好必要的决策点，在决策点到来后，进行必要的技术/业务验证，来决定是继续还是回退。

关于变更的内容，其实还有很多实用的技巧，也欢迎大家与我沟通在实际运维过程中，如何避免犯错。