告警风暴治理：预警通知的合并与降噪实践

告警风暴是运维团队的噩梦：一个小故障触发成百上千条告警，值班人被电话和短信淹没，真正的根因反而被埋在噪音里。治理告警风暴不是少发告警，而是让每一条发出的告警都值得被看到。预警通知作为末尾一公里，在合并降噪中扮演关键角色。

告警风暴的成因

根因通常有三类：监控规则粒度过细、上游故障扇出下游、没有抑制与依赖关系。如果监控系统原生没有降噪能力，预警通知这一层就必须自己加上合并逻辑，否则就是把风暴原封不动地送到值班人手机上。

降噪治理的三层做法

1. 抑制：同主机、同指标在时间窗内只发一次，重复告警只更新工单。
2. 聚合：同故障域的多条告警合并为一条摘要，例如"机房 A 12 台主机离线"。
3. 分级：P0 穿透式立即通知，P2 攒批在工作时间汇总发送。

一个简化的聚合伪代码如下：

buckets = {}   # key=故障域, value=告警列表

def on_alert(alert):
    key = alert.fault_domain
    buckets.setdefault(key, []).append(alert)
    if alert.level == "P0":
        flush(key)   # 紧急立即发
    else:
        schedule_flush(key, delay=60)  # 普通攒1分钟再合并发

def flush(key):
    items = buckets.pop(key, [])
    summary = "%s 共%d条告警, 首条:%s" % (key, len(items), items[0].name)
    send_voice(oncall_mobile, summary[:70])

治理中的注意事项

• 合并不能吞掉根因，摘要里要写清楚关键的一条。
• 抑制窗口不宜过长，通常 30 到 120 秒，避免漏报。
• 风暴过后要有一份汇总报告，帮团队复盘规则是否过细。
• 电话通道只发合并后的关键摘要，明细走短信和工单。

治理效果的量化指标

治理后的效果

经过抑制、聚合、分级三层治理，原本几十通电话可能收敛为一通关键语音加一条汇总短信。互亿无线按成功计费，降噪后发送量下降，成本也随之降低，可谓一举两得。

风暴治理的实施顺序

不要指望一步到位，建议先做抑制（同指纹时间窗内只发一次），这是见效快的一步；再做聚合（同故障域合并摘要）；然后才是分级（P0 穿透、P2 攒批）。每做一步观察一周回调数据，确认没有误合并再继续。

风暴过后留一份汇总报告，看哪些规则触发过多，反过来把监控规则调粗，从源头减少噪音。

治理后的复盘

每次经历一次告警风暴后，留一份复盘：风暴从哪条规则开始、扇出了多少条、合并策略有没有漏掉根因。把复盘结论变成规则改进，下次同类故障就不会重演。互亿无线按成功计费，降噪后发送量下降，成本和信噪比一起改善。

治理工具的落点

抑制、聚合、分级这三层逻辑，建议做在告警网关这一层，而不是散落在各监控系统里。这样统一规则、统一回顾，新接监控系统直接复用网关，不必重新写降噪逻辑。

治理的持续动作

风暴过后留复盘，把误合并、漏报的案例补进规则，下一次同类故障就不会重演。治理是个持续过程。

经过抑制、聚合、分级三层治理，几十通电话收敛为一通关键语音加一条汇总短信，值班人终于能聚焦根因。

治理告警风暴不是少发告警，而是让每一条发出的告警都值得被看到。把逻辑收敛在告警网关，长期复用，效果会越来越稳。

把抑制、聚合、分级做扎实，值班人从信息过载回到聚焦根因，这就是治理的价值。

告警风暴治理是个持续过程，注册免费试用先把预警通知这条出口管起来。