1. 课程导入与PI System高可用灾备全景
在流程工业、电力、水务、制药等连续生产场景中，PI System 往往承担着"运行数据底座"的角色：现场仪表与 DCS/PLC 的数据经接口采集进入 PI Data Archive，再由 PI AF 建立资产模型与计算上下文，最终通过 PI Vision、PI Web API 等通道呈现给操作、工艺、设备与管理层。一旦这条链路中断，损失的不只是"看不到趋势图"，而是历史数据缺口、KPI 计算失真、报警与绩效系统连锁失效。因此，本课程的第一个核心认知是：高可用与灾备不是给 PI 加一个"备份插件"，而是围绕数据从产生到消费的整条链路做分层设计。
一、先看清对象：PI System 的组件与各自的可用性诉求
PI System 并非单一软件，而是一组协同组件。理解高可用，必须先区分每个组件"怕什么"。
- PI Interface（接口）：负责从 DCS、PLC、OPC Server、 historians 采集数据。它最怕的是采集节点宕机导致的数据丢失。PI 接口通常自带缓冲（Buffering），当 PI Data Archive 不可达时把数据暂存本地，恢复后回填，这是第一道数据保护。
- PI Data Archive（PI DA）：时序数据核心，存储压缩后的历史数据。它是整个体系的"心脏"，可用性要求最高，通常采用 PI Collective（集合）实现多成员冗余。
- PI AF Server：承载资产模型、模板、分析计算。它依赖 PI DA，同时被 PI Vision、PI Web API 依赖，属于"模型中枢"。
- PI Vision：Web 可视化层，用户直接访问。它本身可多实例部署，通过负载均衡对外提供服务。
- PI Web API：面向 REST 的访问层，供第三方系统、移动端、报表工具调用，同样需要多实例与负载均衡。
可以看到，不同组件的可用性策略并不相同：接口靠缓冲，PI DA 靠集合，AF 靠故障转移，Vision/Web API 靠横向扩展。把它们混为一谈，是灾备设计中最常见的误区。
二、从单点到集群：可用性的四个层级
建立整体视图时，可以用"层级"来组织认知。第一层是单点部署：所有组件装在一台服务器上，适合试点与小型场景，但任何一次硬件故障都会导致全线中断。第二层是组件冗余：PI DA 组成 Collective，接口启用缓冲，AF 配置为高可用对。第三层是同城高可用：在同一城市的不同机房或不同机架部署冗余成员，抵御单机房断电、网络中断。第四层是异地灾备：在数百公里外的站点保留数据副本与可切换的服务实例，应对区域性灾难。
需要强调的是，层级不是越高越好，而是要与业务连续性目标（RTO/RPO）匹配。RTO 指允许的中断时长，RPO 指允许丢失的数据量。例如某化工厂要求"关键装置数据 RPO≤5 分钟、RTO≤30 分钟"，那么接口缓冲周期、Collective 同步方式、异地复制频率都要围绕这两个数字反推，而不是凭感觉堆机器。
三、把"高可用"和"灾备"分开看
很多团队把两者混用，导致设计目标模糊。可以这样区分：高可用（HA）解决的是"局部故障不中断"，例如一台 PI DA 成员宕机，Collective 自动把读写切到另一成员，用户几乎无感知；灾备（DR）解决的是"区域灾难后能恢复"，例如机房整体断电，需要在异地站点用数据副本重建服务。HA 追求的是秒级到分钟级的切换，DR 追求的是小时级甚至更长的恢复，但必须保证数据副本可用。
两者在 PI System 中的落点也不同。HA 主要依赖 PI Collective、AF 高可用对、Vision/Web API 多实例；DR 则依赖数据复制机制、异地副本、以及一套经过演练的切换与回切流程。一个常见的错误是：只做了 Collective，就以为"已经有灾备了"。实际上 Collective 成员通常在同一机房或同城，无法抵御区域性灾难。
四、一个可参考的目标设定示例
下面给出一个教学示例（参数为合理假设，用于说明方法，不代表任何实际项目实测值）。假设某装置区有 3 套 DCS，约 12000 个位号，关键 KPI 看板 15 个，要求：
| 指标 | 目标值 | 对应设计动作 |
|---|---|---|
| RPO（数据丢失） | ≤ 5 分钟 | 接口缓冲周期设为 1 分钟，PI DA 集合同步间隔 ≤ 1 分钟 |
| RTO（服务恢复） | ≤ 30 分钟 | AF 主备切换脚本化，Vision/Web API 通过负载均衡摘除故障节点 |
| 异地副本延迟 | ≤ 15 分钟 | 异步复制任务每 5 分钟增量同步一次 |
| 演练频率 | 每季度 1 次 | 模拟主成员宕机、模拟机房断电，记录实际切换耗时 |
这张表的意义在于：先定目标，再定架构。如果 RPO 要求是 0，那么接口缓冲和同步机制都要重新设计；如果 RTO 允许 4 小时，就没必要为秒级切换投入过高成本。目标不同，架构选择完全不同。
五、本课程将覆盖的主线
围绕上述全景，后续内容会沿着几条主线展开：PI Data Archive Collective 的成员规划、同步机制与故障转移验证；PI AF 的高可用部署与模型一致性保障；PI Interface 的缓冲、冗余与数据回填；PI Vision 与 PI Web API 的横向扩展和负载均衡；同城与异地数据复制方案；以及切换演练、监控告警与日常运维检查。每一条主线都会落到具体的配置对象、参数和判断依据上，而不是停留在"要做高可用"的口号层面。