上周跟做运维的老周在烧烤摊撸串，他吐槽刚收尾的季度灾备演练。花三天搭临时环境，跑自动化脚本，切换验证环节走得比早高峰打卡还顺。结果上个月老机房临时跳闸，真实切流的时候，核心支付链路卡了整整四十分钟。他说这话的时候，烤筋刚端上来，他一口没吃，就盯着杯子里的冰可乐叹气。
别把“切得动”当“切得对”
多数团队做切换验证，停留在最浅的层面。主节点流量摘下来，灾备节点监控面板绿灯亮了，前端页面能打开，就算过。最容易踩的坑就是把链路通断等同于业务可用。
之前接触过的一个零售团队，去年演练的时候，切完灾备节点，所有监控全绿，页面秒开，接口响应正常。等演练结束复盘，才发现灾备端的库存数据同步延迟了15分钟。要是真遇到主机房故障，切过去的那一刻，全平台的商品库存都是错的，用户下单全是超卖，后续的客诉能把客服部门的电话打炸。
说白了，链路通了只是第一步。你总不能因为水管通了，就说家里的饮用水能喝吧？很多人怕演练的时候出问题，特意把核心链路的校验脚本简化，就为了能顺顺利利走完流程，给领导看个漂亮的演练报告。真遇到事的时候，这些简化的脚本半毛钱用都没有。
验证的颗粒度，要贴到真实业务的疼点上
我见过太多团队的灾备验证用例，是三年前系统刚上线的时候攒的。业务早迭代了八版，新增了直播带货链路，加了跨区域的物流调度模块，接了好几个第三方的支付渠道，验证用例还停留在“用户能不能正常登录”的层面。这不是搞笑吗？
真正有效的切换验证，根本不是对着监控面板数绿灯，是要把真实业务场景拆成可落地的校验动作。比如验支付链路，不能只测支付网关能不能连通，要把从用户点提交订单、到支付回调、到银行对账、到财务记账的全流程走一遍，确认每一个环节的参数都对得上。比如验CRM系统，不能只说系统能打开，要测不同权限的运营账号登进去，能不能看到自己负责的客户数据，会不会因为灾备端的权限配置没同步，出现越权或者看不到数据的问题。
别嫌麻烦。很多团队演练的时候，特意把生产流量降到原来的十分之一再切，美其名曰“降低演练风险”。测出来的结果根本没有参考价值——真出故障的时候，没人会提前给你打招呼降流量，所有的用户请求都是全量冲过来的，你平时测的低流量场景，根本扛不住真实的峰值压力。
别等切完了才想起要做验证
多数团队的演练流程是：先把主节点的流量摘掉，切到灾备节点，等个十分钟，然后挨个点页面查状态。顺序从根上就错了。
切换验证的动作，是要嵌到切换流程的每一步里的，不是切完之后的收尾环节。比如切DNS的时候，就要立刻查全国各个运营商的解析结果，是不是真的把域名指向了灾备节点，有没有哪个地区的解析缓存还留在主节点，导致用户访问的时候绕了半天，还是进了已经停服的主机房。比如切数据库的时候，要在主库停写的瞬间，就盯着灾备库的写入延迟，是不是在业务可接受的范围内，有没有出现个别表的数据没同步过来的情况。
甚至连回切的验证，都要提前嵌到流程里。很多团队只练过从主节点切到灾备节点的流程，从来没认真验过切回主节点的环节。不少人都栽在这上面——故障恢复的时候急着把流量切回主节点，没做回切前的数据一致性校验，把灾备端存的交易数据全冲掉，光对账就得耗掉整整一个通宵。
还要提一句，别全靠自动化脚本做验证。那些脚本覆盖不到的老外围系统——比如财务用来导出工资表的旧系统，比如行政用来查固定资产的内部平台，切完之后得有人手动点一遍。这些系统平时没什么流量，脚本根本不会纳入监控范围，真出问题的时候，才知道这些边角料的系统，缺了哪一个都影响正常办公。
老周那天最后跟我说，他们今年把验证清单全换了。不再数监控面板的绿灯。每一项验证都对应到具体的业务场景，连“切完灾备端能不能正常给用户发验证码”这种细碎的动作，都列到了必须检查的条目里。他说之前总觉得灾备演练是给合规部门交差的事，现在才明白，真到要切的时候，那些你没认真验过的环节，全是等着爆的雷。