设计原则
设计容灾系统时踩过的坑，让我总结出几条可以复用到其他系统的原则。
1. 目标先于技术
原则
先定义 RTO、RPO 和业务分级，再选技术方案。实践
没有恢复目标的容灾设计，只会变成”越复杂越好”的堆砌。先回答：这个业务能停多久、最多丢多少数据。RTO 越短、RPO 越小，成本越高，因此要按业务影响分级——核心交易分钟级恢复，报表系统可以延迟恢复。
2. 备份不等于容灾
原则
能恢复，且恢复时间和丢失窗口可控，才算容灾。实践
备份只是容灾的第一步。很多系统有备份，但从未验证过恢复，或恢复要几小时。容灾能力要包含：恢复时间达标、数据丢失可控、切换可执行、预案可演练。备份要定期校验”能不能真正恢复”，而不是备份成功就算数。
3. 数据同步是容灾的命门
原则
服务可以快速拉起，数据必须跟上。实践
备用机房部署同版本服务很容易，难的是数据同步。先按数据类型分类（强业务数据、可重建数据、临时数据、文件数据、消息数据），再设计各自的同步策略。所有数据都按最高标准同步，成本会失控。
4. 能避免冲突就不要制造冲突
原则
多活写入的冲突，能规避就规避。实践
跨地域强一致成本高、可能降低可用性。很多所谓多活，实际应该先做分区单写：按用户或租户归属地路由，避免同一实体多地写。对可合并数据用 CRDT 或累加合并，对关键业务进入人工或补偿流程。避免冲突永远比解决冲突便宜。
5. 切换是动作序列，不是一次点击
原则
故障转移要有一系列有顺序、有检查、有回滚的动作。实践
切换不是简单把 DNS 指到备用机房。要冻结写入、检查同步延迟、提升备库、切换流量、打开降级、验证核心链路、持续观察。每一步都要有负责人、执行命令、验证方法和回滚策略。回切同样有风险，要等数据追平、健康检查通过后再切。
6. 预案必须演练
原则
没有演练过的预案，不能算真正可用。实践
很多系统的备用机房第一次”真正使用”发生在事故中，这时才发现脚本过期、权限缺失、配置不一致。演练要分层推进：桌面推演 → 组件演练 → 局部演练 → 全链路演练。复盘结果要变成任务，下一次演练验证这些任务是否解决。
7. 故障时保核心
原则
容灾目标是保住核心业务，不是维持所有功能。实践
备用机房可能容量不足，切换时需要降级：暂停非核心功能、限制低优先级流量、关闭报表批处理、对强一致能力收紧写入。容灾场景下，“部分可用”远好于”全部不可用”。
8. 监控决定切换信心
原则
没有持续健康的数据，切换就是赌博。实践
主备复制延迟、最近成功同步时间、备用机房健康度、核心业务成功率，这些指标必须持续监控。没有这些数据，团队无法判断是否能安全切换，也无法证明容灾能力没有退化。
容灾系统设计 checklist
目标定义：
✓ 核心业务定义 RTO 和 RPO
✓ 明确哪些系统必须容灾、哪些可延迟恢复
架构与数据：
✓ 备用机房部署同版本服务和配置
✓ 数据库/缓存/对象存储/消息都有同步或重建方案
✓ 有对账和补偿机制处理数据差异
切换与回切：
✓ 一键或自动化切换脚本
✓ 切换前后核心链路验证清单
✓ 降级策略和回切流程
演练与复盘：
✓ 定期演练并复盘问题
✓ 复盘结果转化为任务并验证记住：
- 容灾是业务连续性管理，不是买第二套服务器
- 先定义目标，再选架构，再谈数据，最后靠演练证明
- 故障一定会发生，问题是你有没有提前准备好