AIOps 大模型：从告警洪水到根因对话

传统 AIOps 擅长三件事：检测异常、收敛告警、关联指标。但它常常停在最后一步——根因是什么？为什么偏偏是现在？该先查哪里？这些问题仍然要靠人。大模型带来的变化，不是让运维多一个聊天窗口，而是让系统终于能“解释自己”。

一、AIOps 缺的不是检测，是解释

告警本身没有价值，上下文才有。一个 CPU 飙升的告警，如果同时出现一次发布、一条数据库慢查询、一个上游超时，它的含义完全不同。大模型擅长把分散的信号拼成叙事：指标、日志、Trace、变更记录、拓扑关系、历史工单，都可以成为它的输入。

所以，AIOps 大模型的第一定位不是“自动修复”，而是“根因参谋”。

二、一个最小实战：让模型读上下文

真正落地时，代码可以很少。核心不是训练模型，而是把上下文喂对，把输出约束好：

def aiops_ask(alert, metrics, logs, changes):
    prompt = f"""
    告警：{alert}
    指标：{metrics}
    日志：{logs}
    变更：{changes}
    请输出 JSON：根因假设、证据、置信度、下一步排查命令、是否建议回滚。
    """
    return llm(prompt)  # 只生成建议，不直接执行

这段代码很短，却包含三个关键原则：输入要有上下文，输出要结构化，执行要留给人或审批流。大模型可以给出“可能是发布引入的连接池泄漏”，但要不要回滚，必须由规则、权限和人来决定。

三、大模型不是执行者，是参谋

把大模型直接接到生产执行链路上，是危险的。它可能幻觉，可能误判，也可能被日志里的恶意内容诱导。更稳妥的路径是：

1. 只读接入：先让它读监控、日志、变更和工单。
2. 建议输出：生成根因假设、排查命令和影响评估。
3. 人工确认：由工程师判断，或进入审批流。
4. 逐步自动化：只对低风险、可回滚的操作开放自动执行。

AIOps 大模型的价值，不是替代 SRE，而是把 SRE 从“翻十块屏幕找线索”变成“验证几个高质量假设”。

四、评估比生成更重要

没有评估的 AIOps 大模型，只是一个会说话的告警面板。要关注四个指标：根因准确率、误报率、MTTR 变化、人工采纳率。尤其要看“它说对了没有”和“人愿不愿意信”。如果建议总是模糊、冗长、无法验证，再强的模型也没有意义。

五、结语

AIOps 大模型不是让运维消失，而是让运维换一种工作方式：从救火转向提问，从盯屏转向验证，从写脚本转向建上下文。

少写代码，多建反馈；少做自动执行，多做可信建议。当系统能解释自己，运维才真正开始变得从容。