三大头部互联网企业交锋，AI 时代可观测边界出现了吗？

LLM 的推理能力与生成式 AI 的数据理解能力，为可观测技术的演进提供了全新思路。另一方面，可观测技术也在反哺 AI 领域。那么， AI 与可观测技术是如何双向赋能的？AIOps 从实验到生产、从口号到落地的行动路径又是怎么样的？

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请 阿里云可观测技术架构负责人、高级技术专家张城 担任主持人，和 阿里云算法专家李也博士、字节跳动 Dev-Infra 观测平台算法负责人董善东博士、小红书可观测团队负责人王亚普 一起，在 QCon 全球软件开发大会 2025 上海站 即将召开之际，共同探讨 AI 时代可观测的新边界。

部分精彩观点如下：

• 传统可观测主要是“看见”，而未来的新一代运维范式有望实现“发现—分析—解决—复盘”的完整闭环。在这个过程中，可观测系统正从单纯的“眼睛”，演化为同时具备“大脑”和“手”的角色。

• 只有当我们拥有贴近真实场景的评测标准，并在大量真实案例上验证模型的表现，确认它在该说“不知道”时能坦诚地说“不会”，不乱编、不幻觉，那么我们才能真正建立起对 AI 的信任机制。

• “垃圾进，垃圾出”的定律在 AI 时代不仅没有失效，反而因 LLM 对数据规模和质量的高依赖被显著放大。

• 三到五年内实现“半自治”运维是可行的，部分场景甚至能实现闭环自动化。但要达到完全自治、真正实现所谓“咖啡式运维”，仍有很长的路要走。

在 QCon全球软件开发大会2025 上海站 上，我们特别设置了【AI 时代的可观测实践】专题。该专题将讨论 AIOps 规模化落地、大模型可观测等关键策略，探索 AI 时代可观测技术的最新趋势。

以下内容基于直播速记整理，经 InfoQ 删减。

完整直播回放可查看：https://www.infoq.cn/video/YOTeVHta0A3Xqq2l4Bbp

张城：在你们看来，AI 正在给可观测性这件“事”本身，带来哪些根本性的、不同于以往的改变？

李也： 一是 “AI for 可观测”。过去，我们需要手动编写 SQL 来提取和分析数据。而现在，只要为大模型提供清晰的上下文和数据格式，它就能出色地自动生成 SQL、配置大盘和定时任务。我们内部评测显示，在上下文充足时，大模型在此类任务上的准确率可达 80%-90%，甚至超过不熟悉 SQL 的工程师。这意味着，数据的提取方式已被彻底改变。

在更复杂的探索性、关联性分析方面，AI 同样能提供助力。例如，将复杂的系统场景截图交给大模型，其分析结果有时优于新手工程师。虽然它目前还无法替代专家进行根因分析，但已能显著提升所有工程师的工作效率。从“给人看”转向“给 AI 看”。未来的关键不再仅仅是美观的可视化，而是如何以结构化的方式组织数据，使其能高效地被大模型理解与利用。

二是 “可观测 for AI”。AI 系统的出现带来了新的可观测需求。大模型的每次调用都会产生成本，因此生成的所有 trace 数据都会被保留，这大幅增加了存储需求。同时，AI 系统的分析和诊断也更加复杂。当一个大模型在 workflow 或 agent 执行中出现问题，我们需要能够诊断其原因，评估其性能。比如，它在 RAG 环节是否检索到了正确的文档？幻觉是在哪个阶段产生的？这些都对新一代可观测系统提出了更高要求。再比如，在大规模 GPU 集群中实现高效可观测与故障自愈，也成为新的挑战。

董善东：LLM 为可观测领域提供了一个通用的“大脑基座”，显著改变了传统 AIOps 的实施方式。

过去，我们实施 AIOps 算法需要从零开始：结合场景目标、收集清洗数据、再建模训练与调优。而 LLM 的引入，为我们提供了一个天然的“六七十分”基础能力，使我们能更快、更好地在具体观测场景中构建出可用的演示原型。正如许多专家所言，LLM 相当于为各行各业配备了具备通用能力的大学生，而后续在本领域的深化优化，仍需行业自身完成。

LLM 在多模态理解与融合方面表现出色，其效果提升与反馈机制也更加高效。关键之一在于多模态上下文的应用：我们的任务重点转变为如何为 LLM 提供更全面、高质量的上下文信息，而最困难的多源信息融合与理解环节，则由 LLM 承担。以异常检测为例，传统方法多局限于单一指标，而 LLM 能够综合指标、日志、追踪等多类数据，实现更全面的异常判断。更优质的上下文，必将带来更出色的检测效果。

