2. AVEVA监控平台高可用与灾备体系解析
在讨论灾备方案之前，必须先看清被保护的对象本身。AVEVA监控平台（以System Platform / OMI、Historian、InTouch等典型组件为例）并不是一个单一软件，而是一组承担不同职责、通过多种通信通道耦合的运行时集合。灾备设计的本质，是识别这些组件之间的依赖关系与数据流向，找出其中"一旦失效就导致业务中断"的单点，再针对不同等级的中断风险匹配不同的恢复能力与指标承诺。
一、平台组件与角色分层
从可用性视角，可以把平台组件划分为四层：
- 采集与现场层：PLC、RTU、DCS控制器，以及通过OPC UA/DA、Modbus TCP、MQTT等协议接入的网关。这一层决定"数据能不能进来"。
- 通信与引擎层：由通信驱动（如DAServer/DI Object）、AppEngine（应用引擎）组成。AppEngine承载脚本、逻辑、报警与历史采集配置，是平台真正的"运行大脑"。
- 数据服务层：Historian（历史库）、Alarm DB（报警库）、Galaxy Repository（对象库）。这一层决定"数据能不能存住、能不能查回"。
- 呈现与访问层：OMI/InTouch View客户端、Web客户端、报表与API接口。这一层决定"人能不能看到"。
四层之间是逐级依赖的：客户端依赖数据服务，数据服务依赖引擎，引擎依赖通信与现场。理解这个依赖方向，是后面识别单点故障的基础。
二、数据流与关键路径
一条典型的实时数据链路是：现场设备 → 通信驱动 → AppEngine属性 → Historian归档 → 客户端/报表。其中存在两条性质不同的数据流：
- 实时流：以秒级刷新，走内存与订阅通道，中断后表现为画面数值冻结、报警不刷新。
- 历史流：以归档周期（常见500ms～5s）写入Historian，中断后表现为历史曲线出现数据缺口，且缺口往往不可自动补齐。
这两条流的恢复要求不同：实时流追求"快"，历史流追求"全"。灾备等级划分时，必须分别评估。
三、单点故障识别方法
识别单点不能靠"感觉"，建议按依赖链逐段排查，对每个组件问三个问题：
- 它失效后，哪些功能立即不可用？（影响面）
- 它有没有冗余实例或可替代路径？（冗余度）
- 恢复它需要多长时间、依赖哪些外部条件？（恢复代价）
以某化工厂监控系统为例，排查结果如下（示例数据，用于说明方法）：
| 组件 | 影响面 | 冗余度 | 恢复代价 | 判定 |
|---|---|---|---|---|
| AppEngine 单实例 | 全站逻辑、报警、采集 | 无 | 需重建对象并重新部署 | 关键单点 |
| Historian 单节点 | 历史查询、报表、趋势 | 无 | 恢复备份，缺口不可补 | 关键单点 |
| Galaxy 对象库 | 无法部署/修改对象 | 定期导出 | 导入备份，约30分钟 | 重要单点 |
| 通信驱动 | 对应设备数据中断 | 可配置双通道 | 切换通道，秒级 | 可消除 |
| 客户端工作站 | 单工位不可看 | 多客户端 | 换机登录 | 非单点 |
可以看到，真正需要投入灾备资源的是引擎与历史库，而通信驱动可以通过双通道设计把单点"消掉"，客户端则天然具备冗余。
四、RTO 与 RPO 的定义与取值
RTO（Recovery Time Objective，恢复时间目标）指从故障发生到业务恢复可接受的最长停机时间；RPO（Recovery Point Objective，恢复点目标）指可接受的最大数据丢失量，通常用时间表示。两者是灾备等级的核心量化指标，必须与业务方共同确认，而不是由IT单方面设定。
举例说明：若某产线监控要求"停机不超过15分钟、历史数据丢失不超过5分钟"，则对应 L2 温备等级，RTO=15min、RPO=5min。此时设计要点是：
- Historian 采用主备复制，复制周期设为 ≤5min，保证 RPO 达标；
- 备用引擎保持配置同步，切换脚本预置，人工确认后启动，控制在15min内；
- 每季度做一次切换演练，实测RTO，若超过15min则需优化启动流程或改为自动切换。
五、灾备等级划分的落地原则
等级划分应遵循"按业务定级、按组件落实"的思路：先对每个监控区域（如反应釜区、罐区、公用工程）评定业务重要性，再映射到 L0～L3，最后把等级要求分解到具体组件。同一个平台内允许不同区域采用不同等级，例如安全联锁相关区域用 L3，辅助泵房用 L1，这样既保证关键业务，又避免整体过度投资。