Charity Majors，Honeycomb 的 CTO 和联合创始人 – 采访系列

Charity 是一名运维工程师和 Honeycomb 的意外创始人。在此之前，她曾在 Parse、Facebook 和 Linden Lab 工作，负责基础设施和开发工具，并总是最终负责管理数据库。她是 O’Reilly 的《数据库可靠性工程》一书的联合作者，并热爱自由言论、自由软件和单一麦芽威士忌。

您曾是 Facebook（现 Meta）的生产工程经理，任职超过 2 年。在此期间，您的亮点和主要收获是什么？

我曾在 Parse 工作，Parse 是一个为移动应用程序提供的后端，类似于 Heroku，但用于移动应用程序。我以前从未对在大公司工作感兴趣，但我们被 Facebook 收购。我的一个主要收获是，收购非常困难，即使在最好的情况下也是如此。我总是建议其他创始人，如果要被收购，必须有一个高管赞助商，并要认真思考是否有战略一致性。Facebook 在收购 Parse 之前不久收购了 Instagram，Instagram 的收购并非一帆风顺，但最终非常成功，因为他们有战略一致性和强大的赞助商。

我在 Facebook 的经历并不轻松，但我非常感激在那里度过的时光；我不知道如果没有在那里学到的关于组织结构、管理、战略等方面的经验，我是否能够创办一家公司。这也让我获得了一个让 VC 感兴趣的背景，在那之前，他们根本不愿意理我。我对此有点不满，但我还是会接受它。

您能否分享 Honeycomb 的创立故事？

当然。从架构角度来看，Parse 是一个超前的平台——我们在微服务成为流行概念之前就已经使用微服务了，我们有一个大规模的分片数据层，并且作为一个服务超过一百万个移动应用程序的平台，我们有很多非常复杂的多租户问题。我们的客户是开发人员，他们不断编写和上传任意代码片段和新查询，这些查询的质量……我们只能说“参差不齐”——我们必须接受所有这些，并且要让它们正常工作。

我们是很多变化的先驱，这些变化现在已经成为主流。以前，大多数架构都很简单，会以可预测的方式反复失败。您通常有一个 Web 层、一个应用程序和一个数据库，大部分复杂性都集中在应用程序代码中。因此，您会编写监控检查以监视这些失败，并为您的指标和监控数据构建静态仪表板。

在过去的 10 年里，这个行业经历了架构复杂性的爆炸式增长。我们已经打破了单体应用，现在您有从几到几千个应用程序微服务。多语言持久化已经成为常态；不再只有“数据库”，现在通常有多种存储类型，以及水平分片、缓存层、每个微服务的数据库、队列等。此外，您还有服务器端托管容器、第三方服务和平台、无服务器代码、块存储等。

过去，难点在于调试您的代码；现在，难点在于找到系统中需要调试的代码。与其反复以可预测的方式失败，不如说每次被叫醒时，都会遇到以前从未见过、可能以后也不会再见到的新问题。

这就是我们在 Parse 和 Facebook 的状态。每天，整个平台都会宕机，每次都是因为新的、不同的原因；一个不同的应用程序在 iTunes 上排名靠前，一个不同的开发人员上传了一个有问题的查询。

从头开始调试这些问题非常困难。使用日志和指标，您基本上必须知道自己在寻找什么，才能找到它。但是我们开始将一些数据集输入到一个名为 Scuba 的 Facebook 工具中，该工具允许我们在任意维度和高基数数据上实时切片和切块，我们从头开始识别和解决这些问题所需的时间大大减少了，从几小时到……几分钟？几秒钟？这不再是一个工程问题，而是一个支持问题。你可以每次都跟随面包屑的痕迹找到答案，轻松点击即可。

这真是令人惊讶。这种不确定性、辛苦劳动、不满意的客户和凌晨 2 点被叫醒的巨大来源……消失了。直到 Christine 和我离开 Facebook，我们才意识到它已经改变了我们与软件的交互方式。回到旧的监控检查和仪表板的日子简直不可想象。

但当时，我们真的认为这将是一个小众解决方案——它解决了其他大型多租户平台可能存在的问题。直到我们建设了几乎一年，我们才开始意识到，哇，这实际上正在成为一个每个人都面临的问题。

对于不熟悉的人，您能解释一下什么是可观察性平台，以及它与传统的监控和指标如何不同吗？

