这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。

回顾

从一次”备用机房只是个空壳”的机房级故障出发，容灾能力不是画一张多机房架构图，而是被一次次事故和演练逼着长出来的。

演进路径回顾

备份恢复：数据库误删后，团队第一次意识到备份不等于容灾。能恢复数据，但恢复时间和丢失窗口都不可控。
同城热备：单机房故障影响服务，需要备用机房随时接管。主备复制、健康检查和流量切换让 RTO 开始可控，但数据一致性和切换权限成为关键。
跨地域容灾：城市级故障进入预案，数据和服务必须跨区域生存。异步同步、GSLB、消息补偿和对象存储复制，让 RPO 和同步延迟有了明确承诺。
演练驱动容灾：没有演练的预案无法信任，切流和回切必须定期验证。故障演练、自动化 Runbook、恢复验证和审计复盘，让容灾成为组织流程和技术系统共同运行的能力。

容灾设计的本质是业务连续性管理。它要求工程团队提前承认故障一定会发生，并把四件事准备好：

目标（RTO/RPO/业务分级）
   ↓
架构（多机房/热备/多活）
   ↓
数据（同步/一致性/对账补偿）
   ↓
组织（切换决策/演练/复盘）

后面几页会分别总结：最终的系统架构、从实战中提炼的设计原则，以及在每个关键节点上的技术取舍。判断一套系统是否真正具备容灾能力，始终回到四个问题：能停多久、能丢多少数据、故障时谁来决策、我们是否演练过。