此外，传统方法中融入人工反馈通常需要重新训练模型，而 LLM 凭借其强大的文本理解能力，可以快速、便捷地将人工反馈应用于下一次检测任务中。

相较于传统 AIOps 往往针对单点场景进行优化，LLM 的引入使得从告警全生命周期——包括发现问题、分析、处理、复盘、预防乃至系统自愈——进行整体优化成为可能。我们可以在现有观测数据平台与各类小模型的基础上，通过 Agent 架构，将整个流程有效串联起来：LLM 与领域知识共同构成决策“大脑”，观测数据与小模型则作为“工具手”，让 Agent 能够逐条处理告警，与人协同工作。未来，它甚至可能像数字生命一样，承担起 SRE 的职责。

王亚普：AI 训练过程出现问题时，常常表现为整体“卡住”，这使得系统稳定性和复杂度显著增加。过去的可观测主要依赖规则和阈值告警，针对已知问题；而 AI 的引入让系统具备一定的语义理解和推理能力，可以对未知问题进行可解释、可验证的分析。在以往的工作中，我们人工排查性能劣化可能需要数小时。而借助 AI，我们可以自动分析指标、链路和变更之间的关联，从被动响应转向主动可观测，甚至进一步实现推理与洞察的能力。

过去，运维或研发人员需要掌握复杂的查询语言，并理解监控平台的各种概念。而现在，AI 让可观测变得对话式，工程师只需输入诸如“帮我查一下日志成功率”这样的自然语言请求，大模型即可完成分析。历史上，可观测平台往往是支撑性系统，难以满足各业务线的定制需求。但有了 AI，自助式服务和个性化编排成为可能。可观测平台可以聚焦于底层能力和抽象输出，业务团队则能自由组合工具，实现“千人千面”的运维体验。

第三个层面是智能决策闭环的形成。传统可观测主要是“看见”，而未来的新一代运维范式有望实现“发现—分析—解决—复盘”的完整闭环。在这个过程中，可观测系统正从单纯的“眼睛”，演化为同时具备“大脑”和“手”的角色。

张城：对于一个 AI Agent ，我们到底该如何衡量它的“智能”？是实验室评测集的分数更重要，还是它在复杂线上环境中解决实际问题的“实战能力”更重要？

董善东： 衡量一个 AI Agent 的智能，得分成通用能力和专属能力 2 块来考虑。

对于通用化能力，现在无论是对于 LLM 的 benchmark，MMLU、MATH 等，还是像对于 Agent 能力的评估: AgentBench、SWE-bench 等，都有很好的参考意义，度量了 LLM 的通用理解、推理、规划等各方面的能力。

而对于专属能力，这里则更需要考虑它解决实际问题的实战能力。这一点在观测领域尤为显著。当然像 AIOps 社区围绕着观测、排障已经构建了一些 demo 以及对应的数据集，在这些数据集上可以作为一个参考。但是在各个公司内，我看到的是有很多相对更加复杂、需求也不一定是标准化的问题，这对于 AI Agent 的实战能力要求也是更高。

以观测领域场景的 RCA 为例，我个人简单对 AI Agent 的粗略分级，供大家参考:

L1 ：单点增强。在某一个具体的问题上，分析流程还是以前的流程，但是 AI Agent 可以协助做一些环节的分析增强。

L2：自主性解决问题。RCA 完全 Agent 化，当有一个自定义的指标出现问题后，AI Agent 可以根据预设的 SOP 和实际情况进行规划、执行，直至完成。

L3：学习。在人类定下一个值守目标、任务的基础之上，可以自行阅读团队内的文档、资料，进行知识提取和学习。当用户询问一个通用化排障流程，也能够按照流程去评估自己是否可以正确执行。如果缺少了一些工具，可以自己按照一定的协议和格式来生成补充这些工具，最后将一个排障流程正确执行完成并输出。

李也： 实战能力更为重要，实验室评测应尽可能贴近真实场景。目前一些大模型榜单存在“刷榜”现象。以 SWE Bench Verified 为例，仅包含约 500 道题目。如果算法工程师每天修复一个错误案例，持续一年，几乎可以“背熟”整个数据集，通过人为过拟合的方式获得高分。这导致实验室评分往往无法真实反映模型的实战水平。

