定义 RTO、RPO 和恢复层级

业务连续性规划 (BCP)是确保关键业务功能在灾难期间及灾难之后仍能持续运行的过程。在云计算中，这意味着设计能够在可接受的时间和数据丢失范围内从故障中恢复的系统。两个关键指标——RTO 和 RPO——定义了每种工作负载的“可接受”标准。

恢复时间目标 (RTO)是系统在灾难发生后可以离线的最长可接受时间。它回答了这样一个问题：“业务最多能容忍此应用程序中断多长时间？”RTO 以时间表示，可以是小时、分钟或秒。支付处理系统的 RTO 可能是 15 分钟，而内部 HR 门户的 RTO 可能是 24 小时。

恢复点目标 (RPO)是以时间衡量的最大可接受数据丢失量。它回答了这样一个问题：“业务最多能承受丢失多少数据？”如果 RPO 为 1 小时，业务就接受最多丢失 1 小时的交易数据。RPO 决定了必须以多高的频率备份或复制数据。RPO 为 0 要求同步复制，这种方式成本高，并且可能影响写入性能。

请务必区分 RTO 和 RPO：

• RTO关注的是时间——系统中断了多长时间
• RPO关注的是数据——丢失了多少数据

系统可能具有较短的 RTO（恢复速度快），但 RPO 较长（接受较大的数据丢失量），也可能相反。理想情况是两者都较短，但要实现这一点，需要在复制和温备容量方面投入大量资金。

并非所有工作负载都具有相同的关键性。一种常见做法是根据业务影响将工作负载划分为不同的恢复层级：

• 第 1 层（任务关键型）——严格的 RTO/RPO，成本最高（例如支付系统、交易平台）
• 第 2 层（业务关键型）——中等的 RTO/RPO（例如 CRM、ERP）
• 第 3 层（非关键型）——较宽松的 RTO/RPO，成本最低（例如开发环境、存档）

不同的恢复层级对应不同的 Azure 功能：

• 第 1 层——Cosmos DB 多区域写入、SQL 自动故障转移组、双活架构、Traffic Manager
• 第 2 层——使用 Azure Site Recovery 恢复到辅助区域、SQL 地理复制（只读副本）、保留 30 天的每日备份
• 第 3 层——使用每周计划的 Azure Backup、不进行复制、从快照还原

要证明低 RTO 架构的投资合理性，请计算该工作负载的停机成本。其中包括收入损失、向客户支付的 SLA 赔偿、员工生产力损失以及声誉损害。如果停机 1 小时的成本为 500,000 美元，那么每月投入 50,000 美元建立双活架构就很容易证明是合理的。请使用这些数据，为适当的恢复层级制定业务论证。

Azure Site Recovery (ASR) 是在 Azure 上实现第 2 层 RTO/RPO 目标的主要服务。ASR 会持续将 VM 复制到辅助区域，并可在几分钟内启动故障转移。Azure VM 的复制频率为每 30 秒一次（崩溃一致），或每 1–4 小时一次（应用程序一致），因此 RPO 通常处于相应范围内，具体取决于配置。

对于 RPO 以小时为单位的工作负载，使用适当计划的 Azure Backup 就足够了。例如，RPO 为 4 小时，就要求备份间隔最长为 4 小时。Azure Backup 支持增强策略，可以为 Azure VM 设置每小时备份计划。对于数据库，使用带事务日志备份的时间点还原 (PITR)，可以以低于 ASR 的成本实现小于 1 小时的 RPO。

RTO 和 RPO 目标应在业务影响分析 (BIA)中正式记录，并由技术和业务相关方共同审查。BIA 会将每个应用程序映射到相应的恢复层级，记录 RTO/RPO 目标，确定负责实现这些目标的 Azure 服务，并规定测试计划（通过演练验证 DR 计划的频率）。

在通过DR 测试验证之前，RTO 和 RPO 目标都只是期望值。在 DR 测试期间，请测量实际恢复时间（是否达到规定的 RTO？）以及恢复点的实际数据丢失量（是否达到规定的 RPO？）。如果测试发现差距，请更新架构或流程，直到目标能够持续实现。请记录测试结果，以便通过合规审计。

请测试您对本课 Microsoft Azure 基础知识 (AZ-900) 概念的理解。

本课您学到了：RTO是最大可接受停机时间，而RPO是以时间衡量的最大可接受数据丢失量；工作负载会被划分为与特定 Azure 服务相对应的恢复层级；并且测试对于验证 RTO/RPO 目标是否可实现至关重要。接下来，我们将学习使用 Azure Site Recovery 制定恢复计划和执行自动故障转移。