记一次差点翻车的生产变更

今天不谈技术，讲一下前不久变更差点翻车的事。

背景：因为安全原因，需要对生产上运行的windows服务器进行打补丁操作，由于是内网环境，只能离线方式进行升级。

配置说明：

A1和A2组成一套环境，B1和B2组成一套环境，两套环境互为主备。

变更准备：

1.下载离线补丁包；

2.测试环境补丁升级；

测试环境与生产环境操作系统相同，离线包在测试环境升级时不是很顺利，直接打到最新的11月份的补丁包失败，摸索着由2017年的补丁一步一步往后打，可以打到2020年1月份。

变更实施：

由于测试环境打补丁只能到1月份，初步计划生产环境4台服务器也只打到1月份。

23：30，变更正式刚开始。按计划先将第1台打到了1月份，操作很顺利，这时做了一个关键的临时决定，试着直接打到最新的补丁包，结果有惊喜，居然打成了。好吧，那就临时改计划，将剩余的3台都升级到最新的补丁包。

前两台进行的很顺利，第3台和第4台的时候卡住了。打补丁会重启服务器，正常情况10分钟就应该启起来，20分钟过去了还是ping不通连不上，没得辙，只能去机房捅屁股了（现在系统都上云了，去机房的机会越来越少了）。这时快3点了。

果然，第3台在系统更新的时候卡住了，硬重启系统恢复。

关键的4台，居然崩溃了，是的，系统进不去，崩溃了……

晚上变更容易犯困，看到进不了系统，困意全无，肾上腺素飙升。

时间来到快5点了，系统已经进不去，这时做了4个操作：1.停止第3台的补丁升级操作；2.咨询厂商，有无解决方案；3.通知系统使用方，做好切换准备；4.想办法恢复系统。

变更之前通知过厂商晚上保障，预料过打补丁可能会失败，但是没想到系统直接会崩溃，没办法，事到如此，只能硬着头皮上了，自己挖的坑，含泪也要填。

第一轮的自救不理想，厂商没有解决办法，自己百度的解决办法也不成功。这时只能做最坏打算了——重装系统和应用。

同时通知科室领导，说明情况；通知厂商，做好打飞的初始化系统的准备。自己也根据报错提示不断寻找解决办法，死马当活马医吧。这个时候压力其实还是很大的，毕竟是生产系统，再过两个小时就是业务高峰期。

时间快6点了，尝试了各种办法，做了两个win pe，尝试回退补丁，不成功，没办法，现在能做的只能尝试更多的办法，终于，有一个方案成功了，成功了，直接重置启动项，居然进系统了，惊喜不惊喜，开心不开心。

系统恢复后，对应用做了各项检查，运行正常，决定补丁暂停升级，通知科室经理、厂商、业务方系统恢复。

各项处理完快7点了，肚子很饿，精神却很好，天也亮了，吃个早餐吧，打工人不能太亏待自己。

复盘：

1.变更前的测试

变更前的测试影响变更成败的关键，无论变更大小，只要有条件都应该进行测试。比如系统类的扩文件系统、扩表空间、文件清理、系统参数调整；应用类的新业务上线、应用切换、漏洞升级等。只有经历过充分的测试，才能做到胸有成竹，生产上遇到问题也不慌。

2.变更实施

变更要有手册，手册规定了操作步骤，命令可直接复制执行，执行完后的结果有截图，异常情况有回退方案。

变更实施应严格按测试结果执行，切忌临时更改方案步骤。变更的操作只是机械的执行，主要工作都在变更前的准备测试阶段。小到日志清理，大到两中心异地切换，变更实施都应该按手册规范执行。

3.异常流程

生产上的变更会遇到各种问题，千奇百怪，可能测试环境和生产环境一样(相同的操作系统版本、应用版本)，但是执行结果不一样，也有可能服务器在测试区各项测试都很正常，上了生产区却有问题了。

出现这些问题很正常，因为我们不能考虑到所有场景、环境、配置，这时应急流程就很重要了。出现了暂时无法解决的问题，需要有一套完善的应急预案和异常流程，这既是对自己减压，也是尽可能降低对业务影响。

4.故障解决

出现的故障没关系，解决它就是，运维就是填坑背锅的嘛，填不了坑就光荣的背锅。

故障的解决和个人的经验和知识储备有关，这个没有捷径，只能多学多做测试多总结多记录了。

5.经验教训

这次是这些年来第二次变更遇到重大重大问题，第一次是服务器直接起不来。

运维的日常工作很繁杂，要会很多技术，知识面要求很宽，而且要不断学习。

对服务器、对生产环境、对各种技术，要有敬畏之心，这些是我们工作的朋友伙伴，要善待它们而不是轻视或者藐视。

作为一个运维人，我很自豪，以上只是个人的一个小感触，仅代表个人观点，不接受反驳，哈哈哈……