3. 灾备需求分析与风险评估
灾备建设最容易犯的错误，是"先买设备、再想需求"。真正决定灾备方案形态的，是业务对中断的容忍度，以及系统实际存在哪些故障模式。本节围绕三条主线展开：业务影响分析（BIA）确定"恢复什么、恢复到什么程度"，故障模式与影响分析（FMEA）确定"可能怎么坏、坏了影响多大"，最后把两者收敛为 AVEVA 监控平台的典型风险场景与恢复优先级排序。
一、业务影响分析：把停机翻译成业务损失
BIA 的核心动作是逐项识别关键业务功能，并为其标注两个时间参数：RTO（恢复时间目标）与RPO（恢复点目标）。RTO 回答"允许中断多久"，RPO 回答"允许丢多少数据"。这两个值不是 IT 拍脑袋定的，而应由生产、调度、安全等业务方确认。
以某化工企业 AVEVA 监控平台为例，可按下表梳理（示例参数，用于说明方法，非实测结论）：
| 业务功能 | 中断影响 | RTO | RPO | 恢复等级 |
|---|---|---|---|---|
| 实时数据采集与画面监视 | 操作员失去工况感知，可能触发联锁停车 | ≤15 min | ≤1 min | 一级 |
| 报警与事件记录 | 无法追溯异常，事故定责困难 | ≤30 min | ≤5 min | 二级 |
| 历史趋势查询 | 工艺分析中断，不影响当前生产 | ≤4 h | ≤15 min | 三级 |
| 报表与统计输出 | 影响管理决策，可延后 | ≤24 h | ≤1 h | 四级 |
表中"恢复等级"是后续资源投入的依据：一级功能必须做热备或集群，四级功能用冷备加定期备份即可。BIA 的产出不是一张表，而是一份带优先级的恢复清单——它直接决定灾备架构的复杂度与成本。
二、故障模式与影响分析：从"会坏"到"坏成什么样"
FMEA 要求对每个组件追问三件事：可能的故障模式、故障后果、可探测性。工程上常用 RPN = 严重度 S × 发生度 O × 探测度 D 排序，S/O/D 各取 1～10 分。分值越高，越需要优先治理。
AVEVA 监控平台典型组件的 FMEA 示例（评分为教学假设值）：
| 组件 | 故障模式 | S | O | D | RPN | 治理方向 |
|---|---|---|---|---|---|---|
| 实时数据库节点 | 进程崩溃/主机宕机 | 9 | 4 | 3 | 108 | 双机热备+自动切换 |
| 历史库存储 | 磁盘阵列故障 | 7 | 3 | 4 | 84 | RAID+异地备份 |
| 采集网关 | 通信中断/协议异常 | 8 | 5 | 2 | 80 | 冗余网关+链路监测 |
| 操作站 | 画面卡死/客户端掉线 | 6 | 6 | 2 | 72 | 备用操作站+快速重连 |
| 授权服务器 | License 失效 | 7 | 2 | 6 | 84 | 冗余授权+离线应急授权 |
注意探测度 D 的含义：D 越大表示越难在故障造成后果前发现。授权服务器 RPN 偏高，正是因为 License 失效往往在客户端报错时才暴露，探测滞后。这类"难发现"的故障，应通过主动巡检和心跳监测来降低 D 值。
三、典型风险场景与恢复优先级
把 BIA 的恢复等级与 FMEA 的高 RPN 项交叉，可归纳出 AVEVA 监控平台四类典型风险场景：
- 单节点故障：实时库或采集网关单机宕机。影响面局部，但若该节点承载一级功能，必须分钟级切换。
- 存储失效：历史库磁盘损坏。数据丢失风险高，恢复依赖备份完整性与 RPO 达成情况。
- 网络分区：控制网与监控网之间链路中断，采集数据积压，恢复后需处理补传与时间戳对齐。
- 站点级灾难：机房断电、火灾、水淹。需要异地灾备中心接管，RTO 通常在小时级。
恢复优先级排序遵循一条原则：先恢复"看得见"的，再恢复"查得到"的，最后恢复"算得出"的。即优先恢复实时监视与报警，其次历史数据，最后报表统计。这一顺序与 BIA 的恢复等级一致，也决定了切换脚本的执行次序。
四、从分析到可执行的需求条目
分析完成后，应把结论固化为可验证的需求条目，而不是停留在描述性文字。每条需求至少包含：对象、场景、指标、验证方式。例如：
需求编号：DR-001
对象：实时数据库主节点
场景：主机宕机
指标：RTO ≤ 15 min，RPO ≤ 1 min
验证方式：模拟主节点断电，记录备节点接管时间与数据断点
验收判据：接管时间 ≤ 15 min，丢失数据点 ≤ 1 min 采集量这样的条目可以直接进入测试用例，也能在灾备演练中逐条核对。BIA 给出"恢复到什么程度"，FMEA 给出"防哪些故障"，风险场景给出"按什么顺序恢复"，需求条目则把三者变成可验收的工程语言——这正是灾备需求分析区别于泛泛而谈的关键。