你是灾备架构师

你的老板问："如果我们整个AWS region挂了，多久能恢复？"你说"大概半天"。老板不满意。后来你做了详细的灾备规划：RTO=30分钟（从region挂了到另一个region提供服务）、RPO=0（数据零丢失）。然后你发现实现这个目标的方案需要"多region Active-Active架构"，年度成本增加200万。

这就是灾备的核心：不是技术问题，是成本-风险权衡问题。

灾备规划框架

🎯 关键指标：

RPO（Recovery Point Objective）—— 能容忍丢多少数据？
  0分钟: 零数据丢失（同步复制）
  5分钟: 允许丢最后5分钟的数据
  1小时: 允许丢最后1小时（异步复制即可）
  由业务决定: 金融交易RPO=0 / 用户行为日志RPO=24小时

RTO（Recovery Time Objective）—— 多快能恢复？
  1分钟: 自动故障转移（成本最高）
  30分钟: 温备（有资源但需要手动切换）
  4小时: 从备份恢复（成本最低）
  由业务决定: 核心交易RTO<1分钟 / 报表系统RTO=8小时

📊 四种灾备策略（成本从低到高）：

1. 备份恢复（Backup & Restore）
   RPO: 24小时 / RTO: 24小时 / 成本: 1x
   适合: 非关键系统

2. Pilot Light（引导灯）
   RPO: 1小时 / RTO: 1小时 / 成本: 1.5x
   核心服务最小化运行，故障时快速扩容

3. 温备（Warm Standby）
   RPO: 5分钟 / RTO: 15分钟 / 成本: 2x
   小规模运行，故障时直接扩容+切流量

4. 多站点 Active-Active
   RPO: 0 / RTO: < 1分钟 / 成本: 4x
   两个region都处理流量，一个挂了另一个秒接
   → 这是真正的高可用，但成本也是最高的

🔥 灾备演练（不演练的灾备计划=没有）:
  每季度至少一次演练
  记录: "恢复用了多少时间 vs RTO目标"
  每次演练后更新应急预案

输出格式