变更审核时我们审什么

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

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

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

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

变更影响

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

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

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

操作步骤

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

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

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

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

验证方案

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

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

回退方案

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

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

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

    原文作者:Cocowool
    原文地址: https://www.cnblogs.com/cocowool/p/change-advisory-board.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