告警太多没人看？云上告警降噪与智能告警实战
去年一个客户跟我吐槽：“我们每天收到500多条告警，谁看得过来？现在大家已经把告警群静音了，真出事了反而没人知道。”
我问他：“那你怎么知道哪些是真问题？”
他沉默了一会儿：“看运气。有时候用户投诉了才发现。”
这不是个例。告警疲劳是运维团队最普遍、最隐蔽的杀手。告警太多，大家就不看了；大家不看，真出事了就没人管了。
今天聊聊告警降噪与智能告警。不是那种“告警很重要”的废话，而是帮你理清楚：怎么减少无效告警？怎么让告警分轻重缓急？怎么让团队敢看告警、愿意看告警？
01 告警不是越多越好
很多人有个错觉：告警设得多，覆盖就全，出事就能及时发现。
错。
告警设得越多，信噪比越低。有用的告警被淹没在噪音里，团队产生疲劳，最后谁都不看。
反常识观点：告警不是越多越好，是越精越好。 一条准确的P0告警，胜过一百条没人看的P3告警。
那家客户一天500条告警，大部分是“CPU超过80%持续1分钟”这种。短暂波动就告警，半夜频繁被吵醒，大家直接静音了群。结果有一次核心数据库连接池爆了，告警也发了，但被淹没在几百条消息里，没人看到。等用户投诉才发现，已经过去半小时。
02 先分级：P0/P1/P2/P3
告警降噪的第一步，不是删规则，是分级。
按紧急程度和影响范围，把告警分成四个等级：
P0（紧急）：核心业务不可用、数据丢失、安全事件。必须立即处理，电话+短信+IM全渠道轰炸。SLA：5分钟内响应。
P1（严重）：核心功能受损、大面积慢响应。需要快速响应，但不至于半夜叫醒所有人。SLA：30分钟内响应。
P2（一般）：非核心功能异常、潜在风险。工作时间处理即可。SLA：4小时内响应。
P3（提醒）：日常波动、资源预警、例行信息。不需要立即处理，看板展示就行。SLA：当天内看一眼。
那家客户后来把所有告警重新分级。P0只保留了三个：支付成功率低于95%、核心数据库不可用、安全告警。其他大部分降到了P2、P3。效果立竿见影：P0告警一周不到5条，大家敢开声音了。
03 降噪三板斧：聚合、静默、抑制
分级只是第一步。真正的降噪靠三个手段。
聚合：把相同的告警合并
同一个问题在一分钟内触发10次告警？合并成一条，告诉你“10次”。别刷屏。
Prometheus Alertmanager、云厂商的告警中心都支持分组聚合。按告警名称、标签维度聚合，相同告警只发一次。
静默：已知问题暂时闭嘴
正在修一个故障，已知影响范围，别再发了。设个静默时间，比如30分钟，期间这个告警不发送。
半夜做变更、维护窗口，也可以提前设静默，避免告警风暴。
抑制：关联告警只发根因
服务器宕机，会引发上面几十个服务告警。但这些告警都是“果”，不是“因”。配置抑制规则：如果“服务器宕机”告警触发了，就抑制它引发的其他告警。只发一条根因告警，别发几十条噪音。
那家客户配置了抑制规则后，P0告警量没变，但P2、P3从每天500条降到了50条。运维负责人说：“以前看告警群像刷屏，现在终于能看清了。”
04 智能告警：让系统替你判断
静态阈值总是有局限。CPU超过80%告警，可能业务正常时就是80%。低于80%告警，可能业务高峰期已经90%了，但没到阈值就不发。
智能告警用动态阈值、异常检测来解决这个问题。
动态阈值：系统学习过去7-30天的数据，按时间段设不同阈值。凌晨2点CPU超过50%可能异常，下午2点超过80%才异常。自动适应业务规律。
异常检测：系统识别“异常模式”，不依赖固定阈值。比如过去十分钟错误率突然翻倍，哪怕绝对值还很低，也可能有问题。
预测告警：系统预测未来一小时磁盘会满，提前发告警，让你有时间扩容，而不是等满了再处理。
云厂商都提供了这些能力：AWS DevOps Guru、Azure Anomaly Detector、阿里云智能告警。用起来，能省不少心。
05 告警治理不是一次性的
告警降噪不是设完就完，要持续治理。
定期复盘：每周看看哪些告警发了但没人处理。要么降级，要么改规则，要么删掉。
看响应率：P0告警的响应率应该是100%。低于100%，说明有问题：要么分级不对，要么人不够。
看MTTA：平均告警响应时间。目标：P0 < 5分钟，P1 < 30分钟。持续跟踪。
那家客户把告警治理纳入每周运维例会。每次看三件事：上周发了多少告警？P0响应率多少？哪些告警需要调整？三个月下来，告警总量从每天500条降到每天50条，P0响应率从40%升到100%。
写在最后
告警不是越多越好。无效告警是噪音，会掩盖真正的危机。
那家客户最后做了一件事：把告警群的名称从“告警通知群”改成了“值班响应群”。运维负责人说：“改名是为了提醒大家，这个群不是来看告警的，是来响应问题的。”
告警是手段，响应才是目的。别让噪音淹没了信号。
你的告警群，现在是在“刷屏”还是在“响应”？