传统监控著名的三大支柱：指标、日志和跟踪。您通常需要购买许多工具来满足您的需求：日志记录、跟踪、APM、RUM、仪表板、可视化等。每一个都针对不同格式的不同用例进行了优化。作为一名工程师，您处于这些工具的中间，试图理解所有这些工具。

现代可观察性有一个单一的真相来源；任意宽的结构化日志事件。从这些事件中，您可以推导出您的指标、仪表板和日志。您可以随时间将它们可视化为跟踪记录，您可以切片和切块，您可以放大到单个请求，也可以缩小到长期视图。因为一切都相互关联，您不需要在工具之间跳转，依靠猜测或直觉。现代可观察性不仅仅是关于如何运营您的系统，也是关于如何开发您的代码。它是允许您建立强大的、紧密的反馈循环的基础，这些循环帮助您快速、自信地向用户交付价值，并在用户之前发现问题。

您以认为可观察性在工程环境中提供单一真相来源而闻名。AI 如何融入这一愿景，以及在此背景下其带来的益处和挑战是什么？

可观察性就像在你疾驰而去之前戴上眼镜。测试驱动开发（TDD）在 2000 年初革命了软件开发，但 TDD 随着复杂性从软件转移到系统的程度而变得不那么有效。越来越多地，如果你想获得与 TDD 相关的好处，你实际上需要将代码进行可观察性驱动的开发（ODD），即边开发边添加工具，快速部署，然后通过刚刚编写的工具来查看代码在生产中的运行情况，并问自己：“它是否按预期工作？是否有其他……奇怪的地方？”

仅仅依靠测试是不够的，您无法确定代码是否按预期工作，直到您在生产环境中用真实用户和真实基础设施测试过它。

这种开发方式——包括快速的生产反馈循环——比依赖测试和较慢的部署周期更快、更简单、更容易。开发人员一旦尝试过这种方式，就不愿意回到老方式。

我对 AI 的兴奋之处在于，当您使用大型语言模型（LLM）进行开发时，您必须在生产环境中开发。您唯一的方法是先在生产环境中验证代码，然后反向推导出一组测试。我认为，支持 LLM 的软件开发将会像支持 MySQL 或 Postgres 一样成为一种常见技能，我希望这会把工程师们拖入一个更好的生活方式中。

您提到了由于 AI 革命而积累的技术债务。您能否详细说明 AI 可能引入的技术债务类型，以及 Honeycomb 如何帮助管理或减轻这些债务？

我担心的是技术债务和组织债务。技术债务中最糟糕的就是没有人真正理解的软件。这意味着任何时候您需要扩展或更改代码，或者调试或修复它，某个人都必须做艰难的工作来学习它。

如果您将没有人理解的代码部署到生产环境中，那么很可能它不是为了可理解性而编写的。好的代码是为易读、易理解和易扩展而编写的。它使用约定和模式，使用一致的命名和模块化，并在 DRY 和其他考虑因素之间取得平衡。代码的质量与人们与之交互的难易程度密切相关。如果您只是因为代码可以编译或通过测试而将其部署到生产环境中，那么您就为自己创造了大量未来的技术问题。

如果您决定部署没有人理解的代码，Honeycomb 无法帮助您。但是，如果您关心部署干净、可迭代的软件，工具化和可观察性对于这一努力至关重要。工具化就像文档加上实时状态报告。工具化是您唯一可以真正确认软件是否按预期工作和行为的方式。

Honeycomb 如何利用 AI 来提高工程团队的效率和有效性？

我们的工程师在内部大量使用 AI，特别是 CoPilot。我们的初级工程师每天都使用 ChatGPT 来回答问题和帮助他们理解正在构建的软件。我们的高级工程师说它非常适合生成编写起来很枯燥或很烦人的代码，例如当您有一个很大的 YAML 文件需要填写时。它也适合生成您不常用的语言或从 API 文档中生成代码片段。例如，您可以使用 AWS SDK 和 API 生成非常好的、可用的代码示例，因为它是在训练有真实使用此代码的存储库的数据上进行的。

但是，每当您让 AI 生成代码时，您都必须逐行检查代码，以确保它做的是正确的事情，因为它绝对会胡言乱语。

