上个月我们线上服务半夜挂了，监控系统发了37条告警，最后真正导致挂掉的是一条被淹没在大量warning里的磁盘慢IO。值班同事按习惯把几个P2告警点了确认，正准备继续睡，然后P0就来了。我盯着告警面板想了很久：我们装了Prometheus、Alertmanager、Zabbix，还有一堆自定义脚本，天天在调阈值，可为什么关键故障永远是被用户骂醒的？
后来我翻了一下过去90天的告警记录，总共21483条，其中被确认后不再重复的有20319条，真正需要人工处理的事件只有89条。也就是说99.6%的告警是噪声。更讽刺的是，那条磁盘慢IO的告警其实早就出现了，但它的级别是warning，因为阈值当时设的是超过200ms才报警，而实际延迟已经到150ms了。所有同事都在群里说‘最近磁盘有点慢’，但没人觉得该改阈值。这就是典型的阈值依赖——你设定了一个标准，大脑就会自动忽略标准以下的所有异常。
换个角度想，告警疲劳不是数量问题，是信息熵问题。每条告警如果只告诉你‘值是多少’，那跟白噪声没区别。真正有用的告警应该包含上下文：这个指标跟昨天同一时段比有什么变化？它跟上游哪个接口的延迟强相关？它最近的趋势是在收敛还是发散？我见过最好的一个自定义告警来自一个老运维，他写了一个脚本，不是简单比较CPU使用率，而是比较CPU使用率与负载均衡连接数之间的比值变化，一旦偏离超过30%就触发。后来他们真的在流量暴增前15分钟收到了告警，提前扩容避免了事故。
如果你也想治一治自己的告警系统，我的建议是别急着加更多规则，先做减法。第一步，统计过去30天所有告警类型，列出前20个，问自己：这20类里哪怕一条不处理最坏后果是什么？如果是‘没什么后果’，直接删掉或降级为日志。第二步，把阈值从固定值改成动态基线，任何指标如果比过去同一时间窗口（24小时前/7天前）的均值偏离3倍标准差，才触发告警。第三步，为每条告警写清楚‘接收人需要做什么动作’，如果写不出来，这条告警就是无效的。这三步做完，我们告警量从每天700条降到了30条左右，而且关键故障都能在发生前10分钟被捕捉到。
最近大家都在聊AIOps，但我觉得AI不是银弹。你先把告警当作文本去分析，观察一下哪些关键词永远出现在一起，哪些告警序列永远在半夜固定时间出现（大概率是定时任务重时段），这些用简单的关联规则就能找出规律。我踩过最大的坑是买了一个智能告警平台，它把3000条告警智能合并成了40条，看起来很美，但合并后的第一条就把我搞懵了——因为它把服务重启和磁盘空间不足合并成一件事，理由是两者在历史数据里经常同时发生。所以别迷信智能，自己动手榨干现有数据里的信息量，才是性价比最高的路径。
