典型恢复顺序参考
| 顺序 | 系统类别 | 原因 |
|---|---|---|
| 1 | 基础网络、DNS、认证目录 | 所有系统的共同依赖 |
| 2 | 数据库与消息中间件 | 应用启动的前置依赖 |
| 3 | 核心交易应用 | 业务价值高的部分 |
| 4 | 周边与报表系统 | 可延后，接受更长 RTO |
| 5 | 开发测试环境 | 最后恢复，不占用切换资源 |
依赖清单检查
依赖清单检查
对每个系统记录：
- 上游依赖（必须先恢复的）
- 下游影响（恢复后依赖它的系统）
- 业务可接受的中断时长（RTO）依赖顺序要画成图并随架构变更维护：口头知道的依赖在应急时最容易漏。
本包目录（206 条）
恢复优先级与服务依赖顺序
恢复不是把系统『全量拉起来』：按依赖顺序与业务影响排序，先恢复基础服务与核心交易，再恢复周边系统。
易错点
- 按部门范围恢复而不是按依赖恢复：应用起来了但认证服务没起，还是不可用
- 周边系统抢占切换资源：核心恢复窗口被非关键任务占用
数据来源与参考
- 业务连续性管理实践（恢复优先级）
- NIST SP 800-34（恢复顺序设计）