凌晨三点，没人敢按下的‘切换’键：一份灾备技术方案现场笔记

告警群响的时候，是凌晨三点零七分。不是演练。核心库所在机房的一路市电抖了，空调跟着喘，监控曲线像心电图掉坑。业务负责人在电话里问我：切不切？

我没法秒回。那套灾备技术方案在共享盘里躺了半年，目录很整齐，封面很漂亮，真到这一刻，像楼道里的消防栓——你知道它在，但不一定拧得开。说实话，手心是汗的。

很多人以为灾备就是“备份加一个备用机房”。不对。备份解决的是“数据还在不在”，灾备解决的是“业务还能不能跑”。中间隔着一条河，河上那座桥叫切换。

数据中心灾备切换指挥台大屏告警场景

备份跑成功，不等于你敢切

我见过太多备份报表绿油油，真出事却不敢动的现场。为啥？备份文件在，恢复脚本找不到；脚本找到了，依赖的密钥在另一台机器；机器起来了，DNS还指着旧地址。每一样都不大，凑在一起就是灾难。

灾备技术方案里最值钱的部分，不是买了几套存储，也不是拉了几条专线。是切换决策：谁拍板、看哪些指标、容忍丢多少数据、切过去之后谁验证。没有这三行字，设备越多越乱。

那次我们没立刻切。先看复制延迟——异步复制落后了八分多钟。八分钟听着不长，订单库里可能压着几百笔支付回调。切过去，这些单子就悬空。财务第二天对账会骂人。可如果不切，主库继续抖，可能连这八分钟都保不住。

你看，灾备从来不是技术单选，是带疼痛的取舍。

RPO和RTO不是两个数字，是两笔账

RPO，恢复点目标，说白了是“你能接受丢多久的数据”。RTO，恢复时间目标，是“你能接受停多久的业务”。这两个词在方案里常被写成两个漂亮数字，落到业务侧，其实是两笔账。

一笔是钱。交易停了，每分钟损失多少；另一笔是信任。用户下完单没看到结果，转头去别家。这个损失报表里不写。

所以别拿一个统一RPO套所有系统。订单库和内部周报库能一样吗？前者丢三十秒都肉疼，后者丢一天可能没人发现。灾备技术方案要分层，别怕麻烦。同步复制听起来硬气，主库写完必须等备库确认，可距离一远，延迟就上来了，业务先喊卡。异步复制跑得快，代价是灾难瞬间可能丢一截。还有半同步、快照、日志归档，各有各的脾气。

数据库异步复制与事务日志恢复流程图

我常打个比方：备份像拍照，复制像录像。拍照能回到某个点，但中间动作没了；录像连贯，可带子断了就断在那。真要做灾备技术方案，得拍照加录像，再配一本“怎么放”的说明书。

那次最后怎么处理的？没切。先降级非核心查询，把主库压力卸掉，等复制追平到三十秒以内，再按预案做了只读切换演练。对，演练。真故障里做演练，听着荒诞，但比盲切强。业务负责人后来吐槽：你们这预案写得像菜谱，真炒菜还得尝咸淡。我认。菜谱不尝，盐会死人。

双活不是万能药，脑裂才是暗礁

不少老板一听灾备就问：能不能双活？两边都跑，谁也不闲。能，但有前提。双活最怕脑裂——两个站点都觉得自己是主，各写各的，最后数据打架。解决要靠仲裁、租约、 fencing，说白了得有个裁判，还得能把输的一方按住。

跨城双活更别拍脑袋。链路抖动、时钟偏差、应用没做幂等，随便一个都能让“双活”变成“双慌”。我见过一个团队，双活上线三个月，最忙的是对账脚本。为啥？重复扣款、重复发券，用户乐了，财务哭了。

所以灾备技术方案里，故障域要画清楚。机房、机柜、可用区、云账号、甚至同一个交换机，都可能是故障域。你备了机房，结果两个机房走同一路光缆，这不叫灾备，叫合租。

真正难的是切换之后：回切、脏数据和肌肉记忆

很多人把切换成功当终点。错。切换只是上半场。下半场是回切。旧中心修好了，数据怎么倒回去？新中心期间产生的增量怎么办？应用版本不一致怎么办？这些问题不写进方案，回切那天就是第二次事故。

还有脏数据。切换瞬间没提交的事务、重复消费的消息、半截子的文件上传。灾备技术方案得留出对账和补偿的窗口，别指望数据库自己擦干净。

再说演练。别搞成会议室念PPT。桌面推演要有，空跑要有，灰度切一小块流量更要有。演练不是为了证明方案完美，是为了把人的肌肉记忆练出来。凌晨三点没人想翻三百页文档，大家只会找那个最熟的人。演练就是让至少两个人熟。

灾备演练切换操作手册与回切检查表现场

我们后来给那套方案加了三样东西：一页纸的切换决策卡，谁签字、看哪三个指标；一份回切检查表，精确到DNS TTL和证书有效期；还有每季度一次的二十分钟盲演，不提前通知，只给故障现象。第一次盲演很狼狈，有人把测试库当生产库连。好事。总比真事强。

边界：灾备不是万能护身符

边界：灾备不是万能护身符

说句冷话，灾备技术方案救不了所有场景。逻辑删除、勒索加密、供应链投毒，这些故障会跟着复制跑到备中心。你同步得越快，脏数据传得越远。所以不可变备份、离线副本、权限隔离得单独设计。别把鸡蛋放在一个“实时复制”的篮子里。

还有成本。RPO越接近零，RTO越短，钱越像自来水。方案评审时最怕听到“我们要最高等级”。先问业务：停一小时到底损失多少？答不上来，就先做分级。核心交易、内部办公、数据分析，各给各的预算和指标。别一刀切，切不起。

最后提醒一个常被忽略的坑：依赖清单。DNS、证书、密钥、镜像仓库、监控探针、第三方支付回调地址。主中心倒了，这些小家伙可能还在原地发呆。灾备技术方案不盘依赖，切换时就会像搬家忘了带钥匙——人到了，门开不了。

那晚我们熬到五点多，复制追平，业务没停。天亮后我在群里发了一句：方案得改，切换卡太厚。有人回：早该改。你看，灾备这事，平时嫌它烦，出事嫌它慢。可真正救命的，往往就是平时被嫌烦的那几页纸。