您能否提供 AI 功能（如查询助手或 Slack 集成）如何增强团队协作的示例？

是的，当然。我们的查询助手是一个很好的例子。使用查询构建器很复杂，很难使用，即使对于强大的用户来说也是如此。如果您有成百上千个维度的遥测数据，您不可能记住最有价值的维度的名称。即使对于强大的用户来说，生成某些类型的图表的细节也是很容易忘记的。

因此，我们的查询助手允许您使用自然语言提问。例如，“最慢的端点是什么？”或“我的最后一次部署后发生了什么？”它会生成一个查询并将您放入其中。大多数人发现从头开始构建一个新查询很困难，但修改一个现有的查询很容易。它让您领先一步。

Honeycomb 承诺更快地解决事件。您能否描述一下将日志、指标和跟踪记录集成到统一数据类型中如何有助于更快地调试和解决问题？

一切都是相互关联的。你不需要猜测。与其依靠仪表板的形状或依靠时间戳来猜测指标和日志中的峰值……不如说，数据是相互关联的。你不需要猜测，你可以直接问。

数据的价值来自其上下文。上一代工具的工作原理是，在写入时丢弃所有上下文；一旦丢弃上下文，就无法再恢复。

此外，使用日志和指标，您必须知道自己在寻找什么，才能找到它。这并不适用于现代可观察性。您不需要知道任何东西，也不需要搜索任何东西。

当您存储这种丰富的上下文数据时，您可以对其执行感觉像魔术的事情。我们有一个名为 BubbleUp 的工具，您可以在任何您认为奇怪或可能有趣的内容周围绘制一个气泡，我们计算气泡内外的所有维度、基线、排序和差异。所以您就像“这个气泡很奇怪”，我们会立即告诉您，“它在 xyz 方面有所不同”。调试的很大一部分就是“这里有我关心的事情，但我为什么关心它？”当您可以立即确定它之所以不同，是因为这些请求来自 Android 设备，使用此构建 ID，使用此语言包，在此区域，使用此应用程序 ID，具有大型有效负载……到现在您可能已经知道到底出了什么问题以及为什么。

这不仅仅是关于统一数据，尽管这确实是一个巨大的部分。这也是关于我们如何毫不费力地处理高基数数据，例如唯一 ID、购物车 ID、应用程序 ID、名字、姓氏等。上一代工具无法处理这样的丰富数据，这几乎是不可思议的，因为丰富的高基数数据是最有价值和最具识别性的数据。

提高可观察性如何转化为更好的业务成果？

这是过去一代和新一代可观察性工具之间的另一个巨大变化。在过去，系统、应用程序和业务数据都被分离到不同的工具中。这是荒谬的——您想要问的每个有趣问题都涉及这三者的元素。

可观察性不仅仅是关于 bug、停机或宕机。它是关于确保我们正在处理正确的事情，我们的用户拥有良好的体验，我们正在实现我们想要的业务成果。它是关于建立价值，而不仅仅是运营。 如果您看不到前方的方向，您就无法快速移动，也无法快速更正航向。您对用户正在使用您的代码做什么有多少可见性，就能成为多好的工程师，并且移动得多快。

您如何看待可观察性的未来，特别是考虑到 AI 的发展？

可观察性越来越多地是关于使团队能够建立紧密、快速的反馈循环，以便他们能够快速、自信地在生产环境中开发，并且浪费更少的时间和精力。

这就是连接业务成果和技术方法之间的点。

以及确保我们理解我们发布到世界上的软件。随着软件和系统变得越来越复杂，尤其是随着 AI 的日益融入，保持人类的理解和可管理性标准比以往任何时候都更加重要。

从可观察性的角度来看，我们将看到数据管道中日益复杂的技术——使用机器学习和复杂的采样技术来平衡价值与成本，以便在可能的情况下保留有关异常事件和重要事件的尽可能多的详细信息，并以最低的成本存储其余事件的摘要。

AI 厂商正在对其能够比您更好地理解您的软件或处理数据并告诉人类采取什么操作的能力做出很多夸张的声明。从我所见的一切来看，这是一个昂贵的幻想。假阳性代价非常高。没有什么可以取代对系统和数据的理解。AI 可以帮助您的工程师做到这一点！但它无法替代您的工程师。

感谢这次精彩的采访，希望了解更多的读者可以访问 Honeycomb。