线上故障排查的难点，往往不在于单条日志或单张指标图本身，而在于如何把告警、日志、指标、调用链和服务上下游关系串成一条可验证的诊断链。ACOS 统一运维监控平台围绕这一问题，建设了面向值班场景的智能故障分析能力。它不是简单的聊天机器人，而是一个以平台告警为入口、以可观测数据为证据、以标准化调查流程推动根因定位的智能排障能力。

本文记录 ACOS 统一运维监控平台在智能故障分析能力上的设计思路和工程实践，重点分享如何让大模型在生产排障场景中做到“少猜测、多取证、可追溯、可继续演进”。

一、为什么要做 SRE 智能故障分析助手

在一次真实的线上告警到来后，值班同学通常要完成一连串动作：确认告警对象，判断影响范围，切到日志平台搜索错误，查看 JVM、CPU、内存、GC、线程等指标，再根据日志里的 traceId 下钻调用链，最后把这些现象整理成根因判断和处置建议。

这个过程有三个典型痛点。

第一，信息关联成本高。ACOS 统一运维监控平台已经承载了告警、日志、指标和调用链数据，但这些数据仍分布在不同分析视角中，字段命名、时间范围和查询方式各有差异。排查者需要在同一平台内不断对齐上下文，才能把分散线索串成完整证据链。

第二，诊断链容易断裂。一个错误日志只能说明“某处发生过异常”，一个指标峰值只能说明“某个资源发生波动”。真正有用的是从“告警症状”到“影响服务”再到“日志、指标、调用链证据”的连续推理。

第三，经验难以复用。资深 SRE 会自然地遵循某种排查路径，例如先确定时间窗口，再用日志寻找 traceId，再用指标验证资源异常。但这些经验如果只停留在个人习惯里，就很难沉淀为团队能力。

因此，这项能力的目标不是让大模型“替人拍脑袋给结论”，而是让它成为一个遵守 SRE 排查方法的协作者：能主动查询数据，能说明证据来源，能区分已验证事实和未验证假设，并最终给出根因、置信度和下一步动作。

二、整体架构：以告警为入口的证据化调查链路

ACOS 统一运维监控平台的智能故障分析能力，围绕“告警进入、智能调查、证据汇聚、结论输出”四个环节展开。

第一层是告警入口。平台将告警等级、事件标题、影响对象、合并次数、最近触发时间和持续时间等关键信息统一呈现，并为重点告警提供“一键智能分析”入口。用户也可以在分析过程中继续追问，让调查从一次自动分析延伸为连续对话。

第二层是智能调查编排。系统会根据告警内容识别影响服务、严重级别、错误信息和时间窗口，再决定优先查询哪些数据源。整个调查过程遵循 SRE 排查路径：先确认告警对象和时间范围，再通过日志寻找异常线索，通过指标验证资源与性能波动，通过调用链定位上下游影响。

第三层是观测数据接入。平台围绕自身可观测数据封装了受控查询能力，目前已接入：

• 告警列表查询，用于展示当前生产环境中的重点告警事件。
• 告警详情查询，用告警唯一标识拉取最新事件详情，并归一化为智能分析输入。
• 日志查询，用关键词和应用名检索应用日志，并抽取 error、exception、timeout、OOM 等高价值错误日志。
• 指标查询，限制在明确的 JVM 和主机指标白名单内，避免模型编造不存在的指标名。
• 调用链查询，按 traceId 返回标准化调用链片段，保留服务名、操作名、上下游关系、耗时、状态和异常等字段。

第四层是证据化输出。大模型负责推理和编排，但真实数据访问全部通过受控能力完成。每次查询都返回结构化结果，并保留 timestamp、traceId、spanId、host、ip、service、appname 等可追溯标识。最终报告不只给出结论，还会说明证据来源、已验证事实、未验证假设、建议动作和可信度。

三、核心流程：让一次告警变成一次调查

该能力支持两种模式：普通对话模式和告警调查模式。

普通对话模式用于用户主动提问，例如“帮我查一下某个应用最近是否有异常日志”。在没有结构化告警载荷时，系统会进入自由问答路径，智能体可以使用同一组观测数据查询能力辅助回答。

告警调查模式则围绕一键分析展开。用户在告警列表点击“智能分析”后，前端先查询告警详情，并把告警标准化为包含告警名称、影响对象、严重级别、告警来源、触发时间、告警消息、标签和摘要等字段的调查载荷。随后前端进入分析页，自动把这条告警交给智能体执行根因调查。

后端的调查流程大致分为五步。

第一步是初始化，规范化输入并判断运行模式。系统会检查最新用户消息或当前上下文中是否存在告警载荷，从而决定进入自由问答还是告警调查。

