很多团队把监控告警配反了，越告越麻木反而漏掉真问题

"昨天晚上手机响了三十多次，全是什么磁盘使用率超过70%的告警，结果今早发现数据库主从断了，一条告警都没有。"这是一位客户在复盘会上原话说的。他的团队配了200多条告警规则，每天收到上百条通知，早就麻木了。

这不是个别现象。告警配得越多越细致，反而越容易漏掉真正要命的故障。问题出在告警体系的优先级倒挂了。运维团队花大量时间处理低优先级告警，真正出问题时反而被淹没了。

常见误区：把阈值当防线

很多运维人员觉得，CPU超过60%就该告警，磁盘超过70%就该告警，内存超过80%就该告警。听起来没毛病，但业务系统本来就有波峰波谷，大促期间CPU跑70%完全正常，这时候告警除了制造焦虑没有任何意义。

阈值不是越低越好，而是要跟业务节奏匹配。正确做法是先拉过去30天的监控数据，找到正常波动的P95值，在P95基础上上浮15%作为warning阈值，上浮30%作为critical阈值。这样告警量能砍掉60%以上。

还有一个常见问题：告警只有一级，不分轻重缓急。磁盘使用率85%和服务不可用用同一种方式通知，运维看到通知根本不知道该放下手头的事还是等会儿再处理。

正确做法：三级告警加收敛策略

把告警分成三个等级。P0级是业务直接影响范围的，比如服务不可用、数据库连接池耗尽、主从同步中断，这类告警必须电话加短信双通道通知，响应时间5分钟以内。P1级是资源预警，比如磁盘将在24小时内写满，走企微或钉钉通知，响应时间30分钟。P2级是信息性通知，汇总后每天发一次日报即可。

然后做告警收敛。同一个指标在5分钟内多次触发，只告第一次；同一台机器上多个指标同时异常，合并成一条告警通知。这两条规则实施后，上面那位客户的日均告警从120多条降到了15条左右，而且再没漏过P0级故障。

检查清单

第一，统计当前告警规则数量，超过100条就该做一次裁剪。第二，检查最近30天告警的准确率，误报率超过50%说明阈值需要重新校准。第三，确认P0级故障是否有独立的升级通道，不能淹没在普通告警里。第四，每月做一次告警体系巡检，把不再适用的规则及时清理掉。告警体系跟安全体系一样，需要持续维护才能保持有效。