灾备演练中的切换验证别把走流程当真演练
上周跟南京本地某三甲医院的信息科主任喝咖啡，他吐槽刚结束的半年灾备演练，切到同城灾备节点之后，监控面板全绿，所有人都鼓掌，结果三天后门诊系统出问题，才发现演练当天切过去之后，医保接口的重试逻辑根本没走通——只是当时验证的人只看了主业务的响应时间，没人去测真实的医保结算请求。
灾备演练切换时多节点监控大屏实拍
很多人对灾备演练中的切换验证，认知停留在“主站挂了，备站能访问”。说白了就是拿个curl敲一下，看返回200就算过。麻烦在于，真实的业务流量不是只有一个首页请求。你切了流量之后，用户端的登录态能不能续？跨可用区的文件同步有没有延迟？那些跑了很久的批处理任务，会不会在切换瞬间直接中断？这些东西，全绿的监控面板是不会主动喊疼的。
我见过太多团队，把切换验证做成了单向的指标核对。CPU利用率多少，内存占用多少，接口响应时间多少，所有数字都在预设的阈值范围内，就算验证通过。至于这些指标背后对应的业务逻辑有没有跑通，没人深究。毕竟数字是不会出错的，对吧？真要出了问题，等真实用户投诉了才发现，那时候演练的意义在哪？
说真的，这事我踩过的坑能凑满半本笔记。三年前帮某零售企业做灾备演练的复盘，他们的演练脚本还是2020年写的，里面的验证项列了十几个，从门店的POS系统到总部的财务报表模块，看起来覆盖得挺全。结果切到备站之后，新上的线上下单自提接口直接超时——因为写脚本的时候，这个模块还没立项，后续几次演练，负责这个模块的产品和开发根本没被邀请参与脚本评审。
灾备演练切换验证checklist手写批注稿
很多团队的演练脚本，更像是一份应付审计的材料，跟真实的业务现状完全脱节。每年更新的时候，就是把上一年的脚本拿出来改个日期，既不跟着业务迭代调整，也不做真实的场景推演。更有意思的是，脚本里的验证项，往往都是三年前核心的业务模块，现在这些模块要么已经下线，要么流量占比不到1%，而真正贡献了90%流量的新业务，从来没进过验证列表。
之前有个做互联网金融的朋友跟我算过账，他们每次演练要拉二十多个人，占整整一天的工作时间，最后花了大半天时间验证的模块，营收占比加起来还不到5%。真正的核心交易模块，因为大家觉得“上次测过没问题”，每次都跳过。这账算下来，怎么看都不划算。
别不信。
很多团队测切换，是在机房的跳板机上敲命令。跳板机的网络环境和真实用户的网络环境根本不一样。你在机房里测，备站的接口响应是50ms，但是真实用户在外面，跨运营商访问，可能要500ms，甚至直接超时——这种问题，你在机房里敲一百次curl也测不出来，机房内的测试结果永远代替不了真实用户的访问体感。
我之前碰过一个在线教育团队的演练复盘，他们在机房里测所有指标全绿，所有验证项都打了勾，结果演练结束之后，有个产品经理在自己家的联通宽屏下试了下，打开课程详情页要转八秒。查了半天才发现，备站的CDN节点根本没配对应的域名解析，机房内网访问的时候走的是内部缓存，根本不会触发公网的解析逻辑。
哦对了，上次还有个团队，切换之后才发现备站的日志收集规则没配，真出事的时候连故障定位的日志都没有，这才叫离谱。
灾备演练中的切换验证，从来不是为了给领导看的“我们的系统能扛住故障”的证明材料。它是你提前把所有会炸的雷，在可控的环境里挨个踩一遍。踩的时候疼点没关系，真炸的时候才不会死。
我每次跟运维团队聊起这个事，都觉得挺可惜的。花了那么多钱建的灾备中心，配了那么多服务器和带宽，最后因为验证环节偷工减料，真出事的时候顶不上用，这钱不就白花了？
别总说灾备演练是形式主义。形式主义的从来不是演练本身，是那些对着脚本打勾、盯着指标自嗨的验证环节。你真把用户的真实请求当成验证的标尺，把业务迭代的最新进展同步到脚本里，把测试的环境从机房挪到真实的公网场景里，演练的价值自然就出来了。
毕竟，省下来的验证时间，换不来真出事时的从容。
全绿的监控面板骗了多少人
很多人对灾备演练中的切换验证，认知停留在“主站挂了，备站能访问”。说白了就是拿个curl敲一下，看返回200就算过。麻烦在于，真实的业务流量不是只有一个首页请求。你切了流量之后，用户端的登录态能不能续？跨可用区的文件同步有没有延迟？那些跑了很久的批处理任务，会不会在切换瞬间直接中断？这些东西，全绿的监控面板是不会主动喊疼的。
我见过太多团队，把切换验证做成了单向的指标核对。CPU利用率多少，内存占用多少，接口响应时间多少，所有数字都在预设的阈值范围内，就算验证通过。至于这些指标背后对应的业务逻辑有没有跑通，没人深究。毕竟数字是不会出错的，对吧？真要出了问题，等真实用户投诉了才发现，那时候演练的意义在哪？
别全信脚本里写的验证项
说真的，这事我踩过的坑能凑满半本笔记。三年前帮某零售企业做灾备演练的复盘，他们的演练脚本还是2020年写的，里面的验证项列了十几个，从门店的POS系统到总部的财务报表模块，看起来覆盖得挺全。结果切到备站之后，新上的线上下单自提接口直接超时——因为写脚本的时候，这个模块还没立项，后续几次演练，负责这个模块的产品和开发根本没被邀请参与脚本评审。
很多团队的演练脚本，更像是一份应付审计的材料，跟真实的业务现状完全脱节。每年更新的时候，就是把上一年的脚本拿出来改个日期，既不跟着业务迭代调整，也不做真实的场景推演。更有意思的是，脚本里的验证项，往往都是三年前核心的业务模块，现在这些模块要么已经下线，要么流量占比不到1%，而真正贡献了90%流量的新业务，从来没进过验证列表。
之前有个做互联网金融的朋友跟我算过账，他们每次演练要拉二十多个人，占整整一天的工作时间，最后花了大半天时间验证的模块，营收占比加起来还不到5%。真正的核心交易模块，因为大家觉得“上次测过没问题”，每次都跳过。这账算下来，怎么看都不划算。
验证的颗粒度要贴真实用户的体感
别不信。
很多团队测切换，是在机房的跳板机上敲命令。跳板机的网络环境和真实用户的网络环境根本不一样。你在机房里测，备站的接口响应是50ms，但是真实用户在外面，跨运营商访问，可能要500ms，甚至直接超时——这种问题，你在机房里敲一百次curl也测不出来，机房内的测试结果永远代替不了真实用户的访问体感。
我之前碰过一个在线教育团队的演练复盘，他们在机房里测所有指标全绿，所有验证项都打了勾，结果演练结束之后，有个产品经理在自己家的联通宽屏下试了下，打开课程详情页要转八秒。查了半天才发现，备站的CDN节点根本没配对应的域名解析，机房内网访问的时候走的是内部缓存，根本不会触发公网的解析逻辑。
哦对了，上次还有个团队，切换之后才发现备站的日志收集规则没配，真出事的时候连故障定位的日志都没有，这才叫离谱。
灾备演练中的切换验证，从来不是为了给领导看的“我们的系统能扛住故障”的证明材料。它是你提前把所有会炸的雷，在可控的环境里挨个踩一遍。踩的时候疼点没关系，真炸的时候才不会死。
我每次跟运维团队聊起这个事，都觉得挺可惜的。花了那么多钱建的灾备中心，配了那么多服务器和带宽，最后因为验证环节偷工减料，真出事的时候顶不上用，这钱不就白花了？
别总说灾备演练是形式主义。形式主义的从来不是演练本身，是那些对着脚本打勾、盯着指标自嗨的验证环节。你真把用户的真实请求当成验证的标尺，把业务迭代的最新进展同步到脚本里，把测试的环境从机房挪到真实的公网场景里，演练的价值自然就出来了。
毕竟，省下来的验证时间，换不来真出事时的从容。