摘要
- AI OnCall，也可以理解为 AI Autonomous Oncall，是大模型进入可观测性领域后的一个关键方向：让每个工程师拥有自己的智能 Oncall 分身。
- 智能 Oncall 的价值不是替代工程师，而是分担告警处理、问题分析、上下文整理和初步根因判断等繁琐工作，让工程师更快进入决策状态。
- 要让 AI 真正参与 Oncall，需要同时具备足够智能且成本可控的大模型、完备的可观测性数据、统一的数据接口、可靠的上下文预处理和工程师确认后的知识沉淀。
- Flashcat 的实现路径是把 metrics、logs、traces、events、Runbook、仪表盘和环境拓扑等信息统一暴露给 AI agent，并通过多智能体架构分别处理不同分析场景。
- 在现实落地中，知识库不应只依赖企业历史文档和复盘记录，更有效的方式是让 AI 在工程师确认后持续积累高质量分析过程和结论。
从 AIOps 到 AI OnCall：为什么现在可行
AIOps 最早可以追溯到 2011 年 Netflix 的 Chaos Monkey 实践。它开创了故障注入与自动化修复的先河。2016 年，Gartner 首次提出 AIOps 的概念：Algorithmic IT Operations，描绘了算法、机器学习和大数据分析在自动化运维领域的重要性和广阔前景。
随后的十多年里，众多创新企业、互联网巨头和科研机构，都在持续追求智能运维领域的“AGI 时刻”。但过去的典型方案大多局限在某个垂直领域或单一场景，比如事件关联分析、时间序列数据预测、日志聚类分析、特征分析等。这些方案在不同企业、不同场景、不同业务系统之间往往难以有效迁移，也不具备足够强的可复制性。
2022 年进入 ChatGPT 时代后，大模型的智能层次和进化速度刷新了很多人的认知。大模型和智能体正在重塑每个行业。在可观测领域，我们也看到了智能 Oncall（AI Autonomous Oncall）的可行性：每个工程师都可以有一个 AI 分身，帮助自己分担故障处理和问题分析中的繁琐工作，并且做得更快、更好。
智能 Oncall 的核心不是给告警套一层聊天入口，而是让 AI 能读懂可观测性数据、理解系统上下文、参与告警响应、辅助根因分析，并在值班协作中沉淀可复用经验。
AI OnCall 能力与场景总览
| 场景 | 关键输入 | AI agent 的工作 | 对工程师的价值 |
|---|---|---|---|
| 告警响应 | 告警事件、metrics、logs、traces、events、仪表盘 | 汇总相关上下文，分析异常特征，给出初步判断 | 减少人工切换工具和整理信息的时间 |
| 根因分析 | 灭火图、服务关系、标签、日志聚类、Tracing 检索结果 | 根据环境关系筛选高相关数据，结合多类信号做分析 | 缩小排查范围，提升问题分析效率 |
| 值班协作 | Runbook、历史 AI 分析过程、工程师确认后的结论 | 将有效分析沉淀为知识库，并在后续分析中复用 | 让团队经验持续积累，而不是停留在个人脑中 |
| 可观测性数据治理 | Prometheus、ElasticSearch、ClickHouse、Doris、Zabbix、MySQL、公有云监控等数据源 | 统一接入、增强标签、预处理上下文，并导出给大模型 | 为 AI OnCall 提供可理解、可计算、可复用的数据基础 |
| 多场景分析 | 灭火图状态、特征分析、日志检索、Tracing 检索、事件分析、仪表盘分析 | 多个智能体分别聚焦单个场景或某一类数据，再汇总输出 | 提升分析准确性和速度，降低对模型上下文大小的依赖 |
实现智能 OnCall 的关键条件
1. 足够智能且成本可控的大模型
首先，需要有足够智能的大模型，以及可负担的 API 调用成本。DeepSeek 把所有人托举到了同一个高度。DeepSeek 具备较强的思考能力，适合分析非结构化的可观测性数据，比如标签、日志文本、事件等。
在 Flashcat 中，可以直接对接并使用公有云托管的大模型 API。如果企业考虑数据安全因素，也可以使用内部私有化部署的大模型。
2. 完备且可统一访问的可观测性数据
足够完备的可观测性数据，是智能 Oncall 的基础条件。企业内部的 metrics、logs、traces、events 等各个维度的数据，需要被封装成统一接口，再暴露给 AI。
这件事的本质，是把原本分散在不同工具、不同存储、不同平台里的可观测性数据，整理成 AI agent 能理解和调用的数据能力。在 Flashcat 中，这项工作被分解为 5 个步骤。
Flashcat 如何把可观测性数据交给 AI
第一步：集成已有数据源
使用数据源集成的方式，将企业已经拥有的 Prometheus、ElasticSearch、ClickHouse、Doris、Zabbix、MySQL 等，以及公有云提供的各种可观测性工具，如阿里云 SLS、阿里云 Arms、AWS Cloudwatch、Azure 云监控等，直接以数据源的方式注册到 Flashcat 平台中，再经由 Flashcat 统一暴露给 AI agent。
Flashcat 目前支持 40 多种常用的数据源对接。对于 AI OnCall 来说，这一步解决的是“数据在哪里”和“AI 如何统一访问”的问题。
第二步：采集缺失数据
如果企业已经拥有的数据不够完整，推荐使用采集器 Categraf 查漏补缺。缺失的数据被采集之后，同样存储到 Flashcat 平台中，再暴露给 AI agent。
告警响应和根因分析都依赖上下文完整性。缺少关键指标、日志或事件时，AI 即使具备推理能力，也很难给出可靠判断。
第三步：做数据增强
各类可观测性数据“有”是一回事，质量高不高是更关键的另一回事。在可观测性领域，标签（Label）是一个关键概念。
通过对 metrics、logs、traces、events 等各维度数据打上足够丰富且一致的标签，可以表达可观测性数据之间的联系，描述实体属性以及实体之间的交互关系。这个打标签的动作，我们称为数据增强。
数据增强可以发生在数据采集阶段。例如，让采集器和 CMDB、K8s APIServer、公有云控制器进行交互，为采集到的数据增加更多相关标签。它也可以发生在数据传输 pipeline 中，通过实时标签提取、转换和映射，让可观测性数据的标签更丰富、更一致，从而让 AI 更容易理解。
第四步：预处理高相关上下文
前面三步让企业拥有了更完备、质量更高的数据。接下来会遇到一个现实问题：可观测性数据量往往很大，如果一股脑全交给大模型分析，单纯靠“大力出奇迹”是行不通的。
在 Flashcat 中，我们利用“灭火图”构建了 CI/CD、Infra、Kubernetes、Metrics、Logs、Traces、Events、Runbook 的完整环境地图，用来描述 API、服务、Pods、组件和其他环境之间的交互关系。
根据这些交互关系，Flashcat 可以更精确地把相关性高的数据发送给大模型分析。与此同时，这些上下文信息本身也是大模型理解问题的重要输入。再结合日志聚类分析、相似性去重等方法，可以进一步减少大模型的数据处理压力。
第五步：以类似 MCP Server 的方式导出数据
Flashcat 采用类似 MCP Server 的方式，把各类可观测性数据与上下文环境信息导出给大模型。未来，企业内部的各种 MCP Client 也可以共享 Flashcat 中这些有价值的数据。
这一步让 AI OnCall 不只是一个独立功能，而是可以成为企业内部智能化运维体系中的数据和上下文入口。
多智能体架构：把复杂分析拆给不同专家
Flashcat 采用多智能体架构。每个智能体聚焦分析单个场景或某一类型的数据，然后汇总输出。
预设的分析场景包括：
- 灭火图状态
- 特征分析
- 日志检索
- Tracing 检索
- 事件分析
- 仪表盘分析
多智能体结构有助于提升问题分析的准确性和智能化程度，也可以提升分析速度，并降低对模型上下文大小的依赖。对于值班工程师来说，这意味着 AI 不只是泛泛地“看一遍数据”，而是按场景把告警响应、日志检索、Tracing 检索、事件分析和仪表盘分析分工处理，再汇总为更容易使用的结论。
知识库：不要只依赖历史文档，要让 AI 持续积累
关于知识库在智能 Oncall 领域的价值和实现路径，普遍存在一个误区：很多人认为可以利用企业内部积累的各种告警处理记录、复盘记录和预案，结合 RAG，提升大模型分析效果。
我们的实际经验是，在现实情况中，大部分企业已有知识库数据的质量和数量都不够，基本不可用。问题不在于 RAG 这个方向本身，而在于输入知识的质量不够稳定，难以支撑可靠的告警响应和根因分析。
在 Flashcat 中，我们采用 AI 来积累知识库。每次 AI 分析的过程和结论，都由工程师加以判断。如果工程师认为有效，就将其入库。随着 AI 分析使用频率提高，高质量知识库会像滚雪球一样越来越多、越来越有价值，形成正向循环。
这套机制也让值班协作更容易沉淀：工程师不只是处理一次故障，而是在处理过程中为后续相似问题留下可复用的分析路径。
FAQ
AI OnCall 是什么？
AI OnCall 是把大模型和智能体引入可观测性与 Oncall 流程的一种实践。它让 AI 读取 metrics、logs、traces、events、Runbook、仪表盘和环境上下文，帮助工程师完成告警响应、问题分析和初步根因判断。
AI OnCall 会替代值班工程师吗？
本文讨论的智能 Oncall 不是替代工程师，而是为工程师打造智能分身。AI 负责分担数据整理、上下文分析和候选结论生成等繁琐工作，工程师仍然负责判断、确认和处置。
为什么可观测性数据质量会影响 AI OnCall 效果？
大模型需要足够完整且一致的上下文，才能理解告警背后的系统关系。metrics、logs、traces、events 等数据如果缺失、标签不一致或无法统一访问，AI 的分析质量就会受到限制。
Flashcat 为什么使用多智能体架构？
因为可观测性分析涉及灭火图状态、特征分析、日志检索、Tracing 检索、事件分析、仪表盘分析等多个场景。让不同智能体聚焦不同场景，再汇总输出，有助于提升分析准确性和速度，并降低对模型上下文大小的依赖。
智能 OnCall 的知识库应该如何建设？
更可行的路径是让 AI 在实际分析中持续积累知识。每次 AI 分析的过程和结论由工程师判断，有效内容再进入知识库。这样沉淀下来的知识更贴近真实告警响应和根因分析场景。
结论
随着 AI 分析速度和准确性逐步提升，大模型调用成本逐步可控，在不远的将来，大部分故障和告警都可以默认开启智能 Oncall。
AI 加速可观测正在发生。它的关键不只是大模型本身，而是大模型能否连接到高质量的可观测性数据、系统上下文、分析工具和工程师确认后的知识沉淀。Flashcat 希望通过数据源集成、采集补全、标签增强、上下文预处理、类似 MCP Server 的数据导出和多智能体分析，为工程师打造真正可用的智能 Oncall 分身。
如果你也在研究这个方向，欢迎与我们一起交流：