类似问题在其他领域同样存在。例如微服务场景中，实验室基准测试通常只涉及十几个服务，而真实生产系统可能有上百个，且每个服务包含大量操作，复杂度完全不在一个量级。实验室中通过混沌工程注入的故障类型相对有限，而现实中的故障千奇百怪。如果仅用已知问题做验证，算法表现可能并不优于规则系统，无法体现大模型在未知场景中的泛化能力。

评估实战能力需要合理划分任务难度。不能让“小学一年级学生去答高考题”。同样，如果让当前大模型直接处理 L3 级别的复杂任务，可能全部失败，但这并不代表 AI 无用，而是说明它目前尚不适合此类高阶场景。相反，在诸如将自然语言转换为 SQL 或 PromQL 等确定性较高的任务中，大模型已表现可靠。这类贴近实战的评测，才能真正增强我们对 AI 落地的信心。

张城：大模型的出现，是否意味着我们过去依赖的、非常精致的传统算法遇到了天花板？它在处理可观测性数据时，到底带来了哪些“质”的不同？

王亚普： 传统算法尚未遇到天花板，其最大优势在于确定性。许多场景中，传统算法依然不可替代。以时序异常检测为例，目前各家生产系统仍在大规模使用相关算法，它们具有响应快、资源消耗低、可控性强、稳定性好的特点。对于一些成熟的小模型算法，只要场景明确，其准确率可以非常高，延迟甚至可控制在毫秒级，这是当前大模型难以匹敌的优势。

但大模型的出现带来了质的变化，主要体现在学习与提效能力上。传统算法在处理单一数据源时非常高效，但在多模态、跨领域的复杂问题上力不从心。而大模型能够同时理解多种信息，包括指标曲线、日志文本、用户反馈、代码变更等，并在它们之间建立关联。这种“融会贯通”的能力正是传统算法难以实现的。

第二个优势是可编程与可解释性。传统算法往往需要采集数据、人工标注、调参训练，工作量巨大。而大模型可以通过推理链和工具调用，自动拼装故障诊断流程。例如，它能根据逻辑顺序决定先检查哪条业务线、再分析 24 小时内的变更，最后是否需要进一步下钻。这种自动化推理显著缩短了定位时间，大幅提升了人力效率。

第三个优势是泛化能力。传统算法虽然在特定场景下表现优异，但一旦迁移到新环境，就需要重新训练和调优，成本高且稳定性差。而大模型具备较好的迁移性和适配性，能够快速应对新的应用场景。这种泛化能力也是大模型带来的又一次质变。

张城：未来的可观测平台技术栈里，大模型和传统算法会是什么关系？是“取代”，是“互补”，还是某种新的“协同”模式？

王亚普： 传统算法与大模型之间的关系并非对立，而是分工协作、优势互补，就像人类大脑中存在不同的认知系统。一个系统是快速、自动化的反应系统，例如开车时看到红灯立即刹车，或在听到警报时本能地产生警觉，这种反应不需要深度思考，效率极高；另一个系统则是需要缓慢思考、整合知识、深入分析的系统，比如诊断复杂问题或做出关键决策。两者并不冲突，而是协同工作的。

从这个角度看，传统算法更像是前者，针对特定场景进行训练，能在已知范围内做出快速、准确、稳定的反应，类似“肌肉记忆”；而大模型则更像后者，它具备广泛的知识储备和复杂的推理能力，能处理跨领域、复杂的信息问题，但响应速度较慢，资源消耗更高，有时甚至会“想得太多”。

过去，传统算法是唯一选择；如今，大模型成为新的主角，而传统算法转为配角，但其价值并未降低。相反，它找到了更合适的位置。我们不应将两者视为“非此即彼”的选择，而应通过协作机制让它们优势互补，实现 “1 + 1 > 2”。

李也： 针对“取代关系”这个问题，我想用“排除法”来讨论。首先排除大模型取代传统算法的可能性。传统算法和 CPU 算子已经能很好地处理线上约 80%–90% 的场景。以阿里云的实践为例，基于规则的方法能够拦截或自愈系统在 60%–70% 以上的异常情况。这类方法运行高效、消耗低、可解释性强，既然“杀鸡不用牛刀”，我们没有必要动用计算开销巨大的大模型来处理这些问题。

此外，即便不考虑效率和成本问题，从技术角度看，大模型也不适合直接处理原始的可观测数据，因为数据量极其庞大。例如，一分钟的 trace 数据可能达到数 GB，如果将这些数据全部输入大模型，会直接导致 context window 溢出；日志数据的体量更是成倍增长。因此，目前的自然语言大模型无法直接处理如此规模的原始数据。

