21｜事件管理（上）：事件降噪的几个典型手段

1.课后题：推送的报警信息可以带链接，链接跳转的页面添加人工介入的按钮，人工介入后对应报警就只记录不推送了，人工处理完之后把对应事件置为已处理，然后接着走监控告警规则，建议在加一个最大的单次人工介入处理时间，防止人工处理完忘记点已处理导致后续监控不推送问题。 延伸：问题解决后可以复盘问题反复出现的原因，然后对恢复脚本或是告警规则做改进。 2.想请问一下老师水平触发（Level Triggered）工作模式和边缘触发（Edge Triggered）工作模式的适用场景有哪些

老师课程里面好像没有介绍：告警触发引擎的设计逻辑吧？还是我没看见，最近公司在做监控告警平台，不知道告警触发引擎怎么设计实现

请教老师几个问题： Q1：告警处理这一块目前是否引入了AI和大数据？ 告警事件需要几个月的保存，通常会积累大量的数据。请问，针对这些历史数据，公司是否会引入大数据和AI进行处理？或者目前是否有一些比较先进的公司采用了这些手段？比如阿里、京东等。 Q2：需要配置多少运维人员？ 公司一般需要配置多少运维人员？可以结合具体的例子。比如极客这种规模需要多少？如果不了解极客的情况，不好回答，这时候可以根据作者自己公司的规模回答。 Q3：能否以作者自己公司作为例子讲解？即作者自己公司是怎么做监控的，比如，公司大致有什么业务，流量多大，用户量多大，机器数量等，基于这些信息，采用了什么框架进行监控、运维。老师可以以自己目前所在的公司为例子进行讲解，也可以以以前的单位为例子。如果方便的话，建议以加餐形式用一节课来讲；如果不方便，就在留言中回复即可。

思考题：如何处理报警重复的问题，我觉得可以通过滑动平均值的方式来聚合报警，比如，报警第一次触发的时候发出报警，然后在一定的时间之内如果有相同的报警发出/解除，进行滑动平均计算，如果达到再次报警或者是报警升级的阈值，再次报警；如果达到解除报警的阈值，则解除报警。以此来减少重复报警的次数

课后题：配置或增大告警规则的留观时长，观察一段时间后再恢复。

之前我也一直在尝试引入AI来做告警收敛，效果不明显；最后还是通过时间线+告警层级两个维度来做收敛，效果更好些。不过大部分收敛规则是要运维同学花时间去配置的，他们也提出能否减少配置的功能，自动去聚合，老师提到的从告警接收人+告警时间维度来聚合，确实是个不错的解决方案，可以减少运维同学的配置工作。