个人体会，希望能帮助大家~。
报警 + 消息通道 + 自愈处理，优化监控报警
1、报警类，可以分为灰色报警、蓝色报警（重要）、红色报警（高危）；如使用zabbix；
2、每类报警单独一个报警群，黄色、15分钟必须有SRE回复，红色必须10分钟内回复；后台埋点使用自动化标记统计 报警与回复时间差，超期没有人员回复跟进，直接自动电话通知相关人员，在自动电话后5分钟未回复 处理中，那么直接后台记录超时；每日、周统计按产品线、或人员 统计总报警数、及超时数、进行考核。可以使用某钉的api接口二次开发实现用户是否恢复记录，及自动电话通知。
3、有些异常类，报警后 + 自愈自动处理。 或 巡检类 + 自愈自动处理。
所有报警类消息，及 回复记录 全部自动搜集入库，如回复信息 ，进行分类 ，如：更新，cpu 、内存、故障、系统bug等 ，在一个报警时候，通过消息中心发到相关群里，然后后面加上最近 1天、3 天、7天出现次数； 及 之前此类报警的 人员回复的信息数据展示，如 之前人员回复 更新 60%， 内存30%； 推荐 最高值操作。
4、报警类的回复统计，进行分类后查看每日、周 的排名情况 ，若是更新类报警较多，那么直接在每次更新时候，通过屏蔽消息通道接口 屏蔽此类更新相关的报警（屏蔽5分钟、10分钟自定），这样更新时候 就不报警到 相关报警群里了，但是 监控工具如zabbix还要继续展示出来。减少了更新导致的报警；
5、因为自愈、自动处理，给隐瞒了部分问题。
”如果一个机器经常出现 CPU_IDLE 报警，那么我们可以将现在的监控策略进行调整，比如说，以前 5min 内出现 5 次就报警，现在可以调整为 10min 内出现 20 次再报警，或者直接删除这个报警策略，或者将报警短信调整为报警邮件，或者各种类似的手段。但这个机器为什么出现 CPU_IDLE 报警，却并没有人去关注，更别提解决了“
每日、周统计 自愈处理的名称、次数； 按人员、 部门业务线 进行维度统计，某个自愈较多的，就要优化程序或其他问题，来减少自愈次数；某个机器突然出现同类报警数增多，有可能就有问题的预兆，报警类较多，直接有报警仪表盘展示各类报警曲线，通过曲线也发现问题。~~ 后期报警少了后，再返回来跟进为啥能引起自愈的问题，如磁盘报警一直报警就自动处理，那么某个时间自愈较多了是否代码debug日志了或者 有异常了导致日志多，导致频繁清理？

参考：
https://www.infoq.cn/article/1AofGj2SvqrjW3BKwXlN?utm_source=infoq&utm_medium=article&utm_campaign=newinfoq&utm_content=language2019&utm_term=701
摆脱无效报警？十年运维监控报警优化经验总结