3. 高可用需求分析与SLA定义

高可用架构设计不能从“上双机、做集群”开始，而必须从业务连续性要求出发。同样是AVEVA监控平台，一条连续生产线上的实时监控与一个只用于月度报表的历史查询系统，对可用性的要求可能相差一个数量级。如果需求没有量化，架构设计就会陷入两种典型误区：一是过度设计，为可用性要求只有99%的系统堆叠昂贵的冗余组件；二是设计不足，为停机一小时就造成重大损失的产线只做了单机备份。本节的任务，就是把模糊的“系统要稳定”转化为可度量、可验证、可验收的SLA指标。

一、业务连续性要求：从业务损失反推可用性等级

业务连续性要求描述的是“系统不可用时，业务会受到什么影响”。在AVEVA监控平台场景中，需要先识别关键业务功能，再评估其中断后果。通常可以把功能分为三类：

• 实时监控与报警：操作员依赖画面、趋势和报警判断工况。中断意味着失去对现场的感知，属于最高优先级。
• 数据采集与历史存储：采集中断会造成数据缺口，影响后续追溯、报表和优化分析，但短时中断不一定立即造成安全事故。
• 组态、报表与运维管理：短时不可用通常只影响工程师效率，可安排在维护窗口内恢复。

可用性等级常用“年停机时间”衡量。以365天为基准：99%（两个9）允许年停机约87.6小时；99.9%（三个9）约8.76小时；99.95%约4.38小时；99.99%（四个9）约52.6分钟。需要强调的是，这里的停机时间是计划外不可用时间，计划维护窗口通常单独约定。对于AVEVA监控平台，实时监控功能一般建议不低于99.9%，关键产线可要求99.95%；历史存储可略低，但数据完整性要求往往更高。

二、RTO与RPO：两个必须分开定义的指标

RTO（Recovery Time Objective，恢复时间目标）回答“故障发生后，多久必须恢复服务”；RPO（Recovery Point Objective，恢复点目标）回答“允许丢失多长时间的数据”。两者常被混为一谈，但工程含义完全不同：RTO约束的是恢复速度，RPO约束的是数据回退深度。

举例说明：某AVEVA监控平台设定实时监控RTO为5分钟、RPO为0（不允许丢失报警和关键实时数据）；历史数据库RTO为30分钟、RPO为5分钟（允许最多丢失5分钟历史数据）。这两个指标直接决定了技术方案：RPO为0意味着实时数据链路需要同步复制或双写；RPO为5分钟则允许异步复制加定期快照。RTO为5分钟意味着故障切换必须自动完成，不能依赖人工判断和手动启动。

三、故障场景与影响分析

定义SLA之后，需要系统梳理可能破坏SLA的故障场景。建议按“故障域”分类，逐一分析影响范围、可检测性和恢复手段。常见场景包括：

• 单节点故障：采集服务器、历史库节点或应用服务器宕机。影响范围取决于是否有冗余节点，通常可通过集群自动切换恢复。
• 网络故障：控制网与监控网之间的链路中断，或交换机故障。可能导致采集数据无法上传，但现场控制不受影响。
• 存储故障：历史库磁盘损坏或阵列降级。影响历史数据读写，若RPO要求高，需要RAID加复制双重保护。
• 软件故障：服务进程崩溃、内存泄漏、数据库死锁。可通过进程守护和自动重启缓解，但频繁重启说明存在根因。
• 站点级故障：机房断电、火灾、水淹。需要异地灾备或至少异地备份，RTO通常以小时计。
• 人为误操作：误删配置、误停服务、错误发布。需要通过权限控制、变更审批和快速回滚降低影响。

对每个场景，应记录：触发条件、影响的功能、预计中断时长、是否可自动检测、恢复动作和验证方式。这张分析结果是后续架构选型的直接依据。

四、从SLA到架构约束

SLA指标一旦确定，就会转化为具体的架构约束。RTO为5分钟且要求自动切换，意味着不能采用“人工发现—上报—手动启动备机”的流程，必须部署健康检查、仲裁和自动故障转移机制。RPO为0意味着实时数据不能只写入单节点后再异步复制，而需要同步复制或双写，这会带来写延迟和一致性设计的权衡。RPO为5分钟则允许异步复制，架构复杂度明显降低。

此外，SLA还需要定义测量方式，否则无法验收。建议明确：统计周期（按月或按年）、不可用判定标准（连续不可用超过多少秒计入）、计划维护是否扣除、以及由谁监测和记录。例如，可以约定“以监控系统每30秒探测一次服务端口，连续3次失败判定为不可用，单次不可用超过60秒开始计入停机时间”。这些细节看似琐碎，却是后续运维争议的焦点。

五、需求分析交付物示例

综合以上分析，可以为AVEVA监控平台整理一份SLA定义表，作为架构设计和验收的依据。以下为示例结构，实际数值需根据项目业务要求确定：