大模型这两年很热运维团队也很难绕开它。很多企业已经开始尝试用大模型做告警摘要、日志分析、故障复盘、知识库问答甚至让它根据监控数据给排查建议。 开始体验通常不错能把一堆告警整理成几句话能从日志里提取异常关键字也能生成一份看起来完整的故障说明。但用得久了问题也会暴露出来。同样是接口超时有时候模型能给出比较靠谱的判断有时候只会泛泛地说“请检查数据库、网络、服务器资源”。同样是日志分析有时候能抓到关键报错但有时也会把下游异常当成根因。不是“模型不够聪明”。不少现场真正问题是运维数据本身还没准备好。一、AI 运维不是从模型开始的过去运维比较多的是靠人来补上下文。告警来了值班同事会看监控面板、查日志、问研发、翻发布记录再结合经验判断问题出在哪里。人脑会自动把很多分散信息串起来比如“这个服务刚发布过”“这个数据库最近慢查询增多”“这个接口依赖第三方”。大模型不一样。它需要明确的数据输入。如果日志里没有 traceId模型很难知道一条请求经过了哪些服务如果指标只有 CPU、内存、磁盘模型很难判断是业务流量上升还是代码问题如果链路数据没有和变更记录关联模型也很难判断故障是否由发布引起。所以大模型时代的运维数据治理不是把原来的监控数据简单接给 AI而是要重新整理日志、指标、链路、资产、变更之间的关系。二、日志不能只是“能查到”很多系统都有日志但故障时真正能用的不多。常见情况是日志量很大但关键字段缺失错误信息很多但没有业务含义不同服务日志格式不一致同一个异常在不同模块里写法不同。人还能靠经验慢慢翻模型面对这些混乱文本容易抓错重点。比如一次支付失败日志里只写了“调用失败返回异常。”这类日志对 AI 几乎没有帮助。更有价值的日志应该包含服务名、接口名、请求 ID、错误码、耗时、下游系统、关键业务状态等字段。不是所有字段都要写得很复杂但至少要能回答几个问题谁在什么时候调用了谁失败发生在哪一步失败前后状态有没有变化这是单个请求失败还是一批请求都失败日志治理的重点是让日志更稳定、更结构化、更容易被关联。三、指标不能只盯机器资源不少企业的监控指标还停留在主机层。这些当然重要但已经不够用了。在微服务、容器、云数据库、消息队列普遍使用的环境里业务故障不一定先表现为机器资源异常。一个接口变慢可能是数据库连接池耗尽、线程池排队、缓存命中率下降也可能是下游接口响应变慢。如果只有服务器资源指标AI 能看到的只是“系统压力变大”很难进一步定位。更合理的指标体系至少要覆盖几类数据业务指标、应用指标、中间件指标、数据库指标、基础资源指标。业务指标看订单量、支付成功率、登录成功率应用指标看接口耗时、错误率、吞吐量中间件看队列堆积、消费延迟、缓存命中率数据库看连接数、慢查询、锁等待基础资源看 CPU、内存、磁盘和网络。这些指标不一定一开始就全部做满但核心系统必须先补齐。否则模型只能基于不完整的视角给建议。四、链路数据决定 AI 能不能看懂传播路径故障排查最难的地方是报错服务不一定是根因服务。用户看到下单失败可能订单服务报错但根因可能在库存、支付、优惠券、消息队列或者数据库。没有链路追踪时多个服务同时告警谁先谁后很难说清。链路数据的价值是把一次请求从入口到出口串起来。每个服务处理了多久调用了哪个下游错误在哪一段出现异常是否沿链路传播都可以被记录下来。对大模型来说链路数据比单点日志更重要。因为它提供了上下文也提供了因果判断的线索。不过链路数据也需要治理。服务名要规范接口命名要稳定traceId 要能贯穿请求全程采样策略要能覆盖关键场景。否则链路看似接入了关键故障发生时还是断的。五、变更记录必须成为运维数据的一部分很多线上故障最后都和变更有关。代码发布、配置修改、数据库脚本、网络策略、安全加固、定时任务调整都可能引发异常。但在很多团队里变更记录和监控系统是分开的故障发生后还要在群里问“刚才谁动过”大模型做故障分析时如果看不到变更记录就会少掉一条重要线索。更好的做法是把变更时间、变更对象、影响范围、操作人、回滚方式沉淀下来并和告警、日志、链路建立关联。当异常发生在某次变更之后系统至少能提示排查人员优先核查相关服务和配置。这往往是排查时最该优先确认的信息。六、数据治理要从高频故障场景入手运维数据治理听起来很大但落地时不建议一上来做全量改造。更实际的方式是从高频故障和核心业务链路开始。比如先选登录、下单、支付、查询这类关键链路梳理它们依赖哪些服务、数据库、中间件和外部系统。再看每个节点的日志是否可关联指标是否能反映真实状态链路是否完整变更是否可追踪。这样做的好处是目标清楚也更容易看到效果。一次治理完成后后续告警摘要、故障定位、复盘生成、知识库问答都会更有依据。AI 运维往往是放大基础工作的价值。底层数据越规范上层智能分析越可靠。七、最需要补的是体系能力我接触到的一些企业系统规模不算小工具也买了不少但故障处理仍然依赖个人经验。原因通常不是缺一个单点工具而是日志、指标、链路、资产、变更、值班流程没有形成体系。江苏立维运维服务在做企业运维保障时比较强调先把基础盘理清楚包括核心系统清单、监控指标分层、日志规范、数据库巡检、告警响应、变更记录和应急预案。尤其是 7×24 运维、数据库运维、云运维这类场景平时的数据治理和流程梳理往往决定了故障发生时能不能快速判断方向。如果准备引入大模型做运维分析可以先做一次现状评估哪些系统没有完整监控哪些日志无法关联哪些链路经常断点哪些变更没有记录。这个阶段引入有经验的运维服务团队参与不是为了替代内部 IT而是帮助把分散经验整理成可执行、可复用的机制。写在最后大模型让运维有了新的工具但它不能凭空理解一个混乱的系统。日志、指标、链路数据如果长期缺少治理AI 只能做表层总结只有数据结构清楚、关系完整、上下文充分模型才可能给出接近现场的判断。大模型时代运维数据确实要重新治理一遍。不是为了赶热点而是因为系统越来越复杂单靠人肉排查已经越来越吃力。先把数据打好再谈智能分析才是更稳的路径。