很多团队做灾备演练中的切换验证，像一场彩排。脚本写得很细，几点几分点哪个按钮，谁盯哪块屏。大屏从红变绿，群里刷一排“成功”！然后呢？然后没人再碰它……真实故障不会按脚本走。业务流量、脏数据、长连接、定时任务，每一样都可能把“成功”掀翻。
切换验证的难点不在切。在验证。切过去只是动作，验证才是确认业务真的活着。活着的标准是什么？不是 curl 返回 200。也不是监控图上有线。是订单能下单，支付能回调，库存能扣减，对账能对平。说白了，得用业务事务去打脸。
先别急着看服务状态
切换一开始，最容易被迷惑的是服务状态。注册中心里实例都起来了，负载均衡后端健康检查全绿。看起来挺美。麻烦在于，应用连接池里还捏着旧数据库的地址。DNS 缓存没到期。长连接没断。配置中心推了新配置，但有些老进程没拉取。
我见过一次演练，应用切到新中心后，新用户请求正常。半小时后，零星报错开始冒。查到最后，是几个老节点的连接池没释放，还在往旧库写。旧库已经切成只读，写不进去。用户看到的是随机失败。这种问题，健康检查发现不了。因为健康检查只查端口，不查业务。
所以切换验证的清单里，得有客户端重连验证。不是重启应用就完事。得看连接池是否真正指向新地址。得看消息队列消费者有没有重新平衡。得看定时任务会不会在新中心重复触发。还有 DNS 的 TTL。平时设 300 秒，切换时恨不得 5 秒。可客户端不一定听话。JVM 缓存、操作系统缓存、HTTP 客户端缓存，一层层扒。
取舍也在这。全量重启应用最干净。代价是业务中断时间长。等待连接自然过期，中断短。代价是脏写窗口不可控。我的看法，核心交易链路别赌。该重启就重启。非核心链路可以灰度。这事没那么玄，就是算清楚哪个代价更疼。
数据一致性才是刀尖
服务起来了，数据对不上，等于没切。主从切换、存储复制、消息积压，这些才是刀尖。切换前要确认复制延迟。别只看秒级监控。要拿具体表、具体流水去比对。比如订单表最大 ID，支付流水总金额，库存扣减次数。数字对不上，就别切。
切换后更麻烦。原主库要确保只读。别出现双写。分布式 ID 会不会冲突。自增序列会不会跳号。消息队列的消费位点是不是最新。缓存里的数据是不是旧的。这些验证点，写脚本只能覆盖一部分。剩下得靠人。靠懂业务的人。
有个复盘我印象很深。某次演练，应用切过去看着正常。财务对账时发现少了十几笔。不是丢数据，是消息重复消费后被幂等逻辑吞了。消费位点回退，重试又失败。监控没告警。因为队列长度正常。这种坑，只有拿真实对账文件跑一遍才会露头。
所以验证要分层。基础设施层看网络、存储、计算。中间件层看队列、缓存、注册中心。业务层看核心事务。别把三层混在一起。混在一起，出了问题就互相甩锅。运维说网络通，开发说代码没改，DBA 说复制没延迟。最后发现是配置中心推错了一个开关。
回切才是照妖镜
很多团队练切换，只练去，不练回。这像什么？像出门不带钥匙……切过去成功了，回切时发现反向复制没开。新中心写的数据，回不到原中心。或者回切后，旧数据把新数据覆盖了。那场面，比不切还难看。
回切验证要盯反向同步是否追平，回切窗口内有没有新写入，回切后业务读到的数据是不是最新。听起来简单。做起来全是坑。比如回切时 DNS 又切一次。客户端缓存还没过期。部分流量打到旧中心，部分打到新中心。数据分叉。
还有人为因素。演练时有人临时改防火墙。有人忘了记录配置变更。有人把测试脚本里的参数带到了生产。这些不是技术问题。是流程问题。可切换验证偏偏最怕流程漏洞。因为技术故障有监控，流程故障没人告警。
我的建议很土。演练脚本要能重复执行。别搞一次性手工操作。每个验证步骤要有明确输出。成功是什么，失败是什么。谁签字。回滚条件是什么。触发回滚谁说了算。这些写清楚，比多买几台设备管用。
最后说个感受。切换验证不是看谁手快。也不是看大屏多漂亮。是看混乱里能不能把数据对平。能对平，再慢也算成功。对不平，绿灯亮得再齐，也是假的。