验证你的灾难恢复承诺：从受控测试到真实环境就绪
内容提要
文章指出单次计划演练只能证明机制可用，无法暴露协调、依赖和预置资源等真实隐患，建议采用四级递进验证：桌面推演明确责任与边界，计划切换测量实际RTO/RPO，突袭演练检验执行准备，故障注入演练发现未建模依赖；每级发现的问题应反馈到恢复边界、业务目标和依赖承诺三项决策，持续迭代强化灾难恢复能力。
延伸解读
单次演练的盲区：机制可用不等于恢复就绪
文章指出，提前通知的计划演练只能证明故障切换机制本身可用，却无法暴露真实恢复中常见的协调、依赖和预置资源问题。案例中，多个应用的灾备实例处于停止状态，切换自动化假设可临时启动实例、创建数据库副本并扩展容器，但团队未提前确认目标区域容量和账户配额能否承接生产负载。这说明架构正确并不足够，恢复环境需要预先配置并验证，否则演练成功可能掩盖实际事件中的启动失败。
四级递进验证：每一级暴露不同类别的缺口
文章提出从桌面推演、计划切换、突袭演练到故障注入演练的四级成熟度模型。桌面推演明确责任与边界，计划切换测量实际RTO/RPO并发现配置错误，突袭演练检验执行准备和协调能力，故障注入演练则揭示未建模的依赖和监控盲区。案例中，计划切换发现DNS记录仍指向主区域，实际恢复时间超过5小时目标的两倍；突袭演练则因仅一名工程师掌握数据库一致性验证方法而损失90分钟。
将发现反馈到三项决策，形成持续改进闭环
每次测试的发现应映射回第一部分的三项决策：恢复边界、业务锚定目标和依赖协调承诺。边界缺口需调整恢复范围，恢复时间超出业务容忍度需业务方接受或投资更快架构，依赖恢复慢于预期则需修订承诺。案例团队将四类缺口分别对应到具体决策和修复措施，四个月后第二次演练通过，并首次在恢复区域运行面向客户的实时系统。文章强调，渐进测试的价值在于每个周期都收紧恢复承诺，而非通过单次演练。
Q&A
为什么只做一次计划好的灾难恢复演练不够？
计划好的演练只能证明故障转移机制可用，但无法暴露团队协调、依赖关系和预置资源等真实隐患。例如，演练中可能发现恢复区域容量不足、账户配额无法承受生产负载，或者DNS配置错误导致下游应用无法服务用户。这些条件在真实恢复中才会导致停滞，而提前通知的演练无法测试这些假设。
四级递进灾难恢复验证分别是什么？
四级递进验证包括：1）桌面推演：明确责任与边界，不触碰生产环境；2）计划切换：提前通知的故障转移，测量实际RTO/RPO；3）突袭演练：不提前通知，检验执行准备；4）故障注入演练：使用AWS故障注入服务模拟特定依赖故障，发现未建模的依赖。每级发现的问题反馈到恢复边界、业务目标和依赖承诺三项决策。
桌面推演主要能发现哪些问题？
桌面推演通过引导式走查恢复计划，能发现责任归属和边界问题。例如：共享认证平台未纳入恢复范围、网络账户没有故障转移手册、DNS更新步骤只列出团队别名而无具体负责人。它帮助明确谁宣布故障转移、每步的负责人和备份、预期时长以及依赖特定人员的情况。
计划切换演练应该测量哪些指标？
计划切换演练应测量：每个应用的实际恢复时间与既定RTO的对比、恢复区域的数据一致性以确认RPO、需要手动干预的步骤（自动化候选）、以及恢复晚于预期的依赖。例如案例中DNS配置错误导致实际恢复时间超过5小时目标的两倍。
突袭演练和计划切换演练有什么区别？
突袭演练不提前通知响应团队，重点检验执行准备而非能力。它能发现准备过程掩盖的缺口，比如只有原作者能解读的手册、依赖特定人员部落知识的步骤、以及无人练习过的升级路径。案例中突袭演练发现只有一名工程师懂得验证数据库一致性，该人不在时团队花了90分钟才找到并理解流程。
故障注入演练用什么工具，能发现什么？
故障注入演练使用AWS故障注入服务（Fault Injection Service），它提供预置场景如“可用区断电”和“跨区域连接中断”。目的是在未完全脚本化的条件下测试韧性，发现你假设健康的依赖、延迟检测的监控缺口、以及桌面推演未建模的级联故障。这是最接近真实事件的近似。
测试发现的问题如何反馈到灾难恢复决策中？
每个测试发现的问题映射到三项决策：边界缺口（如共享服务未纳入范围）反馈到决策1（恢复边界）；恢复时间超出业务容忍度反馈到决策2（业务目标），业务负责人要么接受更长时间要么投资更快架构；依赖恢复慢于目标反馈到决策3（依赖承诺），修订承诺以反映实际测量。案例中团队将每个发现映射到具体决策和修复，四个月后第二次演练通过。
