恢复优先级与依赖顺序
灾难恢复不是把所有系统一起拉起来，而是按依赖关系和业务价值排序：先恢复被别的系统依赖的基础服务，再恢复核心交易，最后处理周边。排序做错会浪费最宝贵的窗口，比如数据库恢复了但认证目录没起，应用依然无法登录。判定顺序的两个依据是依赖图与业务影响，两者都要在平时维护，不能等事发再临时讨论。
基本信息
| 输入材料 | 系统依赖清单、业务影响分析、各系统 RTO 分级 |
|---|---|
| 排序依据 | 上游依赖优先、业务价值高的优先、恢复耗时短的优先进入 |
| 典型基础层 | 网络与 DNS、认证目录、时间同步、密钥管理 |
| 维护要求 | 架构变更后同步更新依赖图，并纳入演练核对 |
典型使用场景
- 编写灾难恢复预案时定义切换批次与每批的时间窗口
- 演练中按批次推进，验证批次之间的等待是否合理
- 资源受限时决定先恢复哪些系统（备侧容量不足是常态）
- 向业务方解释为什么某个系统恢复较晚
- 复盘时定位『应用起来了却不可用』的依赖遗漏
典型恢复顺序参考
| 顺序 | 系统类别 | 原因 |
|---|---|---|
| 1 | 基础网络、DNS、认证目录、密钥管理 | 所有系统的共同依赖 |
| 2 | 数据库与消息中间件 | 应用启动的前置依赖 |
| 3 | 核心交易应用 | 业务价值最高，直接影响收入 |
| 4 | 周边与报表系统 | 可延后，业务可接受更长中断 |
| 5 | 开发测试环境 | 最后恢复，避免占用切换资源 |
为每个系统维护的三行信息
为每个系统维护的三行信息
# 上游依赖：必须先恢复哪些系统，我才可用
# 下游影响：我不可用时，谁会跟着不可用
# 中断容忍：业务可接受的中断时长（对应 RTO 分级）
# 例：订单服务 上游=数据库/认证/消息队列 下游=支付对账/报表 容忍=30 分钟依赖顺序要画成图并随架构演进维护。口头知道的依赖在应急时最容易漏，尤其是认证、DNS、密钥管理与外部回调这类『不显眼但被所有人依赖』的服务。