灾备演练中的切换验证别被纸面流程骗了

上个月跟着跑了三次跨城灾备演练，每次复盘都能揪出一堆之前拍胸脯说没问题的验证漏洞。很多团队一提灾备演练，第一反应是把切换流程走一遍，把清单上的项打个勾，就算交差。真不是这么回事。

别把验证清单当万能护身符

我见过最夸张的一份验证清单，是2019年的版本，直到2024年还在原样用。上面列的验证项全是泛泛的连通性检查，什么主备数据库端口可达，什么中间件集群节点在线，什么应用实例能正常启动。真切换到备用节点跑实际业务的时候，支付渠道的回调IP白名单没加，用户付了款的订单卡了二十分钟没生成，运营那边的告警短信发了几百条，才发现漏了这个配置。

纸面勾选的通过率100%，不代表业务真的能跑通。很多人做验证的时候，只测链路通不通，不测流量扛不扛得住。切换完测个单接口的返回，200就打勾，根本不会模拟日常三分之一的峰值流量压上去。上次碰到个团队，切换完接口确实能返回，结果一压测，CPU直接冲到90%，响应时间从平时的200ms涨到3秒，离用户投诉只差临门一脚。真的。

说白了，清单是死的，业务是活的。每年迭代加的新功能、新依赖、新的第三方对接接口，根本没人同步更新到验证清单里。照着三年前的清单打勾，能验出问题才怪。

比清单过时更离谱的，是很多团队对验证时长的误解。

切换后的等待期才是验证的重灾区

大部分团队的演练节奏是，从主节点切到备节点，等个十分钟，所有项都正常，直接宣布演练成功，大家收拾东西下班。麻烦在于，很多问题根本不会在切换后的十分钟里冒出来。

缓存预热要时间，下游第三方的异步回调要时间，跨节点的定时任务抢占锁、数据一致性校验，全是在切换后15到40分钟才会触发的。我之前碰到过一次演练，切换完成后半小时，财务系统的自动对账任务突然报错，查了半天发现备用节点的时区配置和主节点差了8小时，任务触发时间直接错位，等定位到问题的时候，已经错过了当天的对账窗口。

切换完成不是验证的终点，至少要覆盖一个完整的业务小周期。做电商的就得模拟一波整点的订单流量，做金融的就得等一次批量代扣的任务跑完，做内容平台的就得等一轮推荐流的缓存预热完成，不能刚切完就拍屁股走人。

更有意思的是责任划分。基础设施团队验完网络连通性就撤，中间件团队验完集群状态就走，应用团队验完自己的接口就交差，没人站在用户视角从头到尾走一遍完整流程。用户从选商品、加购、提交订单、用优惠券、付尾款、收到通知、申请退款，全链路走一遍？很少有人做。大家都在自己的格子里交差，拼出来的结果就是每个环节都正常，拼起来根本跑不通。对吧。

还有个几乎所有团队都会踩的坑，就是回切环节的验证被直接砍掉。

回切环节的验证经常被直接跳过

很多演练的流程设计是，主节点切到备节点，验证完，直接把备节点当长期主用，根本不做切回主节点的测试。但真的发生故障的时候，等主节点的故障修复完，总不能一直把备节点当主用吧？到时候回切的时候才发现，之前备节点上跑的那几个小时产生的业务数据，根本没同步回主节点，两边数据差了几十万条，这时候谁都兜不住。

很多团队为了赶演练进度，把回切验证直接从流程里删掉，理由是上次回切没问题，这次肯定也没问题。但上次的版本是三个迭代之前的，中间加了好几个分库的路由规则，改了好几次数据同步的逻辑，上次的经验早就不管用了。真到回切的时候，数据路由错了，同步延迟了，配置不匹配了，哪个问题都能造成线上事故。

其实灾备演练中的切换验证，从来不是为了给汇报材料添上“顺利完成”四个字。那些写在PPT上的漂亮通过率，真碰到故障的时候半毛钱用都没有。能救命的是你演练时多等的那半小时，是你站在用户角度多走的那一遍流程，是你没偷懒跳过的那一次回切。别等真的故障砸到头上，才发现之前的演练全是演给别人看的。