告警静音三天后，我才发现自己一直在盯错的东西

上个月干了一件挺冒险的事：把项目里所有非 P0 的告警通知全关了，只留两条短信。三天。

起因很简单。凌晨两点手机连着震了十几下，爬起来一看，全是"CPU 使用率超过 80%"。查了半天，是白天没跑完的一个批处理。第二天早上在群里提了一句，大家笑笑就过去了。但我心里一直别扭——这套告警是我配的。

后来我翻了一个月的告警记录，一共四百多条。真正需要人动手的，大概五条。剩下的是什么？磁盘用了 78%、内存到了 65%、某个接口 P99 从 120ms 涨到 180ms。这些数字本身没毛病，问题是我把它们都当成了"要处理的事"。

阈值这东西，一开始基本都是照抄的。网上搜一套模板，或者看别人项目里怎么写，直接搬过来。80%、5 分钟、连续三次。看着挺专业，其实跟自己这套系统的脾气一点关系都没有。

我们那个服务每天上午十点和晚上八点各有一个流量高峰，CPU 到 85% 是正常的。可阈值是 80%，于是每天准时响两次。响了三个月，所有人的反应都是"哦，又到点了"。这才是最麻烦的地方——不是误报多，是误报把真报给淹了。

静音那三天我做了件很土的事：把过去半年的告警按"是否有人处理"分了个类，再把处理过的那些倒回去看，当时到底发生了什么。

结果有点意外。真正出问题的场景，几乎都不是某个指标超阈值，而是两个指标同时往一个方向走。连接数在涨、QPS 在跌，说明下游卡住了；磁盘写入量突然归零但进程还在，那多半是挂死了。单看任何一个，都在"正常范围"内。

所以后来我把告警改了。删掉一半，剩下的改条件：不看单点值看变化率，不看绝对值看和上周同一时刻的比值。CPU 高不高不重要，重要的是它比昨天这个点高了多少。

改完一个月，告警量从四百降到六十左右。凌晨被叫起来的次数是零。

当然也踩了坑。有一次把"磁盘剩余空间"的告警删了，觉得有自动清理不用管，结果清理脚本自己挂了三天没人知道。教训是：可以降低噪音，但别把兜底的监控一起删了。

现在我的习惯是，每加一条告警先问自己一句：如果它半夜响了，我会做什么？答不上来，就不加。

听起来是废话，但真的筛掉了不少东西。