1. 灾备与业务连续性核心概念

在讨论任何 AWS 灾备方案之前，必须先建立一套统一的度量语言。否则团队之间很容易出现“系统已经高可用”“数据基本不丢”这类无法验证的表述。灾备与业务连续性的核心，是把业务对中断的容忍度翻译成可测量、可设计、可验证的工程指标，再据此决定架构投入。

RTO 与 RPO：两个方向相反的时间轴

RTO（Recovery Time Objective，恢复时间目标）回答的是“业务能忍受停多久”。它从中断发生的那一刻起算，到服务重新可用为止，是允许的最长停机时长。RTO 为 30 分钟，意味着灾难发生后必须在 30 分钟内恢复对外服务，否则就突破了业务容忍底线。

RPO（Recovery Point Objective，恢复点目标）回答的是“业务能忍受丢多少数据”。它衡量的是恢复后数据的时间点与故障发生时刻之间的差距，本质上是允许的数据丢失窗口。RPO 为 5 分钟，意味着最坏情况下可以接受最近 5 分钟内的数据丢失。

两者方向相反：RTO 指向“未来”，约束恢复速度；RPO 指向“过去”，约束数据备份与复制的频率。一个常见误区是把 RPO 当成备份耗时——备份跑了两小时并不等于 RPO 是两小时，真正决定 RPO 的是“最近一次可用恢复点距今多久”。

可用性、容错与灾难恢复的层次差异

可用性（Availability）通常用“正常运行时间 / 总时间”表示，常以“几个 9”描述。单可用区多副本可支撑约 99.9%，跨可用区部署可支撑约 99.99%，跨区域则进一步向 99.999% 逼近。可用性关注的是日常小故障下的持续服务能力。

容错（Fault Tolerance）比高可用更进一步：系统在组件故障时不仅不中断，而且性能与数据不降级。容错通常依赖冗余与自动切换，成本显著更高，一般只用于核心交易链路。

灾难恢复（Disaster Recovery）针对的是区域级或大规模故障，关注的是“从灾难中把业务重新拉起来”的能力，而不是日常抖动。可用性解决“不常坏”，容错解决“坏了也不停”，灾备解决“大范围坏了怎么重建”。三者是不同层次的问题，不能用同一套投入去覆盖。

责任共担模型下的灾备责任边界

AWS 的责任共担模型把安全与可靠性责任划分为两部分：AWS 负责“云本身的安全”，包括区域与可用区的物理设施、网络骨干、托管服务的底层冗余；客户负责“云中的安全”，包括数据、配置、访问控制以及架构层面的容灾设计。

这一划分直接决定了灾备责任的归属。以 Amazon RDS 为例，AWS 负责数据库实例的底层硬件、多可用区自动故障转移机制；但“是否开启多可用区”“备份保留多少天”“是否配置跨区域只读副本”“RTO/RPO 目标是多少”“切换后应用连接串如何更新”，全部由客户负责。再如 Amazon S3，AWS 保证 11 个 9 的持久性，但“是否开启跨区域复制”“版本控制是否启用”“误删后如何恢复”，仍是客户的设计决策。

责任边界还会随服务模型移动。使用 EC2 这类 IaaS 时，客户要自行处理操作系统补丁、应用部署、数据复制；使用 Lambda、DynamoDB 等托管服务时，AWS 承担了更多底层可用性工作，客户的责任重心转向配置、数据模型与跨区域策略。因此，评估灾备方案时，第一步不是选服务，而是明确“这项能力由谁兜底、我必须在哪一层补齐”。

把业务语言翻译成工程指标

实际落地时，建议按业务影响而非技术组件来定指标。可以先把系统按重要性分级，再为每一级设定 RTO/RPO 区间，最后映射到具体的 AWS 能力组合。下面是一份可直接参考的指标映射示例（参数为教学假设，需按实际业务校准）：

指标确定后，还需要验证它是否真的可达。RTO 不能只看“能不能恢复”，还要看“恢复过程中有多少人工步骤”。如果切换需要人工修改 DNS、手动提升副本、逐个更新配置，那么实际 RTO 往往远大于设计值。建议把恢复过程拆成可观测的阶段：检测时间、决策时间、切换执行时间、验证时间，分别测量并记录，才能判断瓶颈在哪一段。

常见概念混淆与纠正

• 把高可用等同于灾备：多可用区能应对单 AZ 故障，但无法应对区域级故障，也不能替代跨区域备份。
• 把备份等同于灾备：备份解决数据可恢复，不解决服务多快能重新对外提供，RTO 仍需单独设计。
• 把 RPO 当作备份周期：RPO 取决于最近可用恢复点与故障时刻的差距，受复制方式、日志归档频率共同影响。
• 忽略责任边界：托管服务并不自动满足业务 RTO/RPO，客户仍需完成配置、演练与验证。

建立统一指标、明确责任边界、把恢复过程拆解为可测量阶段，是后续所有灾备策略设计的基础。只有先回答“能停多久、能丢多少、谁来兜底”，才能进一步讨论具体的 AWS 架构选型与切换机制。