故障恢复后的 Failback 如何设计？

简化版

Failback 不是原站点一恢复就把流量切回，而是先 fencing、修复数据、验证容量和依赖、预热，再按小比例回流；任何异常都能退回当前稳定站点。回切期间必须明确写主权和数据同步方向，防止双主与旧数据覆盖新数据。

先确认故障根因已消除，恢复站点的版本、配置、密钥和依赖与当前生产兼容。以当前主站为权威，将切换期间数据增量回补到原站并校验业务不变量；原站在追平前保持只读或无写权。

随后预热缓存和连接，用影子读/比对验证，再按 1%→5%→20%→50%→100% 回流。每阶段观察错误率、P99、数据差异和复制 lag。写权切换使用 epoch/租约原子完成，旧主立即被 fencing；稳定观察后才清理临时资源。

灾难切换通常方向单一，而恢复后两边状态已不对称：新站承载了新写，旧站可能停留在故障前，还可能版本落后。直接恢复流量会把用户送到旧数据，直接恢复写权则可能形成第二条时间线。

记忆钩子：Failover 解决“先活下来”，Failback 解决“带着事故期间的新事实安全回家”。

任何关键项不满足都不应为了“恢复原架构”强行回切。当前灾备站稳定运行时，延迟回切通常比冒险更安全。

切换期间新站是权威写主，旧站恢复后先作为追赶副本。通过日志位点、CDC 或回补任务复制新数据，使用版本条件防覆盖。若故障时旧站曾继续写，则先生成冲突清单，资金类按业务流水裁决，不能简单 LWW。

disaster-site primary(epoch=52) -> catch-up -> recovered site(read-only)
verify -> transfer write lease(epoch=53) -> fence disaster-site old lease

空缓存站点直接接 50% 流量会造成数据库回源洪峰。先加载热点 key、建立连接和 JIT 预热，再复制一部分读请求做影子比较，但影子写必须禁止副作用。若 10 万次影子读有 50 次关键字段不一致，差异率 0.05% 仍需解释后再推进。

影子验证也看延迟和错误，不能只比响应体；某依赖出口 IP 未加白名单会在真实回流时立即失败。

先回只读或低风险流量，再逐级扩大。每阶段要求最少样本和观察窗口，例如 1% 至少 15 分钟且 5000 次请求。写流量切换比读流量更谨慎，应通过租约/epoch 原子转移，保证任一时刻只有一方有写资格。

只读回流：1% -> 5% -> 20% -> 50% -> 100%
写权转移前护栏失败 -> 读流量退回 0%，灾备站仍是权威写主
写权转移后护栏失败 -> 先停新写，再以更高 epoch 受控转回并补齐差异

写权转移前，回退只是流量操作；写权转移后，恢复站已经产生新写，不能把流量直接指回旧权威站。此时必须把反向切换当成新的受控写权迁移，重新执行数据追平、fencing 和验证。

100% 回流不等于结束。继续观察一个业务峰值，确认复制方向、积压、缓存命中、业务成功率和对账稳定。临时 DNS、路由、人工开关和扩容资源按清单撤销，并保留原稳定站的快速退回能力。

记录每阶段耗时与人工动作，更新回切耗时基线和 Runbook。Failback 通常不计入已经恢复核心业务的 RTO，但仍应单独设定完成时限，避免系统长期停留在临时容灾拓扑。频繁回切失败通常说明环境漂移，应改进持续校验而不是只优化脚本速度。

Failback 按“根因确认—数据追平—环境校验—预热影子—阶梯回流—原子转写权—观察清理”执行。始终保持一个权威写时间线，每一步都有护栏和退路。恢复原拓扑不是目标，持续正确地提供业务才是目标。