从规则到智能：我把运维告警处理做成了AI智能体

做运维最痛苦的事情之一：告警处理。我们集群半夜平均每小时弹出20-30条告警，其中七成是"同一个问题重复报警"或者"误报"，但值班工程师必须一条条看、一条条确认，熬通宵是常态。今年我花了一个月时间，把告警处理从"规则引擎"升级成了"AI智能体"，值班电话响铃次数直接降了70%。这篇完整记录从设计到落地的过程。

一、为什么规则引擎不够用

我们原本有一套告警规则：阈值触发（CPU>90%就报警）、关键字匹配（日志出现"OOM"就报警）、静默规则（凌晨2-5点不报警）。它的问题很典型：

1. 不会看上下文：某个服务连续10分钟CPU高，但当时正在做压测，规则引擎照样报警，值班人被"狼来了"折磨；
2. 不会关联分析：数据库连接数飙高+慢查询增多+接口延迟上升，这是同一个根因（慢SQL），规则引擎发出三条独立告警，看不出关联；
3. 不会处置：规则引擎只能"报警"，不能"处理"——重启一个挂掉的服务、扩容一个满的队列，都得人工来做。

二、AI智能体的设计思路

我把"值班工程师的处理套路"拆成了四步，让AI智能体复刻这套流程：

告警事件
  → 第一步 关联分析：把相关告警归并成"一次事件"（找根因）
  → 第二步 场景判断：判断是"已知问题"还是"新问题"
  → 第三步 自动处置：已知问题按预案自动处理（调API执行）
  → 第四步 人工上报：未知问题/高风险问题，附分析结论上报值班人

关键点1：告警归并，用AI做"根因关联"

这是整个系统最核心的能力。以前规则引擎的归并靠"告警源相同"，AI版本是让模型理解告警之间的业务关联。我把5分钟窗口内的所有告警+当前集群状态（CPU、内存、连接数、QPS）打包成上下文，让模型判断"这些告警是否同源、根因是什么"。

实测效果：告警条数从日均500+条归并成60+个事件，归并准确率约88%。值班人终于不用面对几百条告警瀑布了。

关键点2：自动处置，用"预案库"约束行动

自动处置最大的风险是"AI乱动"。我的设计是预案库+白名单：

• 预案库：把过去一年人工处理过的告警处置步骤，沉淀成50多个标准预案（如"MySQL主从延迟告警→查看延迟秒数→确认无DDL→降级只读流量"）；
• 智能体从预案库里检索匹配预案，只有命中预案的动作才允许自动执行（重启、扩容、切流都走审批API）；
• 预案未命中时，智能体只做分析、不做动作，把结论交给人工。

这样既保留了AI的"理解能力"，又用预案库守住了"动作边界"。上线以来自动处置了300多次，没有一次越权动作。

关键点3：值班交接，让AI当"白班夜班交接员"

凌晨处置完的事，早班同事完全不知道发生了什么。现在AI会自动生成"值班交接报告"：昨晚发生了哪些事件、哪些自动处理了、哪些遗留待跟进、建议优先级。早班同事打开报告5分钟就能接手，交接时间从半小时压缩到5分钟。

三、技术实现要点

• 模型：Qwen2.5-14B 本地部署（告警数据敏感，不能出内网）；
• 框架：LangGraph编排（归并→判断→处置→上报的状态机）；
• 数据：告警源是Prometheus + Alertmanager，通过Webhook接入智能体；
• 动作执行：预案动作走内部运维平台的API，全部有审计日志。

四、上线效果与数据

最直观的感受：以前夜班是"告警刷屏+神经紧绷"，现在夜班是"手机安静+偶尔看一眼交接报告"。值班同事的幸福感提升是实打实的。

五、踩坑与反思

1. 归并别"贪多"：早期想让模型把所有告警都归成一个根因，结果把无关告警也归并了，反而掩盖问题。后来加上"归并置信度"，低置信度的保持独立告警；
2. 预案库要持续喂养：每次人工处理了新类型的告警，都要沉淀成新预案，否则智能体永远只会在旧预案里打转。预案库是这套系统的"经验积累"，是最需要投入维护的部分；
3. 监控AI本身：智能体也要有"告警"——如果它连续3次判断失败，或长时间无响应，要有降级机制（直接转人工并通知管理员）。

六、总结

从规则引擎到AI智能体，本质是把"告警"从"需要人看的信息"变成"系统自己能处理的信号"。AI不是替代了值班工程师，而是替代了"被重复告警消耗的精力"，让人把注意力集中在真正需要判断力的事情上。

如果你的团队也在被告警淹没，我的建议是：先别急着上AI，先把"预案库"建起来——把你过去处理告警的套路写成文档，这是AI智能体能否靠谱的根基。地基打好了，AI才能在上面盖起楼来。