即便我们对数据进行压缩再输入模型，由于这些模型主要基于自然语言文本训练，它们对“机器生成的数据”缺乏先验认知。可观测数据以时序数值和机器日志为主，而大模型学习的语料是人类语言，两者存在天然差异。因此，大模型在可观测领域需要进行领域微调或强化学习，才能具备实用价值。例如，在根因排序（Root Cause Ranking）任务中，如果直接使用开源的通用大模型，准确率往往只有 30%–40%，甚至更低；但经过可观测领域的专门微调或强化学习后，准确率可提升至 80%–90% 以上。

综上所述，大模型无法取代传统算法，而通用大模型在可观测领域也并非“万能”。在特定垂直场景下，我们仍需要“又快又准”的领域模型。同时，也不应固守旧有的规则体系，在该协同时就应协同。以往我们手工编写大量规则，而现在大模型可以帮助总结规律、生成标注，通过数据驱动的方式自动学习并提炼出规则，从而减少人工维护。

董善东： 我理解的还是互补和增强的协同关系。

一方面，在很多观测场景下，确实小模型在执行的效率、准确率上都已经非常不错。这些场景下就让小模型来执行就可以了。对应的小模型也可以作为 tools 被 Agent 所使用。当然 LLM 可能也可以取得等同的准确率，但是在运行效率上肯定是不如这些小模型的。

另外一方面，大模型确实在很多地方又可以来增强小模型。以检测为例：传统的小模型构建好了之后，如果在某些场景下的 bad case 无法优化，这时候也可以考虑通过引入 LLM 和知识库，对小模型的结果做一些校正，来增强原始异常检测效果。另外，有些缺失空白的环节，如果没有做小模型，也可以快速地拿 LLM 来补齐这个环节。以 RCA 为例，很多厂商已经搭建好了微服务级别的 RCA 的分析模型。这时候定位到数据库，数据库定位分析可能又不是团队擅长，这时候就可以用 LLM 来快速补齐这一个环节的能力。

张城：技术路径清晰之后，一个更棘手的问题就浮出水面了：信任。 当 AI 的诊断甚至决策建议摆在我们面前时，我们敢不敢相信？各位在实践中，是如何解决这个“信任”难题的？如何构建让人放心的机制？

李也： 我们坐出租车时，为什么会信任司机？是因为他经过专业培训、拥有丰富经验？还是因为他具备可解释、可验证的安全机制？我们为什么信任飞机？难道是因为我们能用数学或物理公式证明飞机不会掉下来吗？显然不是。真正的原因是：我们坐了成百上千次飞机、打了无数次出租车，而它们几乎从未出过事。

回到大模型，我们可能永远也无法“数学证明”它是绝对可信的。它依然会出现各种 bad case，产生幻觉，目前人类也还没有足够的认知能力去彻底验证大模型的可被信任性。但我们能做的，是通过大量实践与真实评测去建立信任。

比如，如果我们尝试了一万次，其中 9999 次模型都给出了正确的结果，没有“胡说八道”，我们就会逐渐建立起信任感。相反，如果十次中有两三次结果不靠谱，那信任就会打折；如果十次有八次不靠谱，那基本就无法使用了。

因此，信任与评测体系密切相关。只有当我们拥有贴近真实场景的评测标准，并在大量真实案例上验证模型的表现，确认它在该说“不知道”时能坦诚地说“不会”，不乱编、不幻觉，那么我们才能真正建立起对 AI 的信任机制。

王亚普： 目前，无论是 GPT 还是其他大模型，其可靠性与确定性仍是工程上的难题。因此，在上线任何新功能时，我们都不会盲目信任它，而是采用灰度验证等手段逐步放量。这并非“不信任”，而是以审慎的方式去建立信任。

“信任”是一个渐进的过程，从辅助决策阶段，再到真正赋能核心决策阶段。在早期阶段，AI 应当只是“助手”或“建议者”，不直接拥有决策权。接下来，可以选择一些低风险场景来让 AI 自主处理，比如常见的运维咨询、日报生成、复盘报告等。这些任务即便出错，影响也可控。通过在这些场景中积累上千、上万次成功案例，我们就能逐步建立起团队对 AI 的信任，最终再把它推广到高价值、关键决策的应用中。

当然，当 AI 进入更关键的环节时，必须具备三种保障机制：1、可解释性：AI 在给出结论时，应当能提供推理路径和验证依据，让使用者能复核其逻辑；2、可审计性：所有 AI 决策过程都应记录为审计日志，关键链路要有审批机制和约束条件，确保 AI 是“加速决策”，而非“跳过安全流程”；3、可回滚性：在高风险任务中，AI 的操作必须支持快速回滚，一旦判断错误，可通过“一键撤销”或状态恢复机制还原现场。

