AIOps别急着上AI，先搞定警报收敛
大家好，我是运维老李，在系统监控领域摸爬滚打十多年了。最近AIOps炒得很热，根因分析、异常检测、预测性警报听起来很炫酷。但说实话，很多团队连基础警报都没理顺，就急着上AI，结果呢？警报更多了，噪音更大了，半夜被吵醒的次数反而增加了。
警报疲劳：被忽视的运维杀手
想象一下：你刚躺下，手机响了，数据库CPU高。你爬起来处理，刚解决，又来一条，应用响应慢。结果发现，这些都是同一个底层问题引发的连锁反应。这就是典型的警报不收敛——同一个根因，触发了多个警报，浪费了团队大量时间。
根据我的经验，一个典型的微服务架构，一个故障可能产生几十条警报。如果每条都单独处理，MTTR（平均修复时间）会飙升。而如果先收敛，可能一条警报就覆盖了。
为什么收敛去重是AIOps的第一步？
AIOps被寄予厚望，但它的核心价值应该是辅助决策，而不是制造新问题。当前阶段，首要任务不是生成更多新警报，而是让现有警报更“干净”。
信噪比优先：在引入任何智能算法前，必须确保基础警报的信噪比足够高。如果信号里全是噪音，AI模型学到的也是噪音。就像教孩子认字，先得保证课本没有错别字。
简单规则更可靠：对于警报收敛，基于时间窗口、标签匹配的简单规则往往比复杂模型更有效。例如，将5分钟内同一服务的类似警报合并。AI模型需要训练数据，而警报数据往往稀疏且不平衡，初期效果可能不如规则。
减少误报成本：每条误报都有成本——人力、时间、甚至业务影响。收敛去重直接降低这些成本。而AI如果误报率高，反而增加负担。
如何实践警报收敛？
- 聚合策略：按服务、环境、严重性分组。例如，所有生产环境数据库警报合并为一个组。
- 时间窗口：设置合理的时间窗口（如2分钟），避免短时间内重复触发。
- 依赖关系：利用拓扑信息，如果服务A依赖服务B，B的警报可能影响A，可以关联显示。
- 定期审查：每月回顾警报，删除无效的，调整阈值。
工具方面，Prometheus的Alertmanager、Datadog等都有收敛功能。关键是配置好规则，而不是依赖默认设置。
先净化信号，再谈智能分析
AIOps的终极目标是智能，但路径要踏实。先做好基础收敛，让警报列表从“杂乱清单”变成“关键清单”，这时再引入AI进行根因分析，效果会倍增。
否则，只会得到“智能噪音”——模型复杂了，但问题更模糊了。记住：在警报管理中，少即是多。
总结：别被AIOps的 hype 带偏。从收敛去重开始，提升信噪比，这是最务实、最有效的第一步。你的团队还在被警报淹没吗？先从整理警报清单做起吧！