决定灾备成功的三项业务决策
内容提要
灾备成功取决于三项业务决策：以业务功能而非单个应用划定恢复边界并纳入共享服务；让业务方参与设定RTO/RPO，明确停机后果与需保全数据；梳理完整依赖链，按最慢依赖确定可承诺目标并提前预置资源。三者缺失将导致恢复目标落空。
延伸解读
恢复边界：从应用转向业务功能
文章指出，若仅以单个应用划定恢复范围，容易遗漏跨账户、跨团队的共享服务。案例中，共享认证平台未纳入恢复范围，导致下游应用虽切换成功，用户仍无法登录。将恢复边界重新定义为端到端业务功能，能暴露此类依赖，使恢复目标真正对齐用户所需能力。
RTO/RPO需由业务后果锚定
工程团队单独设定的RTO/RPO可能与业务容忍度脱节。案例中，业务方视5小时为合同承诺，工程方却视为理论上的弹性目标，首次演练耗时9-11小时才暴露分歧。让业务方参与定义，明确每小时停机的后果及必须保全的数据，才能形成工程可构建、业务可认可的目标。
依赖链决定可承诺的恢复目标
应用恢复速度受最慢依赖制约。案例中，面向客户的应用自身可1小时恢复，但依赖的共享身份服务需4小时，实际RTO即为4小时。需梳理完整依赖链，记录各依赖的恢复目标，并以最慢环节设定自身承诺；对他人拥有的依赖，应取得书面承诺而非假设。
预置资源缩短恢复链
文章区分了读取现有状态与变更资源的风险：区域故障时，读取现有凭证和DNS记录仍可用，但创建或修改IAM角色、Route 53记录需经过单区域控制平面，可能失败。提前在恢复区域预置依赖，可减少需按序恢复的服务数量，使可达成目标更接近期望承诺。
Q&A
灾备恢复边界应该按什么来划定？
应以业务功能（用户依赖的端到端能力，如完成交易、登录账户）而非单个应用来划定恢复边界，并确保共享服务（如认证平台）也被纳入范围。
为什么业务方需要参与设定RTO和RPO？
业务方参与能确保恢复目标与业务实际容忍度一致，明确停机每小时带来的后果以及哪些数据必须保全，避免工程团队单方面设定导致目标脱离业务需求。
依赖链如何影响可实现的恢复时间目标？
应用恢复速度受限于最慢的依赖。例如，一个应用自身1小时可恢复，但依赖的共享身份服务需4小时恢复，则实际RTO为4小时。因此需梳理完整依赖链，按最慢依赖确定可承诺目标。
灾备演练中共享服务未纳入恢复范围会导致什么后果？
可能导致业务功能整体失效。例如，共享认证平台未配置故障转移，仍留在主区域，导致依赖它的应用无法认证用户，尽管应用本身切换成功，但用户登录等业务功能无法工作。
如何验证灾备目标是否合理？
可检查三点：恢复边界是否覆盖完整用户旅程（含跨账户共享服务）；业务方是否确认了RTO/RPO对应的每小时后果；目标是否考虑了所有依赖（包括全局端点和需在故障期间创建资源的步骤）。若均有证据支持，则目标合理。
在灾备规划中，为什么应提前预置依赖资源？
提前在恢复区域预置并运行依赖，可以减少事件发生时需要恢复的服务数量，缩短依赖链，使可实现的恢复目标更接近期望承诺的目标。
