? 优质资源分享 ?
学习路线指引(点击解锁) | 知识定位 | 人群定位 |
---|---|---|
? Python实战微信订餐小程序 ? | 进阶级 | 本课程是python flask+微信小程序的完美结合,从项目搭建到腾讯云部署上线,打造一个全栈订餐系统。 |
?Python量化交易实战? | 入门级 | 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统 |
变更是运维工程师最经常参与的一项活动,在重要变更进行之前,我们往往需要在组织内部进行变更评审,那变更评审的作用是什么,我们应当进行变更评审,本文与大家一起探讨。
当运维的组织超过一定规模后,一定要通过变更流程来进行管理,从而实现风险的有效控制,避免出现删库跑路的情况。变更管理的目标是提高变更实施的计划性,规范生产变更实施的活动,这块如果要详细阐述内容非常多,大家可以参考 ITIL 相关流程设计。
不管采用什么样的变更管理流程,变更分析评审是变更顺利实施的重要保障,本文从以下几个方面来做变更评审。
- 变更影响评估是否清晰
- 变更窗口是否合适
- 变更时长控制是否合适
- 变更操作步骤是否清晰、简便
- 变更验证是否完备
- 变更回退方案是否完善
变更影响
在执行一个变更之前,我们首先要非常确切的知道变更的影响,例如是否会引起联机业务中断,会影响哪些用户,和批量业务的时间是否冲突,是否会影响上下游的系统。
这就要求我们运维一个系统时,不管要知道自己运维的技术组件,还要深刻理解系统之上运行的各项业务。
变更影响的分析结果,会直接影响我们的「变更窗口」和「变更时长」的选择。如果是对一个集群模块进行维护,例如 Apache 组件,因为支持优雅重启,我们甚至可以选择在业务高峰时段进行变更。如果是一个需要停机的版本变更,我们则只能选择没有业务或者业务低峰的时候执行。
操作步骤
变更方案是指导我们具体实施变更的最后一份材料,我所在的单位会将变更方案体现为变更控制表,变更控制表的基本格式包括以下要素。
阶段 | 操作内容/目的 | 目标主机/目标网址 | 用户名 | 详细操作步骤 | 开始时间 | 完成时间 | 操作人 | 验证方法 | 复核人 |
---|---|---|---|---|---|---|---|---|---|
准备阶段 | 备份应用 | hostname_ap1001 | root | cp x x.bak | xx | xx | A | diff xx | B |
实施阶段 | |||||||||
验证阶段 | |||||||||
应急回退 |
按照这个格式整理变更方案的好处是步骤和操作内容非常清晰,任何人拿到控制表都可以操作。当然,按照这个标准准备控制表会耗费时间,有些人觉得投入太不值得,很简单的变更,可能两个人沟通几句话就可以说明白,要是写出来则要很久的时间。
从运维的严谨性上来讲,我们要保证99.99%的系统可用性,除了在技术上不断完善提高高可用外,在操作中一定要贯彻「审慎、细致、严格、踏实」的原则,唯有这样,才能形成良好的运维习惯,确保在自己的运维工作中不犯低级错误,避免损失。
验证方案
验证方案是在变更控制表中验证阶段执行的步骤,版本投产往往是开发项目组进行功能上的验证,这就包含很多的方法本文不再赘述。对于非版本类的变更,运维人员尽量将验证方案规范化、细致化,例如本次变更是对一份有问题的数据进行清理,那就需要明确本次执行的SQL会影响多少条数据,实际执行完后,检查是否确实修改了多少条数据。
严丝合缝的完成整个变更过程。
回退方案
任何变更都有失败的可能,也随时有可能收到回退的指令。因此一个没有考虑回退方案的变更是不完整的。
在某些极特殊的场景下,可能确实没有办法做到完全回退,例如我们要对用户系统的ID生成规则做一次转换的变更,当数据转换完成开始接收新的业务时,就可能无法再回退了。这种情况下,我们需要设置好必要的决策点,在决策点到来后,进行必要的技术/业务验证,来决定是继续还是回退。
关于变更的内容,其实还有很多实用的技巧,也欢迎大家与我沟通在实际运维过程中,如何避免犯错。
转载请注明:xuhss » 变更审核时我们审什么