Databricks用AI加速事故调查

在我们的上一篇博客文章中，我们分享了 Databricks 如何使用 AI 调试数千个数据库。在这里，我们继续这个故事，探讨我们的工程师如何使用 AI 在跨越 1500 多个 Kubernetes 集群、覆盖 70 多个区域和三个云的 100 多个微服务上进行操作。

当凌晨 2 点发生故障时，值班工程师需要快速回答一个问题：发生了什么变化？

AI SRE 是一个由 AI 驱动的调试代理，一旦事件触发，它就会开始调查。它关联整个技术栈的信号，并引导工程师进行根本原因分析。

在这篇文章中，我们描述了塑造 AI SRE 的调试历程、其背后的架构，以及我们在事件期间使 LLM 驱动的系统值得信赖所遵循的工程原则。

AI SRE 之前：凌晨 2 点的体验

想象一下典型的寻呼机告警。一个面向客户的 API 出现延迟尖峰。工程师醒来并开始熟悉的流程：

• 检查跨仪表板和区域的服务指标。
• 搜索既相关又不寻常的错误日志。
• 检查部署、依赖项变更和功能标志更新。
• 检查云、网络和共享平台的健康状况。
• 查找并执行相应的运行手册。

这些工作流程中的每一个单独运行都很好，但调试工作流程，即将这些信号连接起来的动作，完全存在于工程师的脑海中。经验丰富的工程师可以在几分钟内完成，因为他们以前见过这种模式。新工程师可能会花费数小时，或者升级给其他人。

工具本身并不是主要问题。连接这些信号的负担落在了值班工程师身上，他们还要应对 SLA。

从客户出发，而不是从技术出发

我们不是从构建代理开始的。我们从观察人们调试开始。

在几周内，我们采访了数十个团队的值班工程师，以端到端地绘制他们的调试旅程。我们阅读了事后剖析和调查文档。我们问了一个简单的问题：你把时间花在哪里，你会在哪里卡住？

三个模式持续出现：

• 上下文组装消耗了大部分时间。 实际的“啊哈”时刻，即识别根本原因，通常在工程师面前有正确信号时是很快的。但是收集这些信号（正确的指标、正确的时间窗口、相关的部署、发生变化的上游依赖）消耗了调查时间的 60-80%。
• 知识分布不均匀。 每个团队都有几个专家，“他们就是知道”他们的系统如何失败。当这些专家不在时，调查速度会急剧减慢。运行手册经常过时或不完整，并且无法回答新的故障模式。
• 平台健康在问题发生之前是看不见的。 许多事件追溯到大规模基础设施问题，如云提供商或网络中断，或关键系统故障，如认证。但在应用层调试的工程师没有简单的方法来检查这些信号，因此他们会花时间追踪应用层假设，然后才发现问题出在较低的基础设施层。

一旦我们认识到调试是由一系列可重复的调查步骤和专家判断组成的序列，就变得清楚，AI 代理可以加速这项工作。但没有任何一个团队可以构建一个理解每个服务、信号和故障模式的代理。我们需要一个共享平台，处理常见的构建模块，如收集上下文、执行工具和运行手册、关联证据，同时允许团队用自己的运营知识进行扩展。问题从“我们能自动化调试吗？”转变为“我们如何为每个团队提供一个 AI 驱动的平台，以进行更快、更明智的诊断和解决？”

介绍 AI SRE

AI SRE 支持两种互补的体验：自动分类，在事件触发时开始，以及交互式调查，让值班工程师探索假设并请求额外的证据。

事件触发时的自动分类

当事件触发时，AI SRE 会在工程师打开笔记本电脑之前立即启动。它启动三个调查轨道并行进行，收集互补的证据以产生初始评估：

平台健康检查 评估服务运行的环境。

• 底层云基础设施是否健康？
• 相关区域是否存在持续的网络问题？
• 上游依赖（数据库、消息队列、共享服务）是否正在经历降级？

仅此一项就消除了大量干扰项，因此工程师不再需要花 30 分钟调试应用程序代码，然后才发现根本原因是大规模基础设施问题。

服务级分析 拉取受影响服务及其直接依赖的相关日志、指标和追踪。它检查最近的部署和配置更改。它识别相对于服务基线行为的异常，不仅是“CPU 高”，而是“CPU 在凌晨 2:47 飙升了 3 倍，恰逢一次部署更改了处理管道中的批处理大小”。

运行手册执行 是 AI SRE 采用特定于团队角色的地方。团队将他们的调试流程编码，例如领域专家会执行的检查、他们查找的阈值、他们采取的缓解步骤。团队可以使用技能将他们现有的运行手册转换为代理式运行手册。这些技能利用代码库、可观测性数据和过去的事件历史，使运行手册更准确且更具上下文感知能力。然后，它代表值班工程师执行这些步骤，执行领域专家会进行的相同调查，但只需几秒钟而不是几分钟。

当工程师第一次阅读事件详细信息时，AI SRE 已经组装了一份丰富的诊断摘要：这里是什么坏了，这里发生了什么变化，这里是你团队运行手册说要检查的内容，所有信号、关联和下一步都在一个视图中。

用于更深入调查的交互式调试

并非每次调查都以自动分类结束。有时根本原因很微妙，或者工程师想要探索一个假设。AI SRE 界面提供了一个交互式调试环境，工程师可以用自然语言提出后续问题，请求额外信号，并深入特定时间窗口或组件。

这就是结构化健康检查与对话式 AI 相结合的优势所在。工程师可能会问：“在警报触发前 10 分钟内，Kafka 消费者延迟有什么异常吗？”AI SRE 会获取相关指标，将其与事件时间线叠加，并解释其发现。

