这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
容灾演练
没有演练过的容灾预案，不能算真正可用。很多系统在文档里写着“备用机房可接管”，但第一次切换往往发生在真实事故中，这时才发现脚本过期、权限缺失、配置不一致、数据没同步。
容灾演练的目标是提前暴露这些问题。
演练层级
演练可以分层推进：
| 层级 | 内容 |
|---|---|
| 桌面推演 | 团队按文档走流程，不真实切流 |
| 组件演练 | 模拟数据库主备切换、消息重放、缓存失效 |
| 局部演练 | 选择非核心服务切到备用机房 |
| 全链路演练 | 核心链路按真实预案切换和回切 |
不要第一次就做全链路。先把流程、权限、脚本和观测补齐，再逐步扩大范围。
演练准备
一次演练前要明确：
- 演练目标：验证 RTO、RPO，还是验证某个组件切换？
- 影响范围：哪些用户、服务、数据会受影响？
- 回滚方案：演练失败如何恢复？
- 观察指标：错误率、延迟、同步延迟、业务成功率。
- 参与角色：指挥、执行、观察、业务确认、客服沟通。
演练不是技术团队单独完成的事。客服、运营、业务负责人也要知道发生了什么。
演练过程
演练过程要像事故一样记录时间线：
10:00 宣布演练开始
10:03 模拟主机房数据库不可写
10:05 启动切换流程
10:08 备用机房接流量
10:10 核心链路验证通过
10:20 开始回切
10:30 演练结束每一步都要记录实际耗时、执行人和验证结果。这样才能判断 RTO 是否达标。
演练复盘
演练结束后要复盘：
- 哪些步骤超时？
- 哪些脚本或权限不可用？
- 哪些监控指标缺失？
- 哪些数据存在差异？
- 哪些沟通链路不清晰？
复盘结果要变成任务，而不是停留在会议纪要。下一次演练要验证这些任务是否真的解决。
演练频率
核心系统至少应该定期演练。频率取决于业务重要性：
- 核心交易链路：季度或月度演练。
- 重要支撑系统：半年演练。
- 普通系统：重大架构变更后演练。
容灾能力会随着系统变化而退化。只有持续演练，预案才不会变成过期文档。