设定并测试 RTO 和 RPO

定义两个独立目标

恢复时间目标（RTO）规定可用服务必须恢复前，最长可接受的中断时间。恢复点目标（RPO）规定以时间衡量的最大可接受数据丢失。针对明确的服务和故障场景，与业务负责人约定这两个目标。

可用性目标描述一段时间内的服务表现。RTO 和 RPO 描述恢复预期，回答的是不同问题。

对于一个虚构订购服务，负责人将 RTO 设为 60 分钟，RPO 设为 15 分钟。这些是示例值，不是通用建议。其他服务可能需要不同限制，因为订单丢失与报表延迟的后果不同。

服务在 10:00 停止。团队记录如下演练：

恢复总历时为 55 分钟，符合 60 分钟的 RTO。如果只计算 25 分钟的恢复操作，就会隐去大部分中断时间。

最新可用恢复点为 09:40，与 10:00 中断时刻相差 20 分钟，比 15 分钟的 RPO 多 5 分钟。更快地恢复同一批数据，不能缩小这段时间窗。

检查实际缺失或不一致的记录。时间窗说明风险暴露，但不能计算受影响订单数量。恢复正常处理前，核对外部付款和履约记录。在恢复练习中尝试不同假设。

策略必须覆盖所需服务、数据和依赖。根据实测目标比较这些模式：

这些模式没有通用恢复时间。实现、数据量、依赖和测试条件共同决定结果。决策时也要纳入运行成本和团队能力。

副本也可能复制误删或损坏记录。需要时，保留可恢复版本或时间点恢复能力。验证保留期限、恢复权限和加密密钥访问。让备份隔离符合故障场景，包括失去主账户访问权限的情况。

进行区域级恢复时，检查允许的数据位置和完整依赖链。纳入身份、DNS、证书、秘密信息、部署制品、配额和网络访问。恢复环境即使只缺少一个必要密钥，也可能无法使用。

明确谁可以宣布发生灾难事件、谁执行恢复，以及谁接受恢复后的服务。规划回切，或继续在恢复环境运行。再次切换前，防止相互冲突的写入并核对数据。

编写操作手册，并在受控条件下演练。记录场景、数据集大小、开始和结束时间、恢复的数据时间点、失败步骤和负责人。使用安全测试记录，验证一项真实业务操作。

相关变更后，以及按约定周期，重复演练。数据模式变化、新外部依赖或不同数据量，都可能使先前结果失效。将演练证据与发布和运维职责关联起来。