眼下可观测性领域有个挺有意思的现象：各家厂商不约而同都在押注同一个方向——融合。

一个SRE袋里，嵌入一个平台，围绕着某一套厂商对故障调查的既定理解来训练。它理解你的遥测数据，解答你的问题，解释故障原因，最终在有人打开仪表盘之前就帮你修复生产环境。

这种未来图景当然有用，但未免有些狭隘。可观测性不是那种标准化的客服工单系统。调试工作高度依赖团队所维护的系统特性、故障模式、可信赖的数据源、作战手册、常用工具，以及多年积累下来的运维经验。数据库团队、前端团队、支付团队和基础设施团队，排查生产问题的方式截然不同。

在这篇文章中，我们来探讨一个观点：可观测性的未来，不会是某个厂商的专有AI袋里，而是由千千万万个像你这样的团队亲手构建的袋里。

AI袋里正在成为可观测性的新界面

可以预见的是，AI袋里在可观测性领域的崛起，早已不是什么大胆的预测了。

如今，大多数故障排查仍然始于工程师打开仪表盘、搜索日志、检查追踪、手动拼凑上下文。而越来越多的工作正在被袋里所取代。模型已经能够查询遥测数据、总结发现、识别模式，并对系统内部正在发生的事情生成合理的假设。

随着模型能力的持续提升，可观测性的交互界面将逐渐从“人→仪表盘→数据”演变为“人→袋里→数据”。工程师仍然负责决定采取什么行动，但调查过程中大量的机械性工作，将在他们触碰图表或编写查询语句之前就已经完成。

“我们在Slack故障频道里观察到明显的趋势变化。以前工程师们习惯分享日志或指标的链接，现在大家开始分享AI调查的摘要并深入讨论。”

—— DoorDash, Anil K.

AI正在重塑可观测性工作负载的形态

关于可观测性袋里的讨论，大多集中在它们能做什么，而很少关注当它们成为日常工作流程的一部分后，底层会发生什么变化。

人工调查员的能力是相对有限的。他们打开几个仪表盘，运行几条查询，检查一两个追踪，然后逐步缩小排查范围。即使是经验丰富的工程师，一次也只能评估有限的可能性。

而袋里没有这种限制。工程师可能对比两个时间窗口，袋里却能对比二十个。人类可能手动排查几个可能的根因，袋里却能同时追踪数十个假设，持续收集证据并排除死胡同。

一个实际后果是：调查的广度将大幅提升，对底层系统也提出了更高要求。袋里可以审查更多的历史数据，并在收敛到答案之前探索远超人工的潜在解释。这直接导致需要更多低延迟响应的查询。

“袋里可能会采取暴力手段——做10次查询，而不是像人类那样只点两下仪表盘。这意味着我们的API层或存储层必须足够健壮，来承担这种非线性的查询模式。”

—— DoorDash, Anil K.

这也改变了底层数据的要求。袋里只能基于它被赋予的上下文进行推理。如果历史数据被丢弃，重要上下文就会缺失；如果遥测数据被大量采样，关键证据可能根本不存在于数据集中。与经验丰富的工程师不同，袋里无法凭借直觉或机构知识来弥补这些空白。它们的结论完全受限于可用数据的完整性和保真度。

大多数可观测性平台都是围绕人类调查员及其产生的工作负载来设计的。下一代平台需要支持的是以人类名义进行的调查。

行业正押注于伟大的SRE袋里

许多公司正在投资构建一个简单的未来愿景：通用的SRE袋里。

这个想法确实很有吸引力。可观测性厂商提供平台、数据和袋里。工程师通过自然语言提问，无需学习仪表盘、编写查询或浏览遥测数据。随着时间的推移，袋里能力不断增强，最终能够独立处理大部分调查工作。

这种模式有其真实价值。大多数可观测性工具仍然难以使用，而袋里有潜力大幅降低理解与运维复杂系统的门槛。

模型也会持续进步，推理能力会更强，编写SQL的能力会更好，并且能将常见的调查模式封装成可复用的工作流。今天许多被视为专家知识的东西，将越来越容易通过袋里来获取。

调试的难点：上下文

问题在于，调试过程并不像软件厂商希望的那样简单收敛。

模型在进步，但真正困难的仍然是上下文。

调查的下一步走向，远不止取决于可观测性平台内部存储的遥测数据。它取决于团队如何运作、信任哪些信号、过去发生过什么故障、所有权如何划分、运维知识存放在哪里。大量上下文散落在作战手册、工单、事后分析、Slack线程、内部文档、部署系统，以及资深工程师的脑海中。

“Ring Central是一家成立25年的公司。运维团队内部有大量未记录在案的默契知识，即便我们连接了所有Wiki。如果你没有数据给它，它就会产生幻觉。”

—— RingCentral AI负责人, Sushant Hiray

每个团队的工作方式都不同

更进一步说，即使是运行着相似技术栈的两家公司，调查同一个故障的方式也可能完全不同，因为它们的系统、团队和运维历史各不相同。厂商可以打包最佳实践，但无法打包每一个使用其产品的工程团队的累积经验。