AI 的价值在于提升效率、加速决策，而不是取代安全流程或责任机制。工程化的信任建设，正是让 AI 真正“可用、可控、可信”的关键。

董善东：AI 信任的建立，本质是一个循序渐进的过程，不能一蹴而就。它需要围绕两类关键变量展开：一是“人”的接受度差异，二是“场景”的效果验证。

从“易接受人群”切入，建立初始信任样本。不同业务团队对 AI 的接受度天然存在差异，有些团队更愿意尝试新技术。优先选择这类“激进型”业务团队深度合作，而非全面铺开。借助他们的实践，快速验证 AI 在具体场景的价值，形成可复制的信任案例。

嵌入日常路径，让 AI“润物细无声”地积累信任。早期阶段，核心是让 AI 融入人的现有工作流程，避免增加额外使用成本。以“告警群事件处理”为例，可分两步推进：第一步：做“辅助者”：在告警卡片的回复中，自动附带 AI 生成的分析和修复建议。用户无需主动调用，每次处理告警都能看到 AI 输出，逐步形成认知。第二步：做“勤杂工”：承接重复性工作，比如定期总结告警群的事件数据、梳理需重点关注的问题。让用户从“观察 AI”过渡到“依赖 AI 减负”。当然这一步还可以加上定期的一些 case 准确率统计， 让使用者更有量化的体感，强化使用 AI 效果还不错的印象和认知。

场景效果作为重要衡量指标，控制推广节奏。信任的核心支撑是“效果可靠”，必须避免因盲目推广破坏信任。聚焦单一场景做深做透，待效果稳定、用户认可后，再横向推广到其他场景。一旦某场景出现频繁失误，会直接打击用户信心，后续重建信任的成本会更高。

张城：当 AI 接管了大量重复性工作后，SRE 和运维工程师的核心价值会转向哪里？是会升级为“AI 训练师”和“复杂问题专家”，还是会面临巨大的转型挑战？

董善东： 首先说挑战。传统的 SRE 往往承担大量重复性工作，这些工作虽然枯燥，但也让团队形成了某种稳定结构。然而，随着大模型和 SRE Agent 的落地与优化，这些重复性任务将被率先自动化。结果是，SRE 将不得不向更复杂、更高价值的问题转型，也意味着每个人都需要成为“复杂问题专家”。

我仍坚持机遇大于挑战。因为长期从事重复性工作并不会带来成长，而当这些工作被 Agent 接管后，人力被释放出来，就能专注于更复杂、更具价值的任务。只有在有时间、有空间不断学习和处理复杂问题时，SRE 才能真正成长为专家。

其次，随着 Agent 的深入应用，“人如何与 Agent 协作”将成为新的课题。SRE 拥有强大的领域知识，比算法工程师更了解运维场景，他们能将自身经验结构化、沉淀为可复用的知识，进一步赋能 AI。SRE 也因此逐渐具备了“AI 训练师”的角色。虽然这种训练不同于传统模型训练，但在整理经验、与 Agent 高效协作的过程中，SRE 的专业能力会不断提升。

王亚普：AI 时代不是淘汰，而是“升维”。以 SRE 为例，过去我们更像“救火员”，而未来则会转型为“高可用架构师”。当 AI 接管告警、常规排查等琐碎事务后，SRE 将有时间思考更本质的问题，比如系统架构是否合理、哪些地方存在设计缺陷、如何从根源提升系统稳定性。这就是高可用架构师的价值所在。

此外，SRE 还会承担“AI 训练师”的角色。SRE 的专家经验极其宝贵——踩过的坑、总结的最佳实践、制定的高可用标准，都是训练 AI 的重要素材。AI 要变得真正智能，就离不开人类专家对知识的结构化整理与持续输入。

这意味着 SRE 的角色正从“单兵作战”变成人机协作。SRE 需要学会指挥、验证 AI 的输出，并在必要时接管控制。这就像使用 AI Coding，它能显著提升效率，但人仍需负责复核与决策。

当然，这种转型对所有行业都是挑战。唯一不变的是，我们必须持续学习，拓展思维方式，从“做事的人”转变为“抽象问题、设计系统的人”。

