"AI 降噪"听起来很美
打开任何一个 AIOps 产品的官网，你都会看到类似的承诺："AI 驱动的告警降噪，减少 90% 噪音"。这些数字看起来令人激动，但在真实运维环境中，事情远没那么简单。
这篇文章不讲营销话术。我们会分享在 VigilOps 中使用 AI（DeepSeek LLM）做告警降噪的实际做法、遇到的坑，以及什么有效、什么没效。
先搞清楚"噪音"是什么
运维告警中的噪音大致分几类：
重复告警。 同一个问题在一分钟内触发了 10 条告警（比如 10 个 Pod 同时报内存高）。AlertManager 的分组功能可以处理大部分情况，但前提是告警的标签要设计得好。
自恢复告警。 CPU 突然飙到 95%，一分钟后降回正常，触发了告警但恢复得太快来不及处理。这类告警对值班人员来说基本是噪音，但完全屏蔽又怕漏掉持续性问题。
关联告警。 一个上游服务挂了，导致下游 5 个服务同时报错。本质上只有一个根因，但你收到了 6 条告警。
真正的噪音只有一种定义：触发了但不需要任何人做任何事的告警。
传统降噪方法的上限
AlertManager 的分组/抑制、静默、商业工具聚合去重……这些方法的共同上限：它们是基于规则的，无法理解上下文。 一条"CPU 95%"的告警，在日常场景和大促期间意味着完全不同的事情，但规则系统看到的只是一个数字。
AI 降噪在 VigilOps 中怎么工作
我们在 VigilOps 中集成了 DeepSeek LLM 做告警分析，嵌入在告警处理流程中：
告警触发
↓
收集上下文（最近 30 分钟趋势 + 活跃告警 + 日志 + 拓扑）
↓
DeepSeek 分析（根因 + 严重程度 + 建议操作）
↓
匹配 Runbook → 自动修复 / 不匹配 → 附加分析后通知
什么有效
根因关联。 5 个下游服务同时报错时，AI 能结合拓扑判断"这些可能都源自上游服务 X 的故障"。
日志解读。 AI 可以阅读错误日志，解释"这个 OOM Killed 是因为 Java 堆内存配置过小"——相当于一个高级工程师在旁边给解释。
和自动修复联动。 AI 分析根因 → 匹配 Runbook → 自动执行，整个链路连贯。
什么没效（诚实说）
延迟。 DeepSeek API 调用 3-8 秒，加上上下文收集总延迟 5-15 秒。P0 告警我们跳过 AI 直接通知，分析异步补充。
幻觉。 LLM 有时会编造合理但错误的根因。我们的做法：分析结果标记为"参考"，低置信度不触发自动修复。
成本。 单次分析几分钱，告警量大时积少成多。做法：只对非重复、非静默告警触发，分组后只分析一次。
几个实用建议
1. 先清理告警规则。 按 30 天触发次数排序，逐一审视触发最多的 10 条。
2. 分层告警：
- P0：电话/短信叫醒（服务不可用）
- P1：即时通讯通知
- P2/P3：面板展示即可
3. 衡量告警质量：
- 噪音比（触发后未被操作的占比）< 30%
- 漏报率趋近于 0
4. 对 AI 保持合理预期。 把 AI 当经验丰富的同事，而不是魔法按钮。
总结
告警降噪的分层方法：
- 基础层：合理规则 + AlertManager 分组/抑制
- 智能层：AI 上下文分析 + 根因关联（VigilOps 在做的）
- 自动化层：Runbook 自动修复
- 治理层：定期回顾 + 指标驱动优化
我们不会声称"减少 90% 噪音"——这取决于你的具体环境。但方向确定：监控系统应该越来越智能，而不是越来越吵。
在线 Demo（无需安装）： demo.lchuangnet.com/login（demo@… / demo123）
自己部署：
git clone https://github.com/LinChuang2008/vigilops.git
cd vigilops && cp .env.example .env
docker compose up -d
欢迎 GitHub Star 👉 github.com/LinChuang20…
也欢迎评论区分享：你们用过什么方法给告警降噪？效果如何？
VigilOps 是 Apache 2.0 开源项目，完全免费。