调试生产系统所需的大量上下文，存在于可观测性平台之外。它散落在手册、工单、事后分析、内部文档、Slack线程、部署系统，以及多年运维该系统的工程师的机构知识中。这些知识的存放位置、团队的结构以及遵循的流程，不仅在不同组织之间千差万别，甚至在同一个组织内部的不同职能领域也各不相同。

这些方法没有绝对的对错。它们只是不同团队基于自身经验形成的不同心智模型。团队信任的信号、遵循的工作流、依赖的上下文，往往都是针对其运维的系统独一无二的。

走向更开放的袋里可观测性模型

综合来看，这些挑战指向了一个与许多厂商押注截然不同的未来。

当袋里成为可观测性的主要界面，而调查越来越受组织上下文影响时，价值中心将从单一通用袋里，转向为特定团队和领域构建的专用袋里。

“我们没有从一开始就追求一个超级精巧的架构，而是加倍投入构建一个无头平台——改进我们的API、数据存储，并构建一个可观测性MCP，这样就能让每个工程师或每个团队都能构建自己的袋里工作流，更贴合他们的调试用例。”

—— DoorDash, Anil K.

我们相信，可观测性更有可能演变成一个由专业化袋里组成的生态系统，每个袋里都针对特定的组织、团队或问题领域进行了优化，而不是汇聚成一个单一的SRE袋里。有些专注于基础设施，有些专注于数据库、安全、支付、客户体验或内部平台。许多袋里将围绕组织自身的作战手册、文档、工作流、业务逻辑和运维知识来构建。

同样重要的是，这种未来依赖于开放性。

这里所说的“开放”，不仅仅指开源软件。它意味着给予团队和工程师在技术栈的每一层选择最佳技术的自由：模型、框架、工具、工作流、界面。它意味着能够围绕组织内已有的系统和流程来构建袋里，而不是让这些流程去适应厂商对可观测性的既定看法。

这也意味着拥有选择袋里之下各层的自由。团队应该能够控制数据存放的位置，技能如何开发和维护，哪些MCP网关和服务器位于生产系统之前，以及袋里的行为如何被观察、治理并集成到整个工程环境中。

“我们更倾向于与那些能给我们足够灵活性的平台合作，让我们有机会在其之上进行构建。只要它能与我们足够多的内部工具协同工作，那就是最佳契合点。”

—— RingCentral AI负责人, Sushant Hiray

最成功的可观测性平台，不会是那些强迫所有人采用单一工作方式的平台。它们将是提供共享基础，并允许在其上构建成千上万个不同袋里的平台。

袋里需要共享上下文

如果每个团队甚至每个工程师都构建和调整自己的袋里，那么调查就不会在同一个地方进行。一个工程师可能从IDE开始，另一个从笔记本开始，另一个从内部聊天界面开始，还有一个通过自定义故障工作流开始。袋里可能在不同的框架中运行，使用不同的模型，遵循不同的调查路径，即使它们都在试图理解同一个生产问题。

这就带来一个协作问题。调查输出不能被困在瞬时的聊天会话或私有的袋里追踪中。团队需要持久、可审查的工件，清楚地显示查询了什么、发现了什么证据、探索了哪些假设、以及为什么得出结论。这对人类审查故障很重要，对未来的袋里也同样重要——它们需要从之前的调查中学习，而不是每次都从头开始。

因此，袋里可观测性需要某种形式的持久化调查表面，让人类和袋里能够协同工作。一个可以共享、审查、重新运行、改进和长期积累的调查空间。调查始于IDE、笔记本、聊天界面还是自定义工作流，最终并不重要，重要的是有一个共同的地方，让结果能够被保存和复用。

这些调查工件不仅仅是事件的记录。它们会成长为一个不断扩充的运维知识库，当未来出现类似问题时，工程师和未来的袋里都可以从中汲取经验。

人类仍将是控制平面

所有这些都基于一个假设：至少在目前，人类仍然处于控制平面。

袋里可以收集证据、执行调查、探索假设、呈现相关上下文，速度远超任何单个工程师。但它们仍然缺乏理解业务优先级、权衡竞争风险、处理模糊性，并最终决定采取什么行动所需的判断力。这些决策仍然是运维系统的人的责任。

也许随着时间的推移，这种情况会改变。不难想象，未来专用袋里会相互协作，持续监控系统，并在无人干预的情况下自主解决一类故障。但那不是我们今天正在构建的未来。

今天，更实用、更有效的模式是协作。袋里加速调查，人类提供方向。袋里收集上下文，人类做出决策。笔记本成为这些交互发生的共享工作空间，创建可审查、可分享、可改进和可复用的持久记录。

无论未来最终是完全自主，还是永远保持人类引导，有一点似乎越来越清晰：可观测性的未来，不会是躲在某个单一厂商界面后面的专有AI袋里。

它将是成千上万由你亲手构建的袋里。