告警太多等于没有告警：把六十条砍到五条

做监控告警最容易犯的错，是把所有异常都设成告警。我们服务上线初期配了六十多条告警规则，结果每天收两百多条通知，所有人很快就开始忽略。真正出事那天，那条告警混在两百条里没人看。后来重做了告警策略，核心思路是把告警分成三类分别处理。第一类是必须立刻叫人的，条件是影响用户且无法自愈，比如核心接口错误率超过阈值持续两分钟、数据库主从延迟超过三十秒。这类不超过十条，走电话加短信，二十四小时响应。第二类是可以等一等的，影响范围有限或有降级方案，比如某个非核心功能报错、磁盘使用率超过百分之八十。这类走群消息，工作时段响应。第三类是只需记录不需要通知的，比如偶发的单次超时、客户端主动断开连接。这类只写日志，进周报复盘。分类的关键判据不是严重程度，是是否需要人立刻介入。很多团队把严重程度当分类标准，结果所有标为严重的都要通知，等于没分类。落地时有三个实践比较有效。一是所有告警必须有对应的处理手册链接，没有手册的告警不允许上线，因为收到通知的人往往不是写代码的人。二是告警要能自愈的先自愈，比如重启、扩容、切流，自愈成功的降级为记录。三是每个月统计告警数量，排名前五的规则要么优化阈值要么改成记录，让告警总数保持下降趋势。做完之后我们的告警从每天两百条降到每天五条以内，出事的响应时间反而从平均四十分钟降到八分钟。