大模型这两年很热，运维团队也很难绕开它。

很多企业已经开始尝试用大模型做告警摘要、日志分析、故障复盘、知识库问答，甚至让它根据监控数据给排查建议。 开始体验通常不错：能把一堆告警整理成几句话，能从日志里提取异常关键字，也能生成一份看起来完整的故障说明。

但用得久了，问题也会暴露出来。

同样是接口超时，有时候模型能给出比较靠谱的判断，有时候只会泛泛地说“请检查数据库、网络、服务器资源”。同样是日志分析，有时候能抓到关键报错，但有时也会把下游异常当成根因。

不是“模型不够聪明”。不少现场，真正问题是：运维数据本身还没准备好。

一、AI 运维不是从模型开始的

过去运维比较多的是靠人来补上下文。

告警来了，值班同事会看监控面板、查日志、问研发、翻发布记录，再结合经验判断问题出在哪里。人脑会自动把很多分散信息串起来，比如“这个服务刚发布过”“这个数据库最近慢查询增多”“这个接口依赖第三方”。

大模型不一样。它需要明确的数据输入。

如果日志里没有 traceId，模型很难知道一条请求经过了哪些服务；如果指标只有 CPU、内存、磁盘，模型很难判断是业务流量上升还是代码问题；如果链路数据没有和变更记录关联，模型也很难判断故障是否由发布引起。

所以，大模型时代的运维数据治理，不是把原来的监控数据简单接给 AI，而是要重新整理日志、指标、链路、资产、变更之间的关系。

二、日志不能只是“能查到”

很多系统都有日志，但故障时真正能用的不多。

常见情况是：日志量很大，但关键字段缺失；错误信息很多，但没有业务含义；不同服务日志格式不一致；同一个异常在不同模块里写法不同。人还能靠经验慢慢翻，模型面对这些混乱文本，容易抓错重点。

比如一次支付失败，日志里只写了：

“调用失败，返回异常。”

这类日志对 AI 几乎没有帮助。更有价值的日志应该包含服务名、接口名、请求 ID、错误码、耗时、下游系统、关键业务状态等字段。

不是所有字段都要写得很复杂，但至少要能回答几个问题：谁在什么时候调用了谁？失败发生在哪一步？失败前后状态有没有变化？这是单个请求失败，还是一批请求都失败？

日志治理的重点是让日志更稳定、更结构化、更容易被关联。

三、指标不能只盯机器资源

不少企业的监控指标还停留在主机层。这些当然重要，但已经不够用了。

在微服务、容器、云数据库、消息队列普遍使用的环境里，业务故障不一定先表现为机器资源异常。

一个接口变慢，可能是数据库连接池耗尽、线程池排队、缓存命中率下降，也可能是下游接口响应变慢。如果只有服务器资源指标，AI 能看到的只是“系统压力变大”，很难进一步定位。

更合理的指标体系，至少要覆盖几类数据：业务指标、应用指标、中间件指标、数据库指标、基础资源指标。

业务指标看订单量、支付成功率、登录成功率；应用指标看接口耗时、错误率、吞吐量；中间件看队列堆积、消费延迟、缓存命中率；数据库看连接数、慢查询、锁等待；基础资源看 CPU、内存、磁盘和网络。

这些指标不一定一开始就全部做满，但核心系统必须先补齐。否则模型只能基于不完整的视角给建议。

四、链路数据决定 AI 能不能看懂传播路径

故障排查最难的地方，是报错服务不一定是根因服务。

用户看到下单失败，可能订单服务报错，但根因可能在库存、支付、优惠券、消息队列或者数据库。没有链路追踪时，多个服务同时告警，谁先谁后很难说清。

链路数据的价值，是把一次请求从入口到出口串起来。每个服务处理了多久，调用了哪个下游，错误在哪一段出现，异常是否沿链路传播，都可以被记录下来。

对大模型来说，链路数据比单点日志更重要。因为它提供了上下文，也提供了因果判断的线索。

不过，链路数据也需要治理。服务名要规范，接口命名要稳定，traceId 要能贯穿请求全程，采样策略要能覆盖关键场景。否则链路看似接入了，关键故障发生时还是断的。

五、变更记录必须成为运维数据的一部分

很多线上故障最后都和变更有关。

代码发布、配置修改、数据库脚本、网络策略、安全加固、定时任务调整，都可能引发异常。但在很多团队里，变更记录和监控系统是分开的，故障发生后还要在群里问：“刚才谁动过？”

大模型做故障分析时，如果看不到变更记录，就会少掉一条重要线索。

更好的做法，是把变更时间、变更对象、影响范围、操作人、回滚方式沉淀下来，并和告警、日志、链路建立关联。当异常发生在某次变更之后，系统至少能提示排查人员优先核查相关服务和配置。

这往往是排查时最该优先确认的信息。

六、数据治理要从高频故障场景入手

运维数据治理听起来很大，但落地时不建议一上来做全量改造。

更实际的方式，是从高频故障和核心业务链路开始。

比如先选登录、下单、支付、查询这类关键链路，梳理它们依赖哪些服务、数据库、中间件和外部系统。再看每个节点的日志是否可关联，指标是否能反映真实状态，链路是否完整，变更是否可追踪。

这样做的好处是目标清楚，也更容易看到效果。一次治理完成后，后续告警摘要、故障定位、复盘生成、知识库问答都会更有依据。

AI 运维往往是放大基础工作的价值。底层数据越规范，上层智能分析越可靠。

七、最需要补的是体系能力

我接触到的一些企业，系统规模不算小，工具也买了不少，但故障处理仍然依赖个人经验。原因通常不是缺一个单点工具，而是日志、指标、链路、资产、变更、值班流程没有形成体系。江苏立维运维服务在做企业运维保障时，比较强调先把基础盘理清楚，包括核心系统清单、监控指标分层、日志规范、数据库巡检、告警响应、变更记录和应急预案。尤其是 7×24 运维、数据库运维、云运维这类场景，平时的数据治理和流程梳理，往往决定了故障发生时能不能快速判断方向。

如果准备引入大模型做运维分析，可以先做一次现状评估：哪些系统没有完整监控，哪些日志无法关联，哪些链路经常断点，哪些变更没有记录。这个阶段引入有经验的运维服务团队参与，不是为了替代内部 IT，而是帮助把分散经验整理成可执行、可复用的机制。

写在最后
大模型让运维有了新的工具，但它不能凭空理解一个混乱的系统。

日志、指标、链路数据如果长期缺少治理，AI 只能做表层总结；只有数据结构清楚、关系完整、上下文充分，模型才可能给出接近现场的判断。

大模型时代，运维数据确实要重新治理一遍。不是为了赶热点，而是因为系统越来越复杂，单靠人肉排查已经越来越吃力。先把数据打好，再谈智能分析，才是更稳的路径。