最近到了新部门，发现日报警1.5K，报警量太多了，所以团队内部的很多同学把报警群给屏蔽了。其实这个也容易理解，这个数量下的报警，已经没有任何效果了。
这种情况导致的后果比较严重，一是真的出现问题了没有人跟进，需要等其它团队反馈或者用户反馈，错误持续很长时间，二是比较影响团队口碑和士气。
正好刚到团队，做一下报警治理。我认为报警治理是稳定性治理的一部分，以前写过稳定性实战指南，里面有部分报警治理的思路，这次正好进行细化处理一下。
治理目标
做任何事情都要有一个目标，用于判断事情完成的怎么样。
我的目标是：报警量少（日均10个以内）、报警及时、真的有问题。
有同学问要不要区分Warning和Critical，我认为不需要，就是所有的加起来少于10个，因为无论哪个过多都说明是有问题的。如Warning虽然不严重，但频繁报肯定是不对的。
处理原则
- 合理设置阈值：一直在报警，没人跟进，但无重大系统影响的，重新设置合理的阈值，只有突破阈值再报警
- 短期无法处理：已确认问题，但短时间无法解决，单独拉报警群，相关报警报到新报警群，减少对大家的打扰
处理思路
先做报警统计，将最近几天的报警做个排序。
然后根据不同的报警使用不同方案进行处理。处理的情况分为几类
1.阈值类
- 尽量不要用纯数值，最好使用比例。如以前是通过错误数量来判断，最好改成错误比例
- 同一场景下的不同资源，配置不同阈值。如都是模型调用，但是有的模型效果好，有的模型差，就需要区分，不要用同一个阈值
- 排除无效的影响因素。如模型监控主要监控官方模型，用户自定义模型没必要关注。或者一些无需监控的路径也给排除掉。
- 纯调整阈值。这种是最简单的，主要是配置的不合理，可以看24h或者72h的报警情况，配置的刚刚不报警就好。
- 有些报警重复了，直接给暂停掉
- 埋点数据有问题，需要进行修复
2.报警频率
- 修改报警的监控时间、检测频率、消抖策略等
3.拆分报警群
- 有时候一些报警属于别的team，最好进行拆分，要不然相互打扰
一般上面几个操作处理完成后，剩下的都是真的有问题的部分了，需要安排同学跟进，每周对一下进度。这时候一定要强力推进，不推进根本解决不了。当然，这些问题有的也确实不是很好处理，大部分都属于技术债的一部分，但我个人认为对自己的成长还是很有帮助的。
像我们这次就处理了很多问题，panic、OOM、TLB500/502/504等问题。
经过一个月的治理，日报警在二十个左右了，线上真正的问题我们能够及时发现，不再依赖别的团队和用户反馈了。而且可以建立值班制度和应急响应了。
至于为什么还没到10个，是因为技术债确实有点多，不好处理，再push一下应该能更好一些。
后续处理
其实后面还有很多事情要做
- 报警仍然需要继续治理。问题再难，也得继续干啊。
- 报警规则优化与补全。随着业务的发展，一些报警规则需要变了，一些报警规则需要加了。
- 报警看板优化与补全。同报警规则。
- 值班制度完善。需要列出关注的核心目标，如接口成功率、error log、慢查询情况，每周周会进行跟进。
总结
我始终觉得稳定性治理是业务功能的重要组成部分，一个不稳定的系统很可能导致整个产品无法提升到更高的水平。