每个不断增长的工程组织最终都会发现同样的问题。当生产环境中出现问题时，工程师调试它。当它再次发生时，他们再次调试。数百个团队，数千个事件，每个事件几乎都从头开始调查。

经验丰富的工程师知道在哪里查找和检查什么模式，但这些知识存在于他们的头脑中，而不是系统中。随着时间的推移，运行手册变得过时，一个人编写的脚本成为部落知识。

Meta 多年前就遇到了这个瓶颈。他们的答案是 DrP，一个让工程师将调查专业知识转化为实际代码的平台。它是一个自动运行的软件组件，通过代码审查进行测试，并随时间改进。它现在在 300 个团队中运行，每天执行 50,000 次自动分析。

虽然 Meta 的具体工具很有趣，但更深刻的是底层原则：调试本身可以被工程化。在这篇文章中，我们将看看 DrP 如何在高层工作，以及 Meta 在构建它时做出的设计选择。

免责声明：这篇文章基于 Meta 工程团队公开分享的细节。如果你发现任何不准确之处，请评论。

为什么手动调查会崩溃

大多数团队调查事件的方式有一个可预测的失败模式，编写更好的文档并不能修复它。

知识被困在人脑中。你最好的调试员携带着别人没有的心智模型，比如哪些服务不稳定、哪些指标实际上很重要、哪些仪表板在特定条件下会说谎。当那个人睡觉、度假或离开公司时，知识就消失了。如果你曾经在凌晨 2 点被呼叫并希望上次发生时已经有人搞清楚了，你就感受过这个问题。

系统频繁变化，有时一天数十次。上个月准确的运行手册现在引用了一个已重命名的仪表板和一个已重构的服务。现代软件变化太快，静态文档无法跟上。

团队经常编写一次性脚本来自动化自己的检查，这是好事。但这些脚本不能跨越服务边界。它们也没有经过系统测试。最终，它们成为自己形式的部落知识，对作者有用，对其他人不透明。

这些问题并非 Meta 独有。每个达到一定规模的组织都会遇到同样的瓶颈。行业以不同方式处理它。一些公司专注于在事件期间更好地协调人员（Netflix 为此构建并开源了 Dispatch），另一些专注于自动化调查本身（Meta 的方法），还有一些倾向于 AI 驱动的 diagnostics。

事件响应至少有三个不同的层次：

  • 协调（让合适的人聚在一起）
  • 调查（找出什么问题）
  • 修复（修复它）

Meta 在调查层投资最深，他们的方法值得研究，因为它已经在大规模生产中运行了五年多。

你也可以将其视为从部落知识到 wiki 运行手册到临时脚本到可测试分析器到可组合平台的成熟度进展。大多数团队卡在第二步或第三步左右，而 DrP 代表第五步。

将调查视为软件

DrP 的核心理念是调查工作流应该写为代码，经过代码审查，有 CI/CD，并像团队发布的任何其他软件一样进行测试。

核心单元是”分析器”（analyzer），一个程序化调查工作流。工程师使用 DrP 的 SDK 将他们的调试步骤编码化，比如拉取哪些数据、查找哪些异常，以及遵循哪些决策树。输出是结构化发现（人类可读和机器可读），而不仅仅是某人可能浏览的 wiki 页面。

与”只是编写脚本”不同的是周围的工程严谨性。

分析器经过代码审查。它们有自动回溯测试集成到审查过程中，所以你可以在部署之前验证分析器会捕获上个月的事件。它们通过 CI/CD 流程发布。当底层系统变化时，分析器通过与任何其他代码相同的开发工作流更新。

SDK 还为常见调查模式提供共享库，比如异常检测（在指标中发现不寻常行为）、时间序列相关性（检查指标峰值是否与部署或配置变化一致），以及维度分析（通过区域、设备类型或其他属性自动切片指标以隔离问题集中在哪里）。工程师不需要为每个分析器从头重新发明这些。

心智转变与技术一样重要。DrP 有用户（值班工程师）、平台团队、部署管道和使用指标。它持续维护和改进，而不是在初始作者转团队后被放弃。

平台超越脚本的地方

将分析器写为代码是基础。但真正的杠杆来自于连接它们时会发生什么。

在微服务架构中，根本原因很少在显示症状的服务中。你的 API 错误率飙升，但实际原因可能是三层下面的存储服务的配置变化。使用独立脚本，每个团队只能调查自己的域。使用 DrP，分析器可以跨服务边界链接。API 分析器发现问题在下游，调用存储服务分析器，传递它已经收集的上下文，并取回确认的根本原因。这自动发生，无需任何人 ping Slack 频道。

DrP 还直接集成到警报生命周期中。分析器在警报触发时自动触发。结果注释警报本身，所以值班工程师在看到警报时看到诊断，在他们打开任何仪表板之前。

调查之后，后处理系统可以闭环：创建回滚任务、提交 bug，或触发缓解步骤。还有更广泛的反馈循环。

DrP Insights 定期分析所有调查的输出，以识别和排名整个组织中最常见的警报原因。单个调查成为组织学习。

调查：从开始到结束

为了让这具体化，这是 DrP 驱动的调查在实际中看起来如何。这是一个基于 DrP 记录能力的可能场景，而不是特定的 Meta 事件。

假设 API 服务的错误率飙升。警报触发并自动触发相关分析器。从那里，调查在一系列自动步骤中展开：

  • 分析器拉取错误率数据并运行维度分析，按区域、设备类型和数据中心切片。它将问题隔离到一个区域
  • 它运行时间序列相关性，将错误峰值与其他信号（如延迟、部署事件和配置变化）进行比较。它发现与下游存储服务的最近配置变化强烈匹配
  • 由于存储服务是单独的依赖，分析器链接到存储服务分析器，传递区域上下文。该分析器确认配置变化将响应延迟推到 API 的超时阈值之外
  • 发现作为结构化摘要呈现给值班工程师：受影响区域、根本原因、相关时间戳，以及指向违规更改的链接
  • 后处理系统创建分配给存储团队的回滚任务
  • 工程师审查分析，批准回滚，事件解决。可能需要 45 分钟跨多个工具和团队的手动工作的调查在工程师读完警报之前在后台发生

结论

DrP 在 Meta 团队中将事件平均解决时间减少了 20-80%，生产中有超过 2,000 个分析器。这些数字引人注目，但持久的收获不是关于特定公司的特定工具。

调查知识太有价值了，不能存在于人的头脑中或过时的文档中。它可以被编码为可测试、可组合的软件。

然而，这并不消除对人类判断的需求。DrP 故意让工程师保持在循环中，呈现发现以供审查，而不是自动修复。它也不是免费的；分析器是代码，代码需要维护。你用不可预测的值班劳累交换更可管理的工程工作。但无论你在哪里工作，这个问题值得问：你团队的调试知识是被工程化到你的系统中，还是等待走出门外？

参考

本文为学习目的的个人翻译，译文仅供参考。

原文链接：How Meta Turned Debugging Into a Product。

版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。