想让AI排障变得更靠谱先把运维数据理清楚

大模型近年热度持续攀升，运维团队也难以避开这一趋势。

许多企业已着手尝试利用大模型进行告警摘要、日志分析、故障复盘、知识库问答，甚至根据监控数据生成排查建议。初体验往往令人满意：能够将大量告警归纳为简明要点，从日志中提取异常关键词，并生成看似完整的故障说明。然而，随着使用深入，问题逐渐显现。

面对同样的接口超时异常，模型有时能给出较为准确的判断，有时却只会泛泛建议“请检查数据库、网络、服务器资源”。日志分析方面，有时能精准捕捉关键报错，但偶尔也会将下游异常误判为根因。这并非模型不够聪明——在许多实际场景中，真实症结在于运维数据自身尚未就绪。

一、AI 运维并非始于模型

以往运维较多依赖人工补充上下文。当告警触发，值班人员会查看监控面板、查阅日志、咨询研发、翻阅发布记录，再凭借经验判断问题所在。人脑能自动将分散信息串联起来，例如“该服务刚刚发布过”、“该数据库近期慢查询增多”、“该接口依赖第三方”。大模型则截然不同——它需要明确的数据输入。

若日志缺少 traceId，模型难以知晓请求流经了哪些服务；若指标仅包含 CPU、内存、磁盘，模型无法判断是业务流量上升还是代码缺陷；若链路数据未与变更记录关联，模型也无法判定故障是否源于发布。因此，大模型时代的运维数据治理，并非简单将原有监控数据对接给 AI，而是要重新梳理日志、指标、链路、资产、变更之间的关联关系。

二、日志不应仅停留于“可查询”

许多系统虽已记录日志，但故障时真正可用的寥寥无几。典型状况：日志量庞大但关键字段缺失；错误信息繁多却无业务含义；不同服务日志格式不统一；同一异常在不同模块中表述各异。人工尚可凭借经验逐步翻阅，但模型面对混乱文本容易抓错重点。例如一次支付失败，日志仅记录：“调用失败，返回异常。”此类日志对 AI 几乎毫无价值。更有实用性的日志应包含服务名称、接口名称、请求 ID、错误码、耗时、下游系统、关键业务状态等字段。

并非所有字段都需复杂设计，但至少应能回答几个核心问题：谁在什么时间调用了谁？失败发生在哪一步？失败前后状态是否有变化？这是单个请求失败还是一批请求均失败？日志治理的关键在于提升其稳定性、结构化程度以及可关联性。

三、指标不能仅关注机器资源

不少企业的监控指标仍停留在主机层面。这些指标固然重要，但已不足以应对当前需求。在微服务、容器、云数据库、消息队列广泛采用的环境中，业务故障未必首先表现为机器资源异常。某个接口变慢，可能是数据库连接池耗尽、线程池排队、缓存命中率下降，或下游接口响应迟缓。若仅有服务器资源指标，AI 只能看到“系统压力增大”，难以进一步定位。更合理的指标体系至少应覆盖以下类别：业务指标、应用指标、中间件指标、数据库指标、基础资源指标。

业务指标关注订单量、支付成功率、登录成功率；应用指标关注接口耗时、错误率、吞吐量；中间件关注队列堆积、消费延迟、缓存命中率；数据库关注连接数、慢查询、锁等待；基础资源关注 CPU、内存、磁盘及网络。这些指标无需一开始全部完善，但核心系统必须先行补齐，否则模型只能基于片面视角给出建议。

四、链路数据决定 AI 能否理解传播路径

故障排查中最棘手之处在于，报错服务未必是根因服务。用户看到下单失败，可能订单服务报错，但根因可能位于库存、支付、优惠券、消息队列或数据库。缺乏链路追踪时，多个服务同时告警，难以判断先后顺序。链路数据的价值在于将一次请求从入口到出口串联起来：每个服务处理时长、调用的下游、错误出现的位置、异常是否沿链路传播，均可被记录。对大模型而言，链路数据比单点日志更为重要，因为它提供了上下文和因果判断的线索。不过，链路数据同样需要治理：服务名需规范，接口命名需稳定，traceId 需贯穿请求全程，采样策略需覆盖关键场景，否则链路看似接入，关键故障发生时仍会断裂。

五、变更记录必须纳入运维数据体系

许多线上故障最终都与变更相关：代码发布、配置修改、数据库脚本、网络策略、安全加固、定时任务调整均可能引发异常。然而在多数团队中，变更记录与监控系统相互分离，故障发生后还需在群内询问“刚才谁动过”。大模型进行故障分析时，若缺失变更记录，便会失去一条重要线索。更优的做法是将变更时间、变更对象、影响范围、操作人、回滚方式沉淀下来，并与告警、日志、链路建立关联。当异常发生在某次变更之后，系统至少能提示排查人员优先核查相关服务和配置。这往往是排查时最需要优先确认的信息。

六、数据治理应从高频故障场景切入

运维数据治理听起来宏大，但落地时不建议一开始就进行全量改造。更实际的方式是从高频故障和核心业务链路起步。例如先选择登录、下单、支付、查询等关键链路，梳理其依赖的服务、数据库、中间件和外部系统，再审视各节点的日志是否可关联、指标能否反映真实状态、链路是否完整、变更是否可追踪。这样做的优势在于目标明确，易于见到成效。一次治理完成后，后续的告警摘要、故障定位、复盘生成、知识库问答都将更有依据。AI 运维往往是放大基础工作价值的过程——底层数据越规范，上层智能分析越可靠。

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

部分企业系统规模不小，工具也采购了不少，但故障处理仍依赖个人经验。原因通常并非缺少某个单点工具，而是日志、指标、链路、资产、变更、值班流程未能形成体系。企业在开展运维保障时，强调先夯实基础盘：包括核心系统清单、监控指标分层、日志规范、数据库巡检、告警响应、变更记录和应急预案。尤其是 7×24 运维、数据库运维、云运维等场景，日常的数据治理与流程梳理往往决定了故障发生时能否快速判断方向。若准备引入大模型进行运维分析，可先进行一次现状评估：哪些系统缺少完整监控，哪些日志无法关联，哪些链路经常断点，哪些变更没有记录。在此阶段引入有经验的运维服务团队参与，不是为了替代内部 IT，而是帮助将分散经验整理为可执行、可复用的机制。

写在最后
大模型为运维带来了新工具，但它无法凭空理解一个混乱的系统。日志、指标、链路数据若长期缺乏治理，AI 只能进行表层总结；只有数据结构清晰、关系完整、上下文充分，模型才可能给出接近现场的判断。大模型时代，运维数据确实需要重新治理一遍——这不是为了追赶热点，而是因为系统日趋复杂，单靠人工排查已越来越吃力。先把数据打好，再谈智能分析，才是更稳妥的路径。