1. 课程导入与灾备恢复全景

在开始学习 Azure 灾备恢复之前，先建立一套统一的“语言”至关重要。业务连续性（Business Continuity，BC）与灾难恢复（Disaster Recovery，DR）经常被混用，但它们的边界不同：业务连续性关注的是“在中断期间如何让关键业务继续运转”，涵盖人员、流程、场地、供应商、通信等全部要素；灾难恢复则聚焦于“IT 系统在灾难后如何恢复”，是业务连续性中技术侧的核心支撑。可以这样理解：业务连续性是一张覆盖全组织的作战地图，灾难恢复是其中负责把系统重新点亮的工程方案。

衡量这套能力是否达标，业界用一组指标来量化。RTO（Recovery Time Objective，恢复时间目标）回答“业务能容忍中断多久”，即从灾难发生到服务恢复可接受的最长时间；RPO（Recovery Point Objective，恢复点目标）回答“能容忍丢失多少数据”，以时间为单位表示最近一次可用恢复点与灾难时刻之间的差距。举例来说，若某订单系统设定 RTO = 1 小时、RPO = 15 分钟，意味着灾难后 1 小时内必须恢复服务，且最多只能丢失最近 15 分钟内的订单数据。这两个指标直接决定了备份频率、复制方式和恢复架构的选择，是灾备设计的第一输入。

与之配套的还有两个可靠性指标。MTBF（Mean Time Between Failures，平均无故障时间）衡量系统两次故障之间的平均运行时长，反映“多久坏一次”；MTTR（Mean Time To Repair，平均修复时间）衡量从故障发生到修复完成的平均耗时，反映“坏了多久能修好”。可用性可近似表达为 MTBF / (MTBF + MTTR)：要提升可用性，既可以延长 MTBF（提高冗余与质量），也可以缩短 MTTR（自动化检测与恢复）。灾备体系本质上就是在同时改善这两个方向。

Azure 的灾备体系可以按“纵深防御 + 分层恢复”来理解。最底层是数据层：Azure Backup 提供备份与长期保留，Azure Site Recovery（ASR）提供虚拟机复制与编排恢复，存储账户的 LRS/ZRS/GRS/GZRS 决定数据副本的地理分布。往上是计算与应用层：可用性集（Availability Set）防机架与主机故障，可用性区域（Availability Zone）防数据中心级故障，区域对（Region Pair）支撑跨区域容灾。再往上是流量与接入层：Azure Front Door、Traffic Manager、Load Balancer 负责健康探测与流量切换。最上层是治理与验证层：Azure Monitor、Recovery Services 保管库、Azure Policy 与恢复演练共同保证方案“可观测、可执行、可验证”。

把这张图读透，后续章节就有了坐标。数据层决定“能恢复到哪个点”，对应 RPO；计算与流量层决定“多快能切过去”，对应 RTO；治理与验证层决定“方案是否真的有效”，对应 MTTR 的持续压缩。四层不是并列关系，而是从下往上逐级支撑：没有可靠的数据副本，再快的流量切换也只是把用户引向空服务。

下面用一个具体场景把指标落到设计上。假设某电商平台的核心订单服务，业务方给出的要求是 RTO ≤ 30 分钟、RPO ≤ 5 分钟。分析可知：RPO 5 分钟意味着不能只靠每日备份（RPO 会是 24 小时），必须采用持续复制，例如 ASR 的异步复制（典型可达到秒级到分钟级 RPO）；RTO 30 分钟意味着恢复过程必须自动化，不能依赖人工逐台重建虚拟机，因此需要预置恢复计划（Recovery Plan）并提前完成网络映射与依赖排序。若该服务还要求跨区域容灾，则副本应落在配对区域，并用 Traffic Manager 做基于优先级的故障转移。这样，RTO/RPO 就从抽象数字变成了复制方式、恢复编排和流量策略的具体选择。

需要特别提醒的是，RTO 和 RPO 是业务目标，不是技术承诺。技术团队能提供的是“能力上限”，例如某复制方案实测 RPO 约 1 分钟、某恢复计划演练耗时约 22 分钟；业务目标必须落在这个能力范围之内才有意义。当目标与能力冲突时，要么增加投入（更高频复制、预热备用环境、多区域主动-主动），要么与业务方重新协商指标。把这一层关系想清楚，就不会出现“写了 RTO 15 分钟，实际恢复要 3 小时”的落差。

本课程后续将沿着“概念 → 备份 → 复制 → 高可用 → 切换 → 演练 → 验证”的路径展开，每一环都会给出 Azure 中的具体服务、可配置参数、示例配置与结果判读方法。学习时建议始终带着两个问题：这一步影响 RTO 还是 RPO？它把 MTTR 压到了什么水平？带着这两个问题，30 章内容会自然串成一条完整的灾备能力建设主线。