误区一：把架构图画成两地，就等于具备容灾
很多方案评审时展示了两地部署，但深入问下去会发现：数据库只是每天备份一次，密钥没有复制，DNS 切换靠人工登录控制台，队列消费者在备用区域没有启动脚本。这种架构在图上是高可用，在故障中是低可用。
容灾要定义 RTO 和 RPO。RTO 是多久能恢复服务，RPO 是最多丢多久数据。没有这两个数字，就无法判断复制频率、备用规模、自动化程度和演练投入是否合理。
| 目标 | RTO 大致要求 | RPO 大致要求 | 常见方案 |
|---|---|---|---|
| 个人内容站 | 小时级 | 可接受小时级丢失 | 版本化备份，可重建部署 |
| 一般在线服务 | 分钟到小时级 | 分钟级 | 定时快照加日志复制 |
| 关键交易系统 | 分钟级 | 接近零 | 持续复制、多活、自动切换 |
误区二：数据库能复制，状态就能恢复
应用状态不只在数据库里。对象存储中的文件、消息队列中未消费的事件、缓存中的会话、搜索索引、定时任务执行进度、外部系统回调地址，都可能影响恢复后的服务行为。
我现在的做法是把状态列成清单，并给每项标注恢复方式：可重建、需备份、需复制、可丢弃。这个清单比“我们用了托管数据库”更能说明真实恢复能力。
# 状态清单模板 database: 备份周期 / 保留期 / 恢复演练时间 object files: 版本化 / 跨区复制 / 权限策略 queue: 是否持久化 / 死信 / 重放策略 cache: 允许丢失 / 预热方式 search index: 重建耗时 / 数据来源 secrets: 复制方式 / 轮换流程 dns records: 导出备份 / 变更审批
误区三：DNS 切换很简单
DNS 切换涉及 TTL、客户端缓存、运营商递归解析、健康检查和流量比例。TTL 设置得长，故障时切换慢；设置得太短，正常状态下解析压力和稳定性又会受影响。某些客户端和库并不严格遵守 TTL，这也是常见意外。
更稳妥的方式是先在入口层做健康检查和自动摘除，DNS 只负责粗粒度调度。如果必须人工切换，要确保账号权限、操作步骤、验证指标和回滚方式写在一页纸内，而不是散落在聊天记录里。
误区四：演练只验证资源能启动
启动资源和恢复服务是两件事。演练至少要覆盖：从备份恢复数据、启动应用、接入流量、验证关键交易、观察监控、执行回滚。演练结束后，还应记录哪些步骤依赖人工，哪些参数只在某个人的终端里存在。
对小团队来说，可以先做季度桌面演练加半年技术演练。桌面演练检查决策链、联系方式和依赖清单；技术演练在隔离环境恢复数据并跑通关键路径。比完全不做强得多，也比追求全年多活更现实。
依赖服务也要进入容灾范围
- 身份认证：备用区域能否验证用户，管理员能否登录。
- 支付或回调：外部系统地址是否需要变更。
- 邮件短信：配额、域名和发信配置是否可用。
- 监控告警：备用环境的指标是否接入同一视图。
- 密钥证书：能否在备用区域自动获取和轮换。
这些依赖常常是故障恢复时间的主要来源。应用容器启动只要十几秒，管理员无法认证或证书无法签发却可能消耗一小时。
一份务实的改进顺序
- 写下服务的 RTO/RPO 和最低可用功能。
- 备份 DNS、数据库、对象文件、密钥和基础设施代码。
- 每季度检查备份是否可恢复，而不是只看任务成功。
- 把启动脚本、环境变量和权限固化到版本控制。
- 建立一页应急手册，明确判断指标、负责人和回滚条件。
- 半年做一次隔离环境演练，修复人工步骤。
跨地域容灾的收益来自约束清晰的架构和重复验证的流程。资源复制只是结果，能够按预期恢复服务才是目标。