用于调试的分层架构

我们从客户访谈中得到的核心见解是，调试不是一个问题，而是一堆问题，解决它们需要有意的抽象。我们将 AI SRE 设计为一个分层平台，每一层都有明确的职责，而上层可以专注于越来越高级的关注点。

原语构成了基础：每次调查最终都依赖的原始操作数据。用于指标、警报、日志、发布信息和代码的原语已经存在，但在事件期间访问它们意味着要在五种不同查询语言的五种不同工具之间切换。原语层并不取代这些系统；它承认它们是事实来源。

该 API 层利用原语并提供对底层数据的受控、统一访问。我们没有让每个调试工具直接查询数据源（如日志或指标存储），而是构建了特定用途的 API：可观测性 API、部署 API 和警报 API，它们处理身份验证、速率限制和数据规范化。这一层将“原始基础设施”转变为“可调试基础设施”。这也意味着，当我们替换底层系统时，上面的调试工具不会中断。

该 核心引擎是智能所在之处。机器人框架提供了构建调试工作流的编排层，引擎处理并行执行、结果关联和 LLM 驱动的综合机制。这是我们第一方机器人运行所依赖的平台，但关键是，它也是每个想要构建自己机器人的团队都可以使用的相同平台。

该 应用层是实际进行调试的地方。这是我们平台级事件分类机器人运行的地方。第三方 AI 工具也可以在此插入，提供互补功能，而无需我们从头重新构建一切。

这种分离使我们能够独立改进数据访问和编排，同时支持集中维护的工作流和团队拥有的运行手册

在非确定性世界中构建可靠性

使 LLM 驱动的代理足够可靠以用于事件响应（其中信任至关重要）需要深思熟虑的工程。几个原则指导了我们：

先结构化检查，后开放式推理。 AI SRE 首先运行确定性平台健康检查和运行手册步骤。LLM 层综合并解释结果，但数据收集不依赖于模型的判断。

透明胜于黑盒答案。 AI SRE 呈现的每个结论都链接回底层证据：具体指标、日志行、部署差异。工程师可以验证推理，而不仅仅是相信它。这是不可协商的，因为值班工程师不会根据他们无法审计的建议采取行动。

优雅降级。 如果 AI SRE 无法自信地确定根本原因，它会明确说明，并呈现其收集到的证据，按相关性组织。一个诚实地说明其局限性的部分调查远比一个产生幻觉的诊断有用得多。

影响

AI SRE 现在支持 Databricks 内部的 150 多个团队，每周有 250 多名活跃用户每天运行超过 2,000 次调查，节省了数小时的调试时间。自发布以来，我们收到了积极的反馈：

“存储平台团队严重依赖 AI SRE 进行分类。它抢先于我的调查：在我甚至打开警报之前，代理已经关联了信号并产生了初步的根本原因分析。感谢团队构建了一个真正通用的调试平台，让多个团队能够将代理工作流融入日常工作中。”—— Gaurav Garg，资深员工工程师

“在 AI SRE 之前，事件的第一阶段是上下文组装：仪表板、时间窗口、全舰队过滤器。现在相关上下文汇集到一个地方，并且已经根据警报/事件进行了范围界定。我不必盲目相信代理的话。证据嵌入在调查中，一键点击即可打开底层工具，并已预先过滤，以便我自己验证。”—— Himanshu Mishra，高级工程师

“AI SRE 通过统一指标、日志和依赖健康状态，加速事件分类，更早地揭示根本原因，从而减少了全公司的平均恢复时间（MTTR），改变了事件响应。”—— Adama Kone，NOC 团队经理

最重要的成果不是取代工程师的判断。而是为他们提供了更快、有证据支持的调查起点。

我们学到的经验

从构建 AI SRE 中得到的三个启示：

让团队拥有自己的专业知识。 试图编码每个团队领域知识的集中式代理总是会过时和脆弱。通过将代理运行手册作为团队拥有和维护的可组合原语，我们将 AI SRE 变成了一个随着增长而变得更智能的平台，而无需平台成为瓶颈。

在优化模型之前构建上下文层。 我们在绘制工程师实际如何调查事件上花费的时间比提示工程更多。这种对问题的前期投入意味着我们构建了正确的东西，即一个组装上下文并执行已知检查的代理，而不是显而易见的东西，即一个连接到我们可观测性系统上的聊天机器人。

通过可追溯的证据赢得信任。 值班工程师在压力下工作，无法承受追逐虚假线索的代价。AI SRE 的每一条建议都有可追溯的证据支撑。这种透明度正是将持怀疑态度的早期采用者转变为日常用户的关键。

对于代理来说，护栏比对人更为重要。 让代理访问可观测性数据意味着重新设计我们的 API 层，而不仅仅是开放它。代理的查询方式与人类不同。它们会突发性地访问端点，并行执行检查，并且不会自行疲倦或退缩。我们必须构建护栏，以便代理能够快速工作，而不会破坏支撑关键业务警报和监控的基础设施。

下一步计划

AI SRE 当前专注于事件响应的调查阶段：理解发生了什么以及为什么发生。自然的下一步是扩展到引导式缓解——不仅诊断问题，还要帮助工程师安全地采取正确的纠正措施。

我们也在投资跨事件学习：利用过去事件的模式来改进未来的诊断，在问题被分页之前预警重复出现的问题，并帮助团队识别系统性的可靠性差距。

加入我们

展望未来，我们兴奋地继续推动 AI 在生产系统中的应用边界，让复杂的基础设施变得轻松易管理。如果你热衷于构建下一代基于 AI 的内部平台，欢迎加入我们！