如何做报警治理

最近到了新部门，发现日报警1.5K，报警量太多了，所以团队内部的很多同学把报警群给屏蔽了。其实这个也容易理解，这个数量下的报警，已经没有任何效果了。

这种情况导致的后果比较严重，一是真的出现问题了没有人跟进，需要等其它团队反馈或者用户反馈，错误持续很长时间，二是比较影响团队口碑和士气。

正好刚到团队，做一下报警治理。我认为报警治理是稳定性治理的一部分，以前写过稳定性实战指南，里面有部分报警治理的思路，这次正好进行细化处理一下。

治理目标

做任何事情都要有一个目标，用于判断事情完成的怎么样。

我的目标是：报警量少（日均10个以内）、报警及时、真的有问题。

有同学问要不要区分Warning和Critical，我认为不需要，就是所有的加起来少于10个，因为无论哪个过多都说明是有问题的。如Warning虽然不严重，但频繁报肯定是不对的。

处理原则

1. 合理设置阈值：一直在报警，没人跟进，但无重大系统影响的，重新设置合理的阈值，只有突破阈值再报警
2. 短期无法处理：已确认问题，但短时间无法解决，单独拉报警群，相关报警报到新报警群，减少对大家的打扰

处理思路

先做报警统计，将最近几天的报警做个排序。

然后根据不同的报警使用不同方案进行处理。处理的情况分为几类

1. 阈值类

• 尽量不要用纯数值，最好使用比例。如以前是通过错误数量来判断，最好改成错误比例
• 同一场景下的不同资源，配置不同阈值。如都是模型调用，但是有的模型效果好，有的模型差，就需要区分，不要用同一个阈值
• 排除无效的影响因素。如模型监控主要监控官方模型，用户自定义模型没必要关注。或者一些无需监控的路径也给排除掉。
• 纯调整阈值。这种是最简单的，主要是配置的不合理，可以看24h或者72h的报警情况，配置的刚刚不报警就好。
• 有些报警重复了，直接给暂停掉
• 埋点数据有问题，需要进行修复

2. 报警频率

• 修改报警的监控时间、检测频率、消抖策略等

3. 拆分报警群

• 有时候一些报警属于别的team，最好进行拆分，要不然相互打扰

一般上面几个操作处理完成后，剩下的都是真的有问题的部分了，需要安排同学跟进，每周对一下进度。这时候一定要强力推进，不推进根本解决不了。当然，这些问题有的也确实不是很好处理，大部分都属于技术债的一部分，但我个人认为对自己的成长还是很有帮助的。

像我们这次就处理了很多问题，panic、OOM、TLB500/502/504等问题。

经过一个月的治理，日报警在二十个左右了，线上真正的问题我们能够及时发现，不再依赖别的团队和用户反馈了。而且可以建立值班制度和应急响应了。

至于为什么还没到10个，是因为技术债确实有点多，不好处理，再push一下应该能更好一些。

后续处理

其实后面还有很多事情要做

1. 报警仍然需要继续治理。问题再难，也得继续干啊。
2. 报警规则优化与补全。随着业务的发展，一些报警规则需要变了，一些报警规则需要加了。
3. 报警看板优化与补全。同报警规则。
4. 值班制度完善。需要列出关注的核心目标，如接口成功率、error log、慢查询情况，每周周会进行跟进。

总结

我始终觉得稳定性治理是业务功能的重要组成部分，一个不稳定的系统很可能导致整个产品无法提升到更高的水平。

最后

大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）

我的个人博客为：https://shidawuhen.github.io/

往期文章回顾：

1. 设计模式

2. 招聘

3. 思考

4. 存储

5. 算法系列

6. 读书笔记

7. 小工具

8. 架构

9. 网络

10. Go语言