上周跟一个做金融IT的老大哥吃饭，他灌了半杯冰啤酒才开口，说刚搞完年度灾备演练，累到想直接把工位搬去ICU。
别把“页面能打开”当切换成功
见过太多团队的验证标准，还停在表层。切到灾备节点，登录页能弹出来，截图发工作群，所有人鼓掌，收工。
上次跟某城商行的运维聊，他们前两年的演练就是这么做的。结果三天后接了几十笔客户投诉，说转账输完密码点确认，转半天没反应。翻日志才发现，灾备节点的数据库连接池配置少了两个零，并发稍微上来就卡死。当时群里的庆祝消息还没撤，所有人对着满屏的报错，脸都绿了。
说白了，切换验证最容易踩的坑，就是只看表层的通断，不摸业务链路的真实负载。很多团队做验证的时候，拿自己的测试账号点两下，流程走通了就算完，根本不管真实用户的行为是啥样的。那些藏在链路边角的配置错误，不到真实负载压上来根本露不出来。
比如电商的订单链路，不是你点一下提交订单就算完，得看库存扣减对不对，优惠券核销有没有漏，支付回调能不能正常进系统，甚至连物流信息能不能同步给外部接口，都得算在验证范围里。真的，见过太多团队在这上面栽跟头，栽完了还觉得是灾备中心的硬件不行，冤不冤。
验证的颗粒度得跟着真实故障的场景走
很多演练的场景设计，从根上就飘着。比如设计的故障是“主中心整网断网”，那验证的时候就不能只看灾备中心的系统能不能跑，得看切过去之后，跨中心的专线延迟会不会影响实时交易，那些需要和线下网点交互的业务，比如ATM的取款，会不会因为灾备节点的路由配置错了，导致交易卡在半路上。
别拿预设的理想测试用例，去套真实世界里乱七八糟的故障。之前有个做高端装备制造的企业，去年演练的时候，特意模拟了主中心存储宕机的场景，切到灾备之后，验证的时候只查了MES系统的生产工单能不能读，就打了满分。结果真碰到存储故障那次，才发现灾备节点的历史工单索引没同步，车间工人查去年的同类型设备故障记录，卡了二十多分钟，整条生产线停了快半小时。
麻烦在于，很多团队的验证清单，是三年前写的。三年里业务迭代了八版，清单上的条目还停留在最初的那几个核心系统。现在企业里新上的智能客服，对接的知识库，跑在云原生节点上的实时数仓，这些系统在切换之后能不能正常跑，根本没人在演练的时候专门验证。等到真出故障了，才发现这些新系统的灾备配置根本没同步，智能客服接不上知识库，用户打电话过来全是机械的“您的问题我暂时无法解答”，比系统崩了还招骂。
切回来的验证才是最容易被漏掉的环节
绝大多数人做演练的时候，注意力全在从主中心切到灾备中心的过程上。等切回主中心的流量一挂，所有人都松了口气，觉得演练结束了，收拾东西准备去吃庆功宴。
谁管切回来之后的数据有没有双向同步？谁管灾备中心跑了两个小时产生的交易数据，有没有完整回传到主中心？之前碰到过一个做本地生活服务的互联网公司，演练的时候切到灾备跑了一个半小时，切回来之后就直接关了灾备的监控，结果过了一周对账的时候才发现，那一个半小时里产生的近千笔用户充值记录，全存在灾备的本地存储里，没同步回主库。用户找过来投诉，说充了钱账户没余额，折腾了快两周才把所有数据补全，被用户骂到现在还留着差评记录。
切换验证从来不是单向的流程，来回双向的链路校验，才是真的能扛住故障的底气。
说实话，我见过不少团队，把灾备演练做成了一年一次的表演。领导在现场看着，运维点几下鼠标，切流量，弹个成功的提示，拍个大合影，写个几千字的演练总结报告，交上去就算完事。
别觉得做这些是浪费时间。真等故障砸到头上的时候，你就知道现在多花半小时做全链路验证，能省下来后面几十个小时的救火时间。上次跟那个金融IT的老大哥聊完，他说今年改了演练的流程，不再搞表演式的切换了，每次演练的时候，专门留两个小时做逐节点的链路验证，连之前漏掉的日志同步任务都加进了清单里。
我问他累不累。
累是累。
但是上次真碰到主中心核心路由器宕机，切到灾备之后，所有业务稳得一批，连平时最容易出问题的月度报表系统都没卡，那种踏实感，比喝十瓶冰啤酒都爽。