李也： 我认为谈论 SRE 时要区分两类角色：初级岗位与专家岗位。未来，这两类角色会呈现明显的两极分化。因为真正的专家型 SRE 平时并不做重复劳动，他们负责解决新问题、建立 SOP、编写自动化代码并做关键决策。无论是制定架构策略还是审批关键变更，仍然需要人来承担责任。即使是简单系统，交给大模型运维也不够可靠。专家不仅不会被淘汰，反而会因为能“带 AI 小弟”而价值倍增。过去一个专家可能独立作战，未来他能带领多个智能 Agent 协同工作，显著放大产出。

与此同时，那些只负责执行重复任务的初级岗位可能会逐渐消失，因为这部分工作已经被自动化完成。未来的大模型甚至可能能主动提出新的 SOP 或解决思路，专家只需审核与确认，但最终责任仍在专家身上——“点同意的人也要能背锅”。这也意味着，未来的 SRE 专家不仅要懂技术，更要有深厚的领域经验与判断力。

张城：只要“背锅”的岗位还存在，SRE 就不会消失。我有个同事十几年前加入阿里时，做的“运维工作”是真正在机房里搬机器、插线的。这样的岗位如今确实没有了，但这个人依然在阿里，并且成长为新的角色。由此可见，只要保持持续学习与自我提升的心态，无论技术如何变化，人总能找到自己的位置。

在 AI 时代，“垃圾进，垃圾出”的定律是否被放大了？各位在可观测数据的质量治理、规范统一方面，有哪些特别想分享的经验或教训？ 李也：** 一个新的 SRE 工程师入职后，如果没有任何培训资料，也不了解可观测系统中各个 schema 字段的含义，那他是无法开展工作的。从这个角度来说，所谓的“context engineering”在大模型中更显重要。如果我们不明确告诉模型这些可观测数据字段的含义，不对数据进行治理，也不将系统的运行流程和知识传递给它，它就无法正常运作。人也一样，缺乏上下文信息就无法处理问题。这是第一点。

第二点，可观测数据的规模极大，其中相当一部分其实是“垃圾数据”，例如重复的日志，没有变化、没有价值。在大模型时代，这些“垃圾”数据不应直接输入模型，而是需要经过筛选与过滤，提取有价值的信息，缩短模型所需的上下文长度。

第三点，与强化学习相关。在强化学习的实践中，可验证的奖励信号至关重要。可观测性领域中，若某个现象或问题的根因并不明确，甚至连人都判断不清楚，往往是因为我们缺乏足够的观测数据。这种情况下，如果将这些模糊的数据交给强化学习模型去学习，只会让模型越学越糊涂。因为连人都无法确定结论，模型更无从得出正确的因果关系。

董善东：“垃圾进，垃圾出”的定律在 AI 时代不仅没有失效，反而因 LLM 对数据规模和质量的高依赖被显著放大。我们在构建 AI Agent 过程中，反复会提及和优化的一个难点是： 需要确保给到 LLM 的 Context 是精确、足够、不给到 LLM 的 context 的逻辑其实也是类似的。

我觉得判断一个可观测数据和对应产品质量好不好，有 3 个可以自问的问题：人能很容易使用数据吗？代码或算法容易分析数据吗？平台内各处容易联动跳转吗？治理的核心目标，是让数据既能满足人的使用需求，也能适配算法、AI 分析，同时支持跨平台联动。

让“人容易使用数据”。首先，需要统一数据语义：给不同来源的可观测数据（如日志、监控指标、链路追踪）定义统一标签，比如“error_code:500”在日志和告警中保持一致释义，避免人在跨场景使用时需反复核对。其次，简化数据获取路径：搭建统一的数据查询入口，支持非技术人员通过关键词（如“支付系统 + 昨日 18 点故障”）快速调取所需数据，无需掌握复杂的 SQL 语法或跨平台切换。

让 AI 更容易读懂数据、避免冲突。首先，推动非结构化数据结构化：将日志、告警描述等非结构化数据转化为键值对（Key-Value）或表格格式，比如将“服务器 A 内存使用率 95%”拆解为“server: A, metric: memory_usage, value: 95%”，方便算法直接提取特征。其次，建立数据质量校验规则：在数据采集阶段嵌入自动化校验逻辑，比如监控指标的取值范围：CPU 使用率不可能超过 100%、时间戳的统一性：避免跨时区数据混乱，单位的统一。 从源头过滤“异常数据”，减少 AI 冲突的理解和计算成本。

