📚 课程目录第3章高可用与灾备核心指标

3. 高可用与灾备核心指标

在讨论 PI System 的高可用与灾备设计之前，必须先建立一套可量化、可验证、可写入合同的指标体系。否则“系统要可靠”“故障要快速恢复”这类表述无法转化为架构决策，也无法在故障复盘时判断是否达标。本节围绕五个核心指标展开：RTO、RPO、SLA、MTTR、MTBF，并将它们逐一映射到 PI System 的四类关键服务——数据采集、数据存储、可视化与接口服务。

一、五个指标的定义与相互关系

RTO（Recovery Time Objective，恢复时间目标）指业务从中断发生到恢复可接受服务水平所允许的最长停机时间。它回答的是“能停多久”。RPO（Recovery Point Objective，恢复点目标）指灾难发生后允许丢失的数据时间跨度，即最近一次可用恢复点与故障时刻之间的最大间隔。它回答的是“能丢多少数据”。

SLA（Service Level Agreement，服务等级协议）是把可用性、RTO、RPO 等承诺固化为可考核条款的协议，通常以可用性百分比、月度停机分钟数、响应与恢复时限等形式表达。MTTR（Mean Time To Repair，平均修复时间）是故障发生后完成修复并恢复服务的平均耗时，它直接决定实际 RTO 能否达成。MTBF（Mean Time Between Failures，平均故障间隔时间）是两次相邻故障之间的平均运行时长，反映系统的稳定程度。

五者的关系可以这样理解：MTBF 决定“多久坏一次”，MTTR 决定“坏了多久能修好”，二者共同决定实际可用性；RTO 是对 MTTR 的业务约束上限，RPO 是对数据保护能力的约束上限；SLA 则是把这些约束写成可追责的承诺。可用性的近似关系为：可用性 ≈ MTBF / (MTBF + MTTR)。例如 MTBF 为 8760 小时、MTTR 为 4 小时，则可用性约为 99.954%，对应全年停机约 4 小时。

二、PI System 业务连续性要求与指标映射

PI System 的核心价值在于持续、完整地记录工业过程数据。不同服务对中断和丢数的容忍度差异很大，因此不能用一个统一的 RTO/RPO 覆盖全部组件，而应分层设定。

数据采集层包括 PI Interface、PI Connector、PI Adapter 等。它们从 DCS、PLC、SCADA、 historians 等数据源读取数据。采集层通常具备本地缓冲能力，短时中断后可以补传，因此 RPO 可放宽到秒级至分钟级，RTO 目标为分钟级。但如果缓冲溢出或源系统不保留历史，丢失的数据将无法找回，所以缓冲容量和补传机制必须与 RPO 匹配。

数据存储层是 PI Data Archive 和 PI AF Server。这是全系统最关键的持久化层，RPO 应接近零，RTO 通常要求分钟级到小时级。实现手段包括 PI Data Archive 的 HA 集群（Collective）、AF 数据库的 SQL AlwaysOn 或镜像、以及归档文件的定期复制。需要特别注意的是，PI Data Archive Collective 提供的是节点级冗余，不是跨站点灾备；跨站点仍需归档复制或 PI to PI 接口。

可视化层包括 PI Vision、PI ProcessBook（已逐步退役）等。可视化服务短时不可用通常不会造成数据丢失，用户可稍后重新查看，因此 RPO 可容忍短时数据缺失，RTO 为分钟级。通过多台 PI Vision 服务器加负载均衡即可实现较高可用性。

接口服务层包括 PI Web API、PI SQL、AF SDK 等对外数据通道。这些接口往往被 MES、ERP、报表平台、移动应用调用，中断会直接导致上下游业务受阻，因此 RPO 要求零丢失，RTO 要求秒级到分钟级，通常采用双活部署加自动故障切换。

三、从业务要求推导指标：一个示例

假设某流程工厂要求：生产报表每小时生成一次，报表数据来自 PI System；安全联锁相关数据必须完整留存；操作员画面允许短暂中断但不得超过 5 分钟。据此可以推导：

报表业务：RPO ≤ 1 小时（下一次报表前数据必须完整），RTO ≤ 30 分钟。
安全相关数据：RPO = 0，不允许任何丢失，需采用同步复制或双写。
操作员画面：RTO ≤ 5 分钟，RPO 可放宽至 1 分钟。

再结合可用性目标 99.9%（年停机 ≤ 8.76 小时），可反推 MTTR 上限。若全年允许 4 次故障，则 MTTR ≤ 2.19 小时；若 MTBF 目标为 4000 小时，则全年约 2.19 次故障，MTTR 需控制在 4 小时以内。这些数字应写入 SLA 并作为演练验收标准。

提示：RTO 和 RPO 是业务指标，MTTR 和 MTBF 是运维指标。设计时先用业务指标定目标，再用运维指标做验证。不要反过来用现有 MTTR 去倒推 RTO，否则会失去业务导向。

四、指标落地：从承诺到验证

指标定义完成后，必须通过演练验证。建议每半年进行一次切换演练，记录实际 RTO 和 RPO。例如：手动停止主 PI Data Archive 节点，观察 Collective 切换时间；停止 PI Web API 主节点，观察负载均衡切换时间；模拟归档复制中断，检查恢复后数据缺口是否在 RPO 范围内。

演练结果应形成记录表，包含：故障注入方式、实际中断时长、实际数据丢失量、是否满足 RTO/RPO、改进项。只有经过验证的指标才是可信的 SLA 承诺，否则只是纸面数字。

注意：PI Data Archive Collective 的故障切换通常需要数十秒到数分钟，具体取决于节点状态和网络。若业务要求 RTO 为秒级，必须考虑 PI Web API 双活、AF 负载均衡等上层冗余，而不能仅依赖 Collective。

综上，RTO、RPO、SLA、MTTR、MTBF 不是孤立数字，而是一条从业务容忍度到架构设计再到运维验证的完整链条。只有把每个指标映射到 PI System 的具体组件和具体容忍度，高可用与灾备设计才有可衡量的依据。