如何开展灾难恢复就绪演练
内容提要
本文介绍五步DR就绪演练：启动会明确恢复边界并指定各依赖负责人；评估依赖缺口并落实修复责任；按桌面推演、计划切换、突袭演练逐级验证；将发现反馈至三项业务决策并更新恢复承诺；每季度复查以防漂移。案例中首次演练因边界遗漏、依赖受限、资源未预置及手动DNS切换失败，超时逾两倍；四个月内整改后第二次演练成功。
延伸解读
边界图是演练成败的第一块基石
文章强调启动会必须产出边界图，列出恢复路径上每个服务与账户的负责人及其恢复时间承诺。案例中首次演练失败的首要原因正是边界遗漏了共享认证平台，导致多数下游应用无法认证用户。这说明演练前若未把所有依赖方拉入同一张图，后续测试再精细也会因范围缺失而失真。读者应优先确认边界图是否覆盖跨团队共享服务，而非急于安排切换测试。
逐级验证避免噪声掩盖真实缺口
文章建议按桌面推演、计划切换、突袭演练的顺序推进，且未通过计划切换前不要安排故障注入的游戏日。原因是跳级测试会产生大量混杂发现，反而模糊真正的依赖与资源缺口。案例中团队在四个月内先整改边界、依赖链、预置资源和DNS切换方式，第二次演练才成功。读者应把每一级验证视为下一级的准入条件，而非可选项。
发现必须回馈到三项业务决策
文章将演练发现分为边界、后果、依赖三类，分别对应三项业务决策：边界发现回馈决策一，后果发现回馈决策二由业务负责人选择接受更长恢复时间或投资更快架构，依赖发现回馈决策三。最终产出是更新后的恢复承诺，以实测替代假设。读者应建立发现到决策的映射机制，否则演练记录容易停留在技术清单，无法推动业务层面对恢复目标的重新确认。
季度复查与架构变更触发机制防漂移
文章指出恢复姿态会随应用变化而漂移，例如新增微服务引入未映射依赖、配置变更改变流量路由、半年前的配额不再覆盖峰值。因此建议每季度复查边界是否变化、业务负责人是否仍接受RTO/RPO、依赖恢复行为是否改变。此外，任何新增跨账户依赖或改变切换路径的架构变更都应触发重新演练。读者可将季度复查与变更触发结合，避免恢复承诺在两次演练之间悄然失效。
Q&A
开展灾难恢复就绪演练的第一步应该做什么？
第一步是启动会，需要将应用负责人、业务负责人和平台团队聚集在一起，明确恢复边界。具体要依次回答：用户需要能做什么才算“恢复”、哪些应用/共享服务/账户在用户旅程路径上、每个部分由谁负责及其恢复时间线是否已确认。输出是一份边界图，列出恢复路径中的每个服务和账户，并指定负责人和记录其恢复时间线。
如何评估灾难恢复中的依赖缺口？
对边界图中的每个组件进行结构化审查，询问：该依赖是否在目标AWS区域恢复、是否在声明的RTO内恢复、上游服务的恢复目标是否会限制可承诺的RTO。可使用Well-Architected框架可靠性支柱审查来发现单点故障、缺失健康检查等，用运营就绪审查检查运行手册假设是否成立。输出是按优先级排列的依赖缺口列表，每个缺口有负责人、修复计划和承诺日期。
灾难恢复演练的验证计划应该如何安排测试顺序？
验证计划应按照渐进式验证级别安排：第2周对最高后果功能进行桌面推演，确认所有权、升级路径和每步预期时长；第4-6周在缺口修复后进行计划切换，测量实际恢复时间与RTO对比，验证数据一致性是否符合RPO；第8-10周若计划切换通过则进行突袭演练，测试无预先通知的协调能力。在计划切换干净通过前，不要安排带故障注入的游戏日。
演练发现的问题如何反馈到业务决策中？
每个测试发现需映射回它影响的三项业务决策：边界发现（测试中发现未纳入恢复范围的共享服务）反馈到决策1；后果发现（恢复时间超出业务容忍度）反馈到决策2，由业务负责人决定接受更长时间线或投资更快架构；依赖发现（上游服务恢复目标限制应用、资源未预置）反馈到决策3。输出是更新后的恢复承诺，反映实际测量结果而非假设。
如何防止灾难恢复能力随时间漂移？
需要安排季度审查，检查边界是否变化（新增共享服务或账户）、业务负责人是否仍接受RTO/RPO目标、依赖的恢复行为是否改变。此外，任何增加跨账户依赖或改变故障转移路径的架构变更都应触发重新参与。这样可防止因新微服务、配置变更或配额变化导致的恢复姿态漂移。
案例中第一次演练失败的原因是什么？
第一次演练未能满足5小时的合同恢复承诺，耗时超过两倍。根本原因对应三项决策：边界遗漏了共享认证平台（导致多数下游应用无法认证用户）；依赖链包含上游服务，其恢复目标限制了调用它的应用；DR资源未预置；DNS故障转移依赖手动步骤，在协调压力下耗时超过3小时。
如何加速灾难恢复就绪演练的进程？
可以借助AWS企业支持提供的机制：技术客户经理协助启动会并保持推进势头；Well-Architected和运营就绪审查用于评估；专业解决方案架构师进行深度依赖分析；AWS Countdown在关键事件（如计划切换和DR游戏日）期间提供协调的运营就绪和工程支持。这些是加速选项而非前提条件，步骤和输出不变。