让“平台内各处容易联动跳转”， 进一步验证“数据链路”与“场景闭环”。首先，构建数据关联关系：让不同类型的可观测数据形成“联动链路”，比如点击某条告警信息，可直接跳转至对应的日志详情页、相关链路追踪图，无需人工复制 ID 跨平台查询。这些产品上能够形成的联动， 也往往很好的体验出数据层面的关联关系。 这种关联关系的构建， 相信也更容易让 AI 能拿到全面的 Context。 其次，统一数据存储与权限：采用兼容多类型数据的存储架构，同时建立统一的权限体系，避免因平台间权限隔离导致“数据孤岛”。

王亚普： 别说大模型了，就算是传统监控系统，一旦数据出错，在公司内部都可能引发很大争议。比如误报或漏报，都会造成严重后果。进入 AI 时代后，这种风险被放大了。错误的数据不再只是导致错误的报表，而可能引发错误的决策，甚至错误的执行，后果会更加严重。

在过去的传统监控中，系统对“垃圾数据”尚有一定容忍度：命名不规范、格式混乱、日志难懂，人还能凭经验进行补全或纠错。但大模型做不到这一点。它若理解错误，可能会得出离谱的根因分析结论。由此可见，大模型对数据语义的理解极度依赖数据质量，垃圾数据会直接破坏其分析能力。

因此，标准化工作变得尤为重要。就像 OpenTelemetry 的出现，使得在 AI 时代快速落地链路追踪、指标监控等变得可能。在大模型语义理解层面，标准化同样关键。要实现深层次的可观测性，必须依赖数据之间的关联和可理解的数据建模。这是一项极具挑战的工作，需要公司层面的战略决心与资源投入。当前行业内尚无统一标准，阿里内部的 UModel 是少数尝试之一，但整体上各公司场景差异大，很难实现完全统一。

此外，我认为在大模型时代，语义标注的完整性甚至比格式统一更为重要。我们在开发 agent 工具时发现，一些字段很难在不同系统间统一，与其强行统一，不如在语义上建立清晰的标注和定义，让模型真正理解原始数据的含义。因此，数据治理和标准化是长期工程，也是可观测性系统在 AI 时代能否发挥价值的前提。高质量的数据，是一切智能分析的基础。

张城：我在 2021 年参与 UModel 项目时，大模型还没像后来那样火。当时推动这件事的初衷，并不是为了适配大模型，而是为了更好地管理多系统的观测数据。这个需求本身一直存在，只不过在大模型时代被放大了。当我们希望模型能理解数据、理解系统语义时，这种建模和标准化的重要性就被进一步凸显。在建设可观测性系统时，一定要关注数据质量和语义化。只有保证了数据的语义清晰和一致性，大模型才能真正读懂并发挥作用。

观众：AI 推理甚至是训练过程的这种可观测，只能是研发大模型的团队才能做吗？

王亚普：这并没有一个确定的答案，因为不同公司的人才结构和资源分配差异很大。以我们小红书为例，我们更倾向于把资源用在刀刃上，让每个人专注在自己最擅长的领域。不过我更想分享的不是这一点，而是我们在可观测领域里做的一些尝试和突破。以我们团队的经历为例，实际情况并不像想象中那么简单。

我们团队里负责训练和推理的同学，他们的专业能力主要集中在这一块。在初期沟通时，双方团队几乎是“鸡同鸭讲”的状态，信息挖掘成了难题。所以，很难要求一个做训练推理的人对可观测性或系统稳定性有深入理解。反过来说，我们做可观测的，也要主动走近他们，学习训练与推理的流程和原理。只有理解这些机制，我们才能提出建设性的意见，与他们进行平等、深入的讨论，从而共同建设更稳定的平台。

观众：AI 时代的专家该怎么样去培养？

张城：AI 时代的变革并不是一夜之间发生的，而是一个循序渐进的过程，这意味着我们都有充足的时间去学习、提升和适应。更重要的是，这并不代表在明年或后年，大多数 SRE 就会被取代。这种情况发生的可能性很低。让 AI agent 或大模型完全取代人，需要模型能真正承担责任，而这在当前阶段几乎做不到。就像自动驾驶行业一样，虽然技术发展迅速，但至今也没能完全取代人类司机。所以大家不必过度焦虑。

第二点，人该如何进步、如何成长为专家？必须在这个领域至少沉淀一万个小时。时间和积累是成为专家的关键。不要急于求成，要脚踏实地、循序渐进。现在的机会在于，学习成本大大降低了。过去我们要查资料、读论文、看技术网站都很费力，而现在借助大模型，这些学习和理解的过程快了数倍。无论是学习新知识还是解决问题，效率都被显著放大。因此，我建议大家要积极利用大模型的各种能力来提升自己，这是一个极好的机会。

