10万条告警淹没运维中心：我们如何用规则引擎解决电站告警风暴

去年 7 月，宁夏一个 100MW 的集中式项目在雷雨季遭遇了一次典型的“告警风暴”。短短 15 分钟内，监控系统后台弹出了超过 3.2 万条告警信息。从箱变断路器跳闸到几百台逆变器的“电网欠压”，再到数千个组串的“电流异常”，系统界面瞬间被红色刷屏，服务器 CPU 占用率直接顶到了 95%。

这种场景对很多做电站运维的同学来说并不陌生。当电站规模从几个 MW 爬升到数百 MW，或者手里管着 50 多个分布在全国各地的工商业屋顶时，数据不再是稀缺资源，反而成了沉重的负担。运维人员面对这种“全城红点”的情况，第一反应通常不是去排查故障，而是直接关掉通知，因为根本看不过来。

我们要解决的问题很直接：如何在海量原始报文中，精准捞出那个真正导致停机的主因，并把剩下的垃圾信息给过滤掉？

为什么告警规则解读这么难

做多品牌逆变器接入时，最让人头大的不是协议对接，而是各家厂商对“告警”的定义完全不在一个频道上。比如，针对同一个“电网电压高”的故障，A 厂商可能定义为Error Code 102，B 厂商可能在Status Bit的第 5 位给个布尔值，而 C 厂商干脆只在描述字段里写一句“Grid Voltage High”。

除了格式不统一，还有三个更深层的坑：

1. 瞬时抖动导致的误报：由于环境遮挡或电网波动，某些参数在 1 秒内触发表，下一秒又恢复正常。如果系统不做延迟判定，运维群里的机器人就会疯狂刷屏。
2. 拓扑关联的从属告警：这是一个典型的逻辑陷阱。当 35kV 变电站侧跳闸后，下游的 50 台逆变器会因为收不到反馈而同时上报“通信中断”或“交流断电”。其实根源只有一个，但系统会推给你 51 个工单。
3. 存量电站的“僵尸数据”：很多老旧电站的传感器早已失效，常年挂着“辐照仪离线”或“气象站通信故障”。这些无效信息每天混在核心告警里，极大地干扰了资产管理效率。

告警引擎的架构设计：从采集层到逻辑层

为了处理这种复杂性，我们在设计监控平台架构时，将告警处理从简单的“状态位采集”升级为了三层过滤引擎。其核心思路是：不要在采集到数据的第一时间就发告警，而是先让数据在逻辑桶里“飞一会儿”。

1. 字段归一化与语义映射

这是基础。无论底层是 Modbus RTU 还是云 API，进入引擎前必须转化成标准的 JSON 格式。我们建立了一套统一的故障代码库。例如，我们将所有品牌的“电网类故障”映射到ALARM_GRID_100系列，将“硬件过热”映射到ALARM_HW_200系列。

{"original_code":"0x05A1","brand":"SUNGROW","normalized_code":"ALARM_GRID_OVER_VOLTAGE","severity":"CRITICAL","timestamp":1715832000,"duration_threshold":"30s"}

2. 时间窗口收敛（Temporal Convergence）

这是去重降噪的第一道防线。我们引入了“滑动时间窗口”机制。当接收到一个告警信号时，引擎不会立刻动作，而是开启一个 30-120 秒（根据故障等级可调）的观察期。如果在窗口内收到了“恢复信号”，则该条记录被标记为“瞬时扰动”，仅记录在后台日志中，不触发推送。通过这一步，我们可以过滤掉约 40% 的电网波动干扰。

3. 拓扑压制逻辑（Topological Suppression）

这是解决告警风暴的关键。系统需要维护一张电站的物理拓扑表：变压器 -> 汇流箱 -> 逆变器 -> 组串。逻辑引擎会执行以下规则：

• 父级压制子级：如果箱变（父节点）上报了“断路器跳闸”，那么该箱变下挂的所有逆变器（子节点）上报的“交流失压”和“通信中断”将被自动收敛，系统只生成一张针对箱变的紧急维修工单。
• 同类合并：如果 10 分钟内，同一区域的 20 台逆变器同时报“电网频率异常”，引擎会将其判定为区域性电网问题，而不是 20 个独立的逆变器故障。

告警解读与工单系统的深度耦合

很多电站资产管理系统做得不好用，是因为告警和工单是脱节的。一个好的光伏工单系统建议应该具备“自动预诊断”能力。当告警触发时，引擎不仅要告诉运维“坏了”，还要根据历史数据和规则库给出“为什么坏”的初步判断。

例如，针对“组串电流失配”告警，引擎会自动调取该逆变器过去 24 小时的 IV 曲线。如果发现电流跌落伴随着辐照度骤降，系统会自动标注“疑似阴影遮挡，建议现场排查遮挡物”；如果是长期电流偏低，则标注“疑似组件积灰或衰减”。

在实际落地中，我们发现这种“解读”比告警本身更值钱。它直接降低了对现场运维人员经验的依赖。即便是刚入行的巡检员，看到工单上的诊断建议，也能快速定位问题。

踩坑复盘：那些文档没写的细节

在对接华为、阳光、古瑞瓦特等主流厂商的云 API 时，我们发现了一些让人哭笑不得的细节。比如某厂商的 API 在凌晨 0 点会准时推送一批“虚假”的离线告警，原因仅仅是它们的云端数据库在进行例行备份。如果我们没做时间窗口过滤，运维老总的手机每晚 0 点都会准时响起。

再比如时区问题。对于跨国电站资产，如果 API 返回的是设备本地时间且不带时区偏移量，告警排序就会全乱套。我们的做法是强行在入库前统一转为 UTC 时间戳，再根据用户的浏览器时区进行前端呈现。

我们的思考与取舍

在设计这套引擎时，我们曾纠结过是否要引入 AI 异常检测。实战后的结论是：在现阶段的光伏运维中，基于确定性逻辑的规则引擎，其可靠性远高于黑盒式的 AI 模型。对于电站资产方来说，他们需要的是 全量 可解释的告警逻辑，而不是一个概率性的预测。

我们把这套沉淀了数十家厂商适配经验、具备拓扑收敛能力的接入层逻辑，封装成了中间件 (ZenovaConnect)。它不只是搬运数据，更是在搬运的过程中完成数据的清洗和语义统一。这样，无论你上层用的是哪家的监控平台或工单系统，拿到的都是已经“降噪”后的洁净数据。

最后留一个问题给各位同行：在你们的电站管理经验中，哪类告警是最让你头疼、却又不得不反复处理的“假故障”？欢迎在评论区交流避雷经验。

了解 ZenovaConnect 完整方案