第二步是告警提取。系统会从原始告警中提取告警名称、影响服务、严重级别、命名空间、错误信息、日志查询线索、实例名和部署对象等字段。如果智能抽取失败，则从告警标签、摘要和标准字段中兜底提取，保证流程不会因为单次解析失败而中断。

第三步是调查时间窗口解析。系统会从告警触发时间生成统一调查窗口。这个设计很关键，因为历史告警不能简单查询“最近 60 分钟”，否则很容易查不到真正的故障现场。

第四步是深度调查。智能体会根据告警上下文优先查询日志、指标和调用链，从多个数据源中收集证据。系统规则明确要求：只要数据能够回答，就不要猜测；如果查询为空或失败，需要如实说明；最终输出必须包含根因、根因分类、证据、已验证结论、未验证假设、修复步骤和可信度评分。

第五步是发布结论。该能力已经能把最终报告稳定返回给前端。后续会进一步把自然语言报告转成结构化结果，沉淀为证据条目、已验证结论、未验证假设、处置步骤和置信度等字段，便于前端展示、检索和审计。

四、前端体验：把工具调用变成可读证据

在 SRE 场景里，AI 输出是否可信，很大程度上取决于用户能否看到它到底查了什么。因此前端没有把数据查询过程隐藏在黑盒里，而是用卡片展示查询名称、执行状态、参数摘要、数据数量、数据来源和可展开详情。

例如日志查询返回时，卡片会显示返回了多少条日志、数据来源是否可用，以及错误日志摘要。指标查询返回时，卡片会显示是否成功、返回了多少数据点。调用链查询返回时，卡片可以进一步展示关键服务、关键 span、耗时和异常信息。

分析页也围绕告警上下文设计。页面顶部固定展示告警标题、等级、告警对象、首次触发、最近触发和合并次数。这样用户在与智能体继续对话时，不需要反复回忆当前分析的是哪条事件。

五、工程经验：约束大模型比增强大模型更重要

这次实践中，一个重要体会是：在生产排障场景里，大模型的价值不只是“更聪明”，而是“被正确地约束”。

首先，能力需要有明确边界。日志、指标、调用链都是只读查询能力，默认不提供重启、回滚、扩容等生产变更动作。这样可以让智能体在没有审批机制时始终停留在分析和建议层面。

其次，输入需要可验证。指标查询没有让模型自由填写任意指标，而是要求它从白名单里选择合法指标。告警查询也会校验唯一标识格式，降低错误查询和注入风险。

再次，输出需要面向后续关联。日志结果不仅返回消息正文，也保留时间戳、主机、IP 和标签。调用链结果不仅返回一段文本摘要，也保留 spanId、父子关系和耗时。只有这些 ID 被保留下来，后续才能从“看到一个错误”推进到“定位一个依赖路径”。

最后，系统指令需要强调证据纪律。当前规则明确要求“禁止伪造日志行或指标数据”“如果证据不足要说明缺口”“把已验证结论和未验证假设分开”。这类约束比单纯要求模型“回答准确”更有操作性。

六、能力建设和后续演进

作为 ACOS 统一运维监控平台面向智能运维的重要能力，智能故障分析已经覆盖从告警发现到根因报告的核心链路：平台可以展示告警事件，支持自由问答与告警调查两类场景，能够联动日志、指标和调用链数据，并输出面向 SRE 的根因报告。

后续建设会围绕诊断质量、证据结构和生产治理继续增强。

第一，继续完善证据结构化。最终报告不应只停留在自然语言文本里，而应解析为统一的诊断结果，包括根因、根因分类、证据条目、已验证结论、未验证假设、处置步骤和可信度。

第二，增强跨源关联能力。后续可以基于调用链片段、服务名、主机、IP、实例名和命名空间做关联分析，进一步推断影响范围、上下游依赖和故障半径。

第三，补齐生产化治理。包括鉴权、审计、会话持久化、查询预算、超时、重试、熔断，以及未来如果支持修复动作时必须具备的审批、预执行和回滚机制。

七、总结

SRE 智能助手的关键，不是让大模型替代人做判断，而是把人的排障方法沉淀成可执行的调查流程。告警是入口，日志、指标和调用链是证据，智能体是编排者，界面承载的是让证据被看见和继续追问的过程。

这项能力建设给我的最大启发是：AI 工程落地不能只围绕模型能力设计，也要围绕数据契约、能力边界、流程状态和用户信任设计。对于生产故障分析而言，一个好的智能助手应该少一些笼统总结，多一些可验证证据；少一些凭空推断，多一些明确的不确定性；少一些炫技式对话，多一些能帮助值班同学缩短排查路径的具体动作。

当我们把大模型放进值班现场，它首先要学会的不是“像专家一样回答”，而是“像 SRE 一样取证”。