观众：一般的企业该怎么样去构建自己的可观测平台去协助运维？

张城：第一条路是借助开源生态。开源社区已经有许多成熟的可观测数据解决方案，如果公司有人力投入，并且有具备一定可观测经验的同学参与，是完全可以自建的。要想进一步做智能化分析，则需要团队对大模型和 Agent 技术有一定理解，这部分可以通过自学获得，毕竟现在还没有哪所大学开设“AI Agent 专业”。

第二条路是使用商业化的平台解决方案。这些平台能帮助企业快速打通数据接入、存储、分析等关键环节，从而节省自建成本，让团队把精力集中在更有价值的产出上，比如为 SRE 团队提供洞察、提升系统稳定性。当然，商业方案会带来额外成本，这是权衡效率与预算的取舍问题。

观众：微调对于通用性不会有损失吗？是否会导致只能处理少量的场景？

李也：Anthropic 最近有一份技术报告我觉得挺有参考价值的，它通过可视化展示了模型在微调前后的差异。结论是：微调通常不会显著削弱模型的通用能力。在相同模型规模下，微调后的模型与原始模型在通用任务上的表现差别不大。

以 Anthropic 的可视化结果为例，微调前后模型掌握的概念和推理深度变化很小，主要的差异体现在表达风格、思考方式以及特定领域知识的增强上。换句话说，“微调”中的“微”字非常准确，它强化的是特定方向的能力，而不会显著损伤模型的通用性。

张城：在 AI 的驱动下，3-5 年后，可观测性的理想图景会是什么样子？我们离真正的“自治运维”还有多远？

王亚普： 未来的可观测平台也许会从一个单纯的平台进化为一个“智能生命体”。从我们工程师的角度来看，它可能会帮助我们完成一些智能化的日常巡检。比如，我早上来到公司，打开电脑，看到的是系统自动生成的摘要报告：昨天系统运行平稳，预测某个服务将在下周的某天达到峰值容量，并已生成相应的容量计划。此外，它可能还会自动发现某个服务在某个版本上出现了 5 毫秒的性能劣化，并指出这可能与特定实验变更有关。这样的系统能让我们从被动监测转向具备预测性洞察的工作方式。

第二个设想是交互方式的变化。未来可观测系统的交互方式可能不再是传统的图表和数据界面，而更像是与一个经验丰富的同事进行对话。例如，你可以直接问：“昨天的故障为什么发生？”系统能给出原因分析，并进一步帮你检查是否存在类似风险。这种双向的自然交互让系统真正成为工作伙伴。

至于自治运维的前景，我认为核心在于“二八原则”：AI agent 可以解决 80% 的常规问题，实现从发现、诊断、决策到执行的闭环，而剩下 20% 的复杂问题仍然需要人类介入。三到五年内实现“半自治”的可观测系统是现实且可期的，它能处理大部分日常工作，并在部分成熟场景中实现全自动化。不过，仍面临诸多挑战，包括黑天鹅事件、信任、安全等问题。跨越这些鸿沟仍需时日，但整体方向是明确的，而且我们已经能看到变革在逐步发生。

李也： 未来，SRE 的大量工作会被自动化，SRE 的学习和成长曲线也会变得更快。比如，我们不再需要处理重复性很高的运维工作，可以把更多时间用于分析与决策。此外，全球范围内遇到的类似问题，也能被自动识别并提供解决方案。未来的 SRE 可能只需喝杯咖啡，在关键决策节点上确认执行即可。

董善东： 理想的可观测图景是：系统能够自动值守告警群。未来，即使是关键告警群，人也无需全天候盯着。尤其是在半夜，这种能力价值更大。夜间若发生告警，AI agent 可以自动处理大部分问题，早上只需查看一份夜间值守报告即可。即使 agent 无法完全处理，也能在通知人之前完成更多分析，把相关数据和结论整理好，从而大幅缩短排障时间。

再往远看，AI 的发展可能会重塑整个可观测体系。比如，未来主机侧或端侧的 AI 能实时判断数据的重要性，不必像现在一样每分钟都存一个数据点。如果系统稳定，采样频率可以降至每 5 分钟、10 分钟甚至 30 分钟；而一旦出现异常，采样频率又能自动升高。这种动态采集机制能显著降低存储成本，同时在问题发生时提供足够密集的数据支持。

三到五年内实现“半自治”运维是可行的，部分场景甚至能实现闭环自动化。但要达到完全自治、真正实现所谓“咖啡式运维”，仍有很长的路要走。