这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
故障转移
故障转移是容灾预案真正落地的时刻。它不是简单把 DNS 指到备用机房，而是一系列有顺序、有检查、有回滚的动作。
故障发现
切换前要先确认故障级别。常见信号包括：
- 核心接口错误率持续升高。
- 主机房网络不可达。
- 数据库主节点不可写。
- 多个可用区同时异常。
- 用户侧成功率明显下降。
单个指标异常不一定要容灾切换，可能只是局部服务故障。切换动作成本很高，需要明确触发条件。
切换流程
一次主备切换通常包括：
- 冻结或限制主机房写入，避免双写冲突扩大。
- 检查数据同步延迟，评估 RPO。
- 提升备用数据库或服务为主。
- 切换流量到备用机房。
- 打开必要的降级策略。
- 验证核心链路：登录、下单、支付、查询。
- 持续观察错误率、延迟和业务指标。
每一步都要有负责人、执行命令、验证方法和回滚策略。
自动还是人工
自动切换响应快，但误切风险高；人工切换更谨慎，但可能拖长 RTO。实践中可以分层：
- 单实例故障自动恢复。
- 集群主备自动切换。
- 机房级切换需要自动化执行，但人工确认。
关键是让人工做决策，不让人工手敲复杂命令。
降级策略
备用机房可能容量不足，切换时需要降级：
- 暂停非核心功能。
- 限制低优先级流量。
- 关闭推荐、报表、批处理任务。
- 对库存、余额等强一致能力收紧写入。
容灾目标是保住核心业务，而不是在事故时维持所有功能。
回切
主机房恢复后，不要急着切回。回切同样有风险：
- 主备数据是否重新追平？
- 主机房是否通过健康检查？
- 切回期间是否会产生双写？
- 切回失败如何重新回到备用机房？
故障转移和回切都需要演练。下一章先讨论数据一致性，因为它决定了切换后业务是否可信。