问他咋了。
他说切是切过去了，所有核心交易接口全通，页面加载速度甚至比主站还快，结果演练结束两小时，财务部的电话直接打过来——头天晚上跑的批量对账任务，数据差了整整两个批次。
切通只是及格线
很多人对灾备演练中的切换验证的认知，就停留在“能登系统、能点页面、接口不报错”这三个标准上。这东西，说白了就是给合规看的。你拿自己的管理员账号登上去，什么权限都有，点什么都能用，能说明啥？一线的柜员、客服、运营，他们的权限跟你不一样啊。之前有个朋友做零售系统的灾备演练，切到备站之后，运营登上去发现全部门的优惠券批量发放按钮灰了，为啥？备站的权限同步是两周前的，中间刚给运营组加了这个功能的权限，没同步过去。还好演练的时候发现了，要是真遇到主站机房断电，全部门的优惠券发不出去，那损失可不是一点半点。
更搞笑的是，很多人验证的时候，连账号都懒得换，就用自己平时的运维账号点一圈，完事打个勾。你怎么知道普通用户能不能用？你怎么知道没有权限的人能不能越权看到敏感数据？这些细节，没人盯，最后全是坑。
别被提前写好的脚本骗了
老周说他们这次演练，之前的验证脚本是提前一周写好的，列了87个核心接口，全是平时跑的最多的交易类接口，切完挨个用测试数据打，全绿。谁都没想到要测那个批量对账的异步任务——那玩意是每天凌晨自动跑的，平时没人盯着，演练刚好安排在周三下午，谁会想到手动触发一次？结果那任务切到备站之后，调度规则没同步，本来应该往备站的数仓写数据，结果直接绕回了主站的旧库，两批数据全写串了。老周那天晚上在机房待到凌晨三点，才把数据捋清楚，第二天眼睛肿得像核桃。
说白了，提前写好的脚本，本质上就是在演给别人看。真出故障的时候，哪有时间给你按脚本一步步来？你要测的，是那些不在脚本里的，平时没人注意的边角料功能——比如自动生成的月度报表，比如定时清理过期缓存的任务，比如用户提交的投诉工单自动同步到客服系统的链路。这些东西，平时没人管，真出问题的时候，全是能让你丢工作的雷。
异步任务是切换验证里最容易被忽略的盲区。因为这些任务大多是后台跑的，没有直观的页面反馈，你切完之后站在监控屏前面看半小时，根本看不出问题。等它跑完几个小时，数据脏了，你再想找问题，都不知道从哪下手。
回切才是最容易出事的环节
很多公司的灾备演练流程，就是切到备站，测半小时，没问题，直接切回主站，收工写报告。这完全是本末倒置。你在备站待的时间短，可能还没遇到那些需要跑几个小时才会触发的问题，更别说回切的时候了。老周说他们之前有次演练，切回主站之后，没人检查主备之间的同步链路，结果备站还在持续往主站写旧的缓存数据，过了三天才发现，两边的用户会员积分差了近万条，最后花了整整一周才把数据对齐。
灾备演练中的切换验证，从来不是只验证“能不能切到备站”，还要验证“切回主站之后，两边的数据能不能对上，同步链路能不能正常跑”。很多人觉得回切是小事，主站本来就是平时用的，能有啥问题？麻烦在于，你在备站跑的那几个小时，产生的所有数据，回切的时候都要同步回主站，要是同步链路有问题，要么数据丢了，要么两边对不上，后面全是烂摊子。
说实话，现在很多公司做灾备演练，本质上就是为了应付监管的要求，走个过场，脚本提前写好，每一步都有人盯着，连测试数据都是提前准备好的，当然全过。真遇到主站光纤被挖断，或者机房着火的情况，你之前练的那些东西，能用上多少？
没人想遇到真故障。
但你不能永远不准备。
灾备演练中的切换验证，说到底，就是要把真出故障时可能遇到的所有破事，提前在演练里踩一遍。别嫌麻烦，你今天少测一个接口，明天可能就要花三天擦屁股。