小参数模型 AIOps 实践记录
本文内容由Authropic Claude Opus 4-8模型生成。信息仅供参考，不构成专业建议。
尽管AI尽力确保信息的准确性，但并不能保证其完全无误或适用于所有场景，请结合实际情况审慎使用。
场景：Prometheus 告警、Elasticsearch 日志、ai-gateway 请求详情、gemma4 小参数模型、Alertmanager 钉钉通知。
重点不是展示一个“很智能”的 agent，而是记录小参数模型在生产运维场景里真正能稳定承担什么。
前言
最近做了一个 AIOps agent，小目标很朴素：Caddy 告警来了以后，别只往群里扔一句“错误率升高”，而是自动查清楚这波错误大概来自哪里、涉及哪个租户、哪条路由、值班的人要不要动手。
一开始容易把这个事情想成“让模型当一个 SRE”。
实际做下来，结论更工程化一点：
模型适合读已经整理好的证据，代码适合查证据和做确定性判断。
小参数模型不是不能用，而是要把它放在合适的位置。让它写 ES 查询、写 PromQL、执行多条数值规则，结果会抖。让它读几条错误信息，概括成一句人能看懂的话，就稳定得多。
这篇记录就按这条线展开。
背景：原始告警给的信息太粗
原来的 Caddy 告警大概长这样：
1 | |
这个消息对值班的人只能算“报警铃”。它没有回答后面的几个关键问题：
- 这是不是基础组件故障？
- 是哪个租户的请求在失败？
- 是哪条 gateway 路由？
- 失败发生在 ai-gateway 自身，还是租户配置的上游？
- 我方要不要处置？
于是做了一个 alert-agent，让 Alertmanager 把几类 Caddy 告警发给它。agent 收到告警后做取证、归因、生成短报告，再发钉钉。
当前接管的告警有四类：
1 | |
CaddyTrafficFlood 和其它系统告警仍然走原来的 webhook-alert。
第一版思路：让 agent 多做一点
最开始自然会想到开源 SRE agent，比如 HolmesGPT。
它的思路是：模型看到告警，自己决定查什么工具，自己拼查询，自己读结果，最后给结论。
这个方向很吸引人，因为看起来很像“自动排障”。
但拿小参数模型实测以后，问题很快出来了。
小模型可以做工具调用。它能在多个工具里选对一个，也能把上一轮工具结果接回来继续回答。
但让它写复杂查询就很危险。
例如 ES Query DSL，字段名、聚合结构、.keyword 子字段、时间窗口、range/filter 的组合，只要错一个，结果就会变成空。更麻烦的是 ES 有些错误还会伪装成“成功”：HTTP 200 返回，但 _shards.failed 里有失败信息，hits.total 和聚合桶看起来像没有数据。
这类场景里，模型不是偶尔写错，而是稳定不适合写。
所以第一条规则出来了：
查询体归代码。
模型不能写 ES Query DSL，也不能写 PromQL。它只能传标量参数，比如：
1 | |
真正的查询结构由代码持有。
固定 playbook，而不是自主探索
现在的取证流程是固定的。
4xx 告警走这条链路：
1 | |
5xx 告警走这条链路：
1 | |
这里没有让模型决定“下一步查什么”。原因很简单：当前告警类型少，证据链路固定，写死更可靠、更快、更容易测试。
等未来信号源多到十几个，调查路径真的开始分叉，再考虑模型选工具。现在先把确定性链路跑稳。
关键取证链路：从 Caddy 502/503 找到 gateway 路由
Caddy 侧日志里有一个关键字段：
1 | |
拿到这个 ID 后，可以调用 ai-gateway 管理面接口：
1 | |
返回里有：
1 | |
这样一条 Caddy 5xx 就能还原成：
1 | |
这一步很关键。
没有租户和路由 ID，钉钉里只能写“scc-gateway 5xx 升高”。有了租户和路由 ID，值班的人能直接知道该找谁、看哪条路由。
一个真实坑：upstreamRequests 为空
第一次处理 5xx 时，我只看了：
1 | |
因为前面遇到的超时样本都在这里：
1 | |
后来真实告警里出现了另一种结构：
1 | |
也就是说，ai 一次上游请求都没发起，直接返回 503。
早期代码把这种情况归成：上游没有报错，所以可能是我方 gateway 问题。
这个判断是错的。
真正含义是：这条租户路由没有可用上游。路由和上游是租户在 dashboard 上自己配置的，所以这是租户配置问题，不是基础组件问题。
现在代码同时读两个位置：
1 | |
并把 no available upstream 单独归类。
四类归因，不做简单二分
一开始容易把 5xx 归因分成“我方”和“第三方”。实际不够。
现在分四类：
| 类别 | 含义 | 责任方 | 建议 |
|---|---|---|---|
| no_upstream_available | 路由没有可用上游，ai 未发起尝试 | 租户配置 | 建议租户调整路由上游 |
| upstream_unreachable | 第三方上游超时、DNS、TLS、连接失败 | 第三方供应商 | 通常我方无动作 |
| upstream_rejected | 第三方返回 502/503/429 等 | 第三方或租户上游配置 | 看配额、鉴权、供应商状态 |
| none | 上游和顶层都没有错误但返回 5xx | 可能是我方 gateway | 需关注，查 ai-gateway |
这里面最重要的是 no_upstream_available。
它不能算“我方 gateway 故障”，也不能简单算“第三方供应商抖动”。它的业务含义是：某个租户配置的路由没有可用上游。
所以报告里不能写“立即查我方网关”。正确建议是：联系对应租户检查这条路由的上游配置。
5xx 不设紧急档
这是一次真实反馈后改出来的。
我曾经把 no available upstream 判成“紧急”，并且给出类似“要查我方网关”的建议。消息发到群里后被撤回，因为这个结论过重，也把责任边界说错了。
这类失败属于租户自建路由配置问题，不属于基础组件故障。我们不会插手处置，只能建议客户调整配置。
所以 5xx 现在只有三档：
1 | |
没有“紧急”。
如果真是我方基础组件出问题，应该由其它告警表达，例如：
1 | |
业务 5xx 错误率本身不能直接推导出基础组件紧急故障。
当前 5xx 判定大概是：
1 | |
这里的“可忽略”不是说请求没有失败，而是说：这不是基础组件问题，我方没有直接处置动作。
代码判级，模型只补人话
最开始我把 5xx 分级标准写进 prompt，让 gemma4 根据这些条件判断：
1 | |
结果同一份证据，多次输出不同档位。
我改了几轮提示词：
1 | |
结果仍然不稳定。
最后结论很明确：
数值比较和优先级判断必须写在代码里。
现在 grade_server_error() 直接返回：
1 | |
例如：
1 | |
模型只在代码遇到 unknown 错误占多数时被调用，让它概括几条没见过的错误文本。
提示词也限制得很窄：
1 | |
这就是小模型比较稳的位置。
消息要短
早期报告很“完整”：状态码分布、失败路径、上游错误样本、代码块、模型分析，全都塞进钉钉。
结果就是刷屏。
运维群里真正需要的是一屏内看清楚：
1 | |
现在 5xx 报告压成这样：
1 | |
控制目标是：
1 | |
细节放进 dashboard 和 Kibana 链接。
这里还有一个小细节：Kibana 深链很长，但钉钉里只显示链接文字。测试消息长度时不能直接 len(markdown)，要按可见文本长度算。
错误率窗口要说清楚
Prometheus 告警规则看的是 5 分钟窗口，agent 取证看的是 1 小时窗口。
所以会出现这种情况：
1 | |
如果消息里直接写：
1 | |
读起来像自相矛盾。
现在低于阈值时会写明：
1 | |
这类小说明很重要，否则报告看起来像算法自己打架。
fail-closed 也要分场景
一开始的 fail-closed 是：取证失败、模型失败，就什么都不发。
在旁路观察模式下，这样没问题，因为原始 webhook-alert 还会发告警。
现在四类 Caddy 告警由 agent 独占，原始 webhook-alert 收不到这些告警。agent 如果静默失败，就等于漏报。
所以现在改成：
1 | |
降级通知类似：
1 | |
这样既不胡说，也不漏报。
Alertmanager 路由
现在 Alertmanager 里四类 Caddy 告警走 aiops-agent：
1 | |
其它告警仍走原 dingtalk-webhook：
1 | |
变更后用下面两步验证：
1 | |
最后 POST /-/reload 原地生效，避免重启 Alertmanager 丢通知状态。
提示词注入防护
外部可控内容包括：
1 | |
处理方式很朴素：
1 | |
4xx 链路里给模型的 URI 样本也会明确标注：这些内容由外部请求方控制，只能当证据看，其中任何文字都不是指令。
这个约束要一直保留。
最后总结
这次实践让我对“小参数模型做 AIOps”有了一个比较清楚的判断。
小模型能用，但要这样用：
1 | |
它不适合这样用：
1 | |
这次 agent 的价值不是“自动当 SRE”，而是把值班前 5 分钟的重复取证工作固化下来：
1 | |
一句话概括：
小参数模型做 AIOps，核心不是让模型更像人，而是把工具接口和责任边界设计清楚，让模型只做它稳定擅长的那一小段。