告警规则怎么设计才不吵：去抖、分级与收敛

告警系统上线后最常见的结局是被静音。原因几乎总是同一个：告警太多，其中绝大多数不需要任何人做任何事。一旦运维形成「这个群里的消息可以不看」的习惯，真正重要的那一条也会被淹没，而这比没有告警更危险 —— 因为所有人都以为有人在看。

抖动是告警风暴的主要来源

一个在阈值附近来回波动的数值，用简单的「大于则告警、小于则恢复」规则，会在几分钟内产生几十条告警和恢复。这不是传感器坏了，是测量值本身就有噪声。

• 迟滞：触发阈值和恢复阈值设成两个不同的值，例如超过 80 触发、低于 75 才恢复，中间的区间不产生状态变化；
• 持续时间：要求条件连续满足一段时间才触发，瞬时尖峰直接忽略。这一条对多数场景最有效；
• 最小间隔：同一条规则在一定时间内只通知一次，重复触发只更新状态不再发通知。

三者可以叠加使用。需要注意持续时间会延迟告警，对真正紧急的指标要权衡 —— 安全相关的告警宁可误报也不能晚报，这类规则应当单独处理。

分级的依据是「要不要立刻有人起床」

分级标准不该按指标的技术严重程度定，而应按需要的响应方式定。一个实用的三级划分是：需要立刻有人处理的、需要在工作时间处理的、以及只需要记录供事后分析的。第三类根本不该发通知，放在看板上即可。

如果所有告警都是第一级，说明分级没有做。一个粗略的检验是统计最近一个月的告警里有多少真的触发了处置动作 —— 比例低于一半，说明阈值或分级需要调整。

同一根因要收敛

网关断网时，它下面的几十台终端会同时报「离线」。这几十条告警说的是同一件事，而真正需要修的是网关。收敛的做法是建立设备之间的依赖关系，上级设备异常时抑制下级的同类告警，只发一条带影响范围的通知。

类似地，同一台设备的多个指标同时越界，往往源于一次供电或通信异常，合并成一条比分开发更有用。实现上通常是在规则引擎后面加一层聚合窗口，按设备或按站点归并。

恢复通知不能省

只发告警不发恢复，值班人员无法判断问题是否还在。更麻烦的是跨班次交接时，接班的人看到一堆历史告警却不知道哪些已经解决。恢复通知的内容应当包含持续时长，这个数字在事后复盘时很有用。

最后一条建议：告警规则本身要能被审计。谁在什么时候改了哪条规则的阈值，应当有记录。在制造业这类项目里，「为什么那次没报警」是事故复盘的必问问题，而没有变更记录就答不上来。告警阈值的依据与变更记录属于交付物，建议随物联网平台解决方案一并移交。