这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
容灾基础
容灾设计的第一步不是选技术，而是定义业务目标。没有 RTO、RPO 和业务分级，所有技术方案都会变成“越复杂越好”的堆砌。
RTO 与 RPO
RTO 关注恢复时间，RPO 关注数据丢失窗口：
| 指标 | 问题 | 示例 |
|---|---|---|
| RTO | 故障后多久恢复服务 | 支付系统 5 分钟内恢复 |
| RPO | 最多丢多少数据 | 订单数据最多丢 10 秒 |
RTO 越短、RPO 越小，成本越高。RPO 接近 0 通常意味着同步复制或强一致方案，会带来延迟和可用性代价。
业务分级
不是所有系统都需要同等级容灾。可以按业务影响分级：
- 核心交易链路：登录、下单、支付、履约，要求分钟级恢复。
- 重要支撑系统：库存、账户、通知，要求较短恢复时间。
- 非核心系统：报表、运营后台、推荐训练，可以延迟恢复。
分级后，资源才能投入到真正关键的地方。
容灾模式
常见容灾模式包括：
| 模式 | 特点 | 适用场景 |
|---|---|---|
| 冷备 | 备用资源平时不运行 | 成本敏感、恢复时间要求低 |
| 温备 | 备用环境部分运行 | 中等 RTO 要求 |
| 热备 | 备用环境实时可接管 | 核心业务 |
| 双活/多活 | 多地同时承载流量 | 高可用、高成本、高复杂度 |
不要一开始就追求多活。很多系统先做到热备和可演练切换，收益已经很大。
故障决策
容灾还需要明确组织流程：
- 谁有权宣布进入容灾状态？
- 自动切换还是人工确认？
- 切换前要检查哪些指标？
- 切换失败如何回滚？
- 谁负责对外公告和内部协同？
技术预案没有决策机制，事故时就会变成争论。下一章我们进入多机房架构，讨论资源如何部署。