无效告警优化实践总结(1)

同样是告警，对于CPU跑满这种情况需要立即处理，但对于单机健康状态告警（正常异常机器会自动置换，异常情况可能置换失败），系统并不能自动解决这种状况，但是一段时间内不处理，也不会造成影响，负载均衡设备会自动摘除。

所以这里涉及到一个告警分类的问题，当然，告警可以有很多种分类方法，分成很多种级别区别对待，但在优化无效告警的目标下，我们通过是否需要立即停下手头工作立即处理，分为三类：

1. 紧急：收到报警就需要立即执行某种操作。如CPU跑满，内存跑满等。判断标准，是否对业务有影响，以及是否有潜在的未知风险

2. 不紧急：系统并不能自动解决目前状况，但是一段时间内不处理，也不会造成影响。如单机出现访问不通异常。判断标准，对业务无影响，基本无潜在的风险，但最终需要人工介入处理

3. 不需要处理：已知异常并且系统会自动恢复，不需要人工接入。如机器虽然出现异常，但运维底座会再一段时间内自动处理，不需要人工介入

对于一个异常，首先需要判断是否需要立即处理，区分进行优化。

对于不需要处理的异常，则完全没有必要进行告警。如果需要感知事件，可以通过邮件方式进行时候定时通知，无需通过告警渠道打断工作。

对于不紧急的告警，如果工具支持的话，应该以工单的形式定时推送，统一处理，没必要进行实时告警，减少对正常工作的打断。在工具不支持的场景，可以适当调整告警间隔时间，以及重复告警的收敛策略。如单机异常可以整点告警，避免重复打断工作，当然，如果同时超过一定百分比的机器异常，这便转换为紧急告警了，需要实时触达。

对于紧急告警，应该尽量提升其实时性和准确性，尽可能去除无效告警。那应该如何进行无效告警的识别和判断呢，接下来可以看一下告警设置的原则。

告警设置原则

每当告警发生时，值班同学需要暂停手头工作，查看告警。这种中断非常影响工作效率，增加研发成本，特别对正在开发调试的同学，影响很严重。所以，每当我们收到告警时，我们希望它能真实的反映出异常，即告警尽可能不误报(对正常状态报警)；每当有异常产生时，报警应该及时发出来，即告警不能漏报(错过报警)。误报和漏报总是一对矛盾的指标。

以下是一些告警设置原则：

1. 告警具备真实性：告警必须反馈某个真实存在的现象，展示你的服务正在出现的问题或即将出现的问题

2. 告警表述详细：从内容上，告警要近可能详细的描述现象，比如服务器在某个时间点具体发生了什么异常

3. 告警具备可操作性：每当收到告警时，一般需要做出某些操作，对于某些无须做出操作的告警，最好取消。当且仅当需要做某种操作时，才需要通知

4. 新告警使用保守阈值：在配置告警之初，应尽可能扩大监控告警覆盖面，选取保守的阈值，尽可能避免漏报。

5. 告警持续优化：后续持续对告警进行统计分析，对误报的告警，通过屏蔽、简化、阈值调整、更精准的体现原因等多种方式减少误报，这是一个相对长期的过程。

再以请求失败举例，如仅当请求的失败量超过某一阈值时告警，可能存在多种原因，如一些恶意构造的请求，也触发失败量告警。这样的告警既不具备真实性，也不具备可操作性，因为确实无需任何处理。对于此类情况，我们应该尽可能通过特性加以识别，从而更加精准的区分原因的告警。

善用工具

另外优化告警的一个必备条件，就是要熟悉所用告警平台使用，如果都不知道告警平台可以做到什么程度，可以设置怎样灵活的条件阈值，是很难对告警做合理优化的。

1. 监控告警平台能做到什么：业务基础指标，系统基础指标，各种维度的统计方式

2. 告警阈值设置：如何电话/短信告警设置

3. 告警统计和趋势：有利于进行数据分析和优化告警

以请求失败举例，告警平台是否可以区分不同原因类型告警，是否可以统计成功率告警，是否可以配置持续多久告警，是否可以配置环比同比条件告警；以及不同类型的阈值区分配置，不同条件下的短信，还是电话告警，短信一段时间未处理是否可以转换为电话通知，是否可以屏蔽重复告警等等。所有的特性都有利于我们设置一个精准的告警条件。

另外平台提供的统计和趋势，有利于我们进行针对性优化，查看每天每周的TopN告警是什么，整体的趋势是什么样的，从而进行针对性优化。

告警处理流程

前面提到了告警的优化是一个持续的过程，不存在一劳永逸的事情。需要每天或者每周安排值班人员负责告警事宜，这点上确实是需要一定的投入。值班同学需要持续关注告警的有效性，对于出现的无效告警，分析清楚原因，持续优化阈值或者告警策略。

合理的告警流转流程：

处理流程中，在告警触发后，通过短信/电话等方式触达，值班处理人接单处理，再接单后处理完成前，重复的问题不再触发告警，以避免大量的重复无效告警。确认原因后结单返回原因。

可能受限于告警工具问题，不能严格的按照流程来推进（比如一次异常事件，由于告警平台不支持，处理过程中可能触发很多重复告警；系统没有反馈原因的流程等），但是值班同学心里需要有这样的流程，确保每条告警都是清清楚楚在哪个阶段，没有含糊其辞之处。

另外值班同学要强调几点注意事项

1. 确保能够收到所有告警：可以通过接收人组解决，确保所有值班同学都在一个接收人组，如果有人员变动也方便修改

2. 上升线路：需要判断问题的严重性，适合时机上升，增加资源快速把问题消灭再萌芽状态

3. 明确根本原因：确保弄清楚问题原因，而不是表面上恢复。比如单台机器CPU跑满告警，可能存在未知的死循环问题，如果仅仅重启进程恢复，很可能掩盖了问题，导致未来出现大面积的死循环引发故障

最后告警的处理，在心态上要做到：凡事最好能在不疑处有疑，不能在有疑处不疑**。**

参考&引用

1. 《SRC：Google运维解密》

2. 《MTTR/MTTF/MTBF图解》：https://blog.csdn.net/starshinning975/article/details/102893787

3. 《一篇文章了解监控告警》：https://zhuanlan.zhihu.com/p/60416209

4. 《准确率、精度和召回率》：https://www.cnblogs.com/xuexuefirst/p/8858274.html

5. 《告警配置的一些原则和经验》http://wsfdl.com/devops/2018/02/07/configure_alarm.html

Ending

Tip：由于文章篇幅有限制，下面还有20个关于MySQL的问题，我都复盘整理成一份pdf文档了，后面的内容我就把剩下的问题的目录展示给大家看一下

如果觉得有帮助不妨【转发+点赞+关注】支持我，后续会为大家带来更多的技术类文章以及学习类文章！（阿里对MySQL底层实现以及索引实现问的很多）

吃透后这份pdf，你同样可以跟面试官侃侃而谈MySQL。其实像阿里p7岗位的需求也没那么难（但也不简单），扎实的Java基础+无短板知识面+对某几个开源技术有深度学习+阅读过源码+算法刷题，这一套下来p7岗差不多没什么问题，还是希望大家都能拿到高薪offer吧。

8712)]

[外链图片转存中…(img-NHTe3A33-1714724848713)]

吃透后这份pdf，你同样可以跟面试官侃侃而谈MySQL。其实像阿里p7岗位的需求也没那么难（但也不简单），扎实的Java基础+无短板知识面+对某几个开源技术有深度学习+阅读过源码+算法刷题，这一套下来p7岗差不多没什么问题，还是希望大家都能拿到高薪offer吧。

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录