DR 计划：关键服务和故障点

制定 DR 计划：识别关键服务与故障点

灾难恢复（DR）计划应从终端用户服务入手。目标是最小化业务流程中断时间，而不是单纯关注单个基础设施组件。用户感知到的中断发生在服务层面：无法访问邮件或 ERP 系统，而不是服务器磁盘故障。

首先，列出关键 IT 服务——这些是业务缺了它们就会损失收入或效率的工具：

• 电子邮件
• 企业电话系统
• 企业资源计划（ERP，如用友、金蝶）
• 文档协作平台
• 网络打印
• 互联网访问
• 企业 CRM 和数据库

排除非关键项目，如游戏服务器——它们不影响日常运营。

基础设施中的故障点识别

针对每个服务，识别所有潜在故障点——这些基础设施组件的故障会导致服务不可用。故障点是指排查到此就停在“它挂了”的任何单元。

在模块化设备（如路由器）中，将单个模块和机箱分开考虑。如果能隔离并替换子组件，每个都是独立的故障点。

“电子邮件”服务的示例：

• 服务器操作系统（Linux/Windows Server）
• 邮件软件（Postfix、Exchange）
• 核心网络交换机
• 电源系统（UPS、PDU）
• 外部 DNS 服务器
• 黑名单过滤（RBL）
• 机房环境控制
• 数据存储（SAN/NAS）

别忽略“可靠”设备：即使是带 RAID 和复制的存储阵列，故障时也需要恢复计划。

故障点间依赖关系分析

故障点构成依赖图：一个故障可能引发其他连锁反应。例如，UPS 故障导致服务器关机，重启虚拟化主机时虚拟机可能无法正常启动。而客户端交换机则是独立的。

对于“电子邮件”，依赖形成链条：电源 → 服务器 → 应用 → 网络 → 外部服务。将此模型扩展到所有关键服务，使用影响图展示。

这一洞察对优先级排序至关重要：它决定排查顺序、RTO/RPO 目标和风险评估。后文将讨论恢复流程和指标。

关键要点

• 聚焦用户面向服务，而非硬件：企业以关键工具中断分钟数衡量停机时间。
• 列出每个故障点，别跳过“万无一失”的设备——墨菲定律总会找上门。
• 依赖图揭示连锁故障，加速 MTTR（平均恢复时间）。
• DR 计划将被动救火转为主动策略，配以预算和 SLA。
• 与 CMDB 或 ITSM 集成，实现自动化发现。

— Editorial Team