凌晨两点十七分，切换窗口打开。主库停写，备库接管。延迟曲线掉到零，会议室里有人低声说了句成了。
三分钟后，订单服务开始报错。
连接池里还留着旧地址；DNS缓存没到期；一张服务证书前一天刚过期。三件小事，没有一件写在演练手册的第一章里。
这种场面我见过不止一次。说白了，大部分灾备演练，练的是流程熟练度，不是容灾能力。
演练的目标不该是切换成功率
很多团队把指标定成“切换成功率百分之百”。听着挺提气，但这指标有毒。为了刷它，剧本越写越细，时间越来越固定，参与的人越来越是同一批老面孔。练到第三次，闭着眼都能过。
真实故障不长这样。
它挑凌晨三点来，挑能拍板的人手机关机的时候来。它还经常顺手把主中心的监控、日志、跳板机、CMDB一起带走——这些东西恰好都部署在主中心。切过去之后你连“自己切没切成功”都看不见，只能靠打电话问业务那边有没有人下单。
所以演练真正要抓的，是那些切不过去的点。一个连接池，一条DNS记录，一张证书。不是那份漂亮的切换耗时曲线。
纸面上的RTO和RPO最容易骗人
RTO三十分钟，RPO零丢失。这行字写在方案首页，写了三年没人动过。
问一句：这三十分钟从哪一刻开始算？故障发生那一秒，还是有人确认这是故障的那一刻？中间那段“人发现、人上报、人判断”的时间，经常比切换本身还长。
RPO为零，一般靠同步复制撑着。可跨城链路几十毫秒，同步复制会把主库的写入延迟一起拉起来。业务能不能忍这个延迟，是另一个问题，而且往往是要单独谈的问题。谈不下来，就改异步，RPO变成几分钟——但PPT上没改。
还有一件事更容易被混过去：备份演练不等于灾备演练。这俩经常被塞进同一张表里，打一个勾了事。真出事的时候得想清楚：是先恢复备份，还是先切备中心？如果备份没有异地副本，那备份和主库在同一个机房里一起遭殃。恢复时长必须实测，不要估算。磁带库、对象存储、归档系统，取回延迟能差出十倍，这个差距平时看不出来。
回切比正切难得多
几乎所有演练都只练正切。生产切到备中心，跑一遍业务，收工合影。
麻烦在于，故障修好之后你得切回来。
这时候数据是双向的。备中心跑了四十八小时，产生了新数据；主中心修好了，还停在两天前。谁覆盖谁？这个问题没有通用答案。要么停业务做反向同步，要么接受一段时间的双写，然后老老实实处理冲突——而冲突解决策略，在演练里基本是被跳过的章节。不测回切，等于只演了一半。
还有些低级但高频的坑。备中心的NTP源还指向主中心，切过去之后集群时间开始漂移，分布式事务报错，证书校验失败。日志采集的端点也在主中心，于是切换后那两小时是观测黑洞。破事，但足够让一次切换变成一次事故。
流量切进来才算数
只切组件不切流量，等于在停车场练开车。
有条件的话，灰度切百分之一的真实流量到备中心，看两条链路的行为差异。数据库读到了，缓存没命中，异步任务重复消费了——这类问题只有真流量能钓出来。代价是什么？备中心的数据会被污染，回切时更麻烦。取舍就在这儿，想做就得提前设计隔离和清理方案，做不到就别假装切过了。
组织上的事，技术解决不了
谁有权按下切换开关？
是运维负责人，还是业务负责人？如果切了之后发现是误判，损失谁背？这些问题在事故当天是来不及讨论的，你只能在会议室里听两拨人互相看。
有些团队把决策权前置：定好技术触发条件，达到条件自动切，不要人拍板。代价是可能误切。切慢了业务受损，切错了业务也受损，就是这么个二选一的账。
演练计划里还该有一栏，要业务方签字确认数据丢失容忍度。嘴上说能丢五分钟的人，真丢了三分钟就开始追责。白纸黑字提前写下来，比事后吵架体面得多。
怎么把这件苦差事做得有点用
我倾向于降频，但加难度。
一年四次不如一年两次，但这两次不给剧本、不预告具体时间、不指定参与人。让当天值班的人上手，让没参与过项目的人上手。他们踩的坑才是真坑。
成功标准也换掉。不是“切换完成”，而是“切换后核心业务自检通过”。自检脚本提前写，覆盖下单、支付、查询这几条主干链路，跑到全绿才算过。
复盘文档别写结论，写清单。谁、在什么时间、做什么、什么时候做完。结论会被忘掉，清单不会。
最后一句闲话。把演练里发现的配置漂移、文档过期、应急联系人已离职这堆小事，也一起记下来。灾难来的时候，绊倒你的多半就是这些。它们太小了，小到不配写进方案，但足够让你在凌晨三点多打半小时电话。