YCOS统一运维平台智能故障分析能力实践

线上故障排查的难点，往往不在于单条日志或单张指标图本身，而在于如何把告警、日志、指标、调用链和服务上下游关系串成一条可验证的诊断链。YCOS 统一运维监控平台围绕这一问题，建设了面向值班场景的智能故障分析能力。它不是简单的聊天机器人，而是一个以平台告警为入口、以可观测数据为证据、以标准化调查流程推动根因定位的智能排障能力。 本文记录 YCOS 统一运维监控平台在智能故障分析能力上的设计思路和工程实践，重点分享如何让大模型在生产排障场景中做到“少猜测、多取证、可追溯、可继续演进”。

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

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

这个过程有三个典型痛点。第一，信息关联成本高。第二，诊断链容易断裂。第三，经验难以复用。

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

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

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

第一层是告警入口。平台将告警等级、事件标题、影响对象、合并次数、最近触发时间和持续时间等关键信息统一呈现，并为重点告警提供“一键智能分析”入口。

第二层是智能调查编排。系统会根据告警内容识别影响服务、严重级别、错误信息和时间窗口，再决定优先查询哪些数据源。整个调查过程遵循 SRE 排查路径。

第三层是观测数据接入。平台围绕自身可观测数据封装了受控查询能力，目前已接入告警列表查询、告警详情查询、日志查询、指标查询、调用链查询。

第四层是证据化输出。大模型负责推理和编排，但真实数据访问全部通过受控能力完成。最终报告不只给出结论，还会说明证据来源、已验证事实、未验证假设、建议动作和可信度。

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

该能力支持两种模式：普通对话模式和告警调查模式。后端的调查流程大致分为五步：初始化、告警提取、调查时间窗口解析、深度调查、发布结论。

系统规则明确要求：只要数据能够回答，就不要猜测；如果查询为空或失败，需要如实说明；最终输出必须包含根因、根因分类、证据、已验证结论、未验证假设、修复步骤和可信度评分。

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

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

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

这次实践中，一个重要体会是：在生产排障场景里，大模型的价值不只是“更聪明”，而是“被正确地约束”。首先，能力需要有明确边界。其次，输入需要可验证。再次，输出需要面向后续关联。最后，系统指令需要强调证据纪律。

能力建设和后续演进

后续建设会围绕诊断质量、证据结构和生产治理继续增强。第一，继续完善证据结构化。第二，增强跨源关联能力。第三，补齐生产化治理。

总结

SRE 智能助手的关键，不是让大模型替代人做判断，而是把人的排障方法沉淀成可执行的调查流程。当我们把大模型放进值班现场，它首先要学会的不是“像专家一样回答”，而是“像 SRE 一样取证”。