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

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

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

我曾在 Parse 工作，Parse 是一个为移动应用程序提供后端服务的平台，类似于 Heroku。我从未想过在大公司工作，但我们被 Facebook 收购。我的一个关键收获是，收购非常困难，即使在最好的情况下。我的建议是，如果您要被收购，请确保您有一个高管赞助商，并认真思考您是否具有战略协同性。Facebook 在收购 Parse 之前不久收购了 Instagram，Instagram 的收购并不顺利，但最终非常成功，因为他们具有战略协同性和强大的赞助商。

我在 Facebook 的经历并不容易，但我非常感激在那里度过的时间；我不知道如果没有在那里学到的关于组织结构、管理、策略等方面的经验，我是否能够创办一家公司。它还给我带来了一个让我在风险投资者眼中具有吸引力的背景；在那之前，风险投资者从未给我过多的关注。我对此有点不满，但我仍然会接受它。

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

当然。在架构方面，Parse 是一个领先于时代的平台——我们在微服务成为热门概念之前就已经使用了微服务，我们有一个大规模的分片数据层，并且作为一个为超过一百万个移动应用程序提供服务的平台，我们有很多复杂的多租户问题。我们的客户是开发人员，他们不断地编写和上传任意代码片段和新查询，质量参差不齐——我们必须接受所有这些，并让它们正常工作。

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

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

过去，代码调试是最难的部分；现在，难点在于找到需要调试的代码。过去，系统会以可预测的方式反复失败；现在，每次您被叫醒时，都是因为您从未见过的事情，也可能再也不会见到。

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

从头开始调试这些问题非常困难。使用日志和指标，您基本上必须知道您要寻找什么才能找到它。但是当我们开始将一些数据集输入 Facebook 的一个工具 Scuba 时，Scuba 允许我们在任意维度和高基数数据上实时切片和切块，我们识别和解决这些问题所需的时间从几个小时减少到几分钟甚至几秒钟。它不再是一个工程问题，而是一个支持问题。您可以每次都通过点击点击点击来找到答案。

这令人惊讶。这种巨大的不确定性和辛苦劳动的来源、不满意的客户和凌晨 2 点的电话突然消失了。直到 Christine 和我离开 Facebook，我才意识到它如何改变了我们与软件的交互方式。回到旧日子里使用监控检查和仪表板的想法是不可想象的。

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

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

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

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

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

可观察性就像在您疾驰而去之前戴上眼镜。测试驱动开发（TDD）在 2000 年代初期彻底改变了软件开发，但 TDD 随着复杂性从软件转移到系统而变得不那么有效。越来越多地，如果您想获得与 TDD 相关的好处，您实际上需要使用类似于可观察性驱动开发（ODD）的东西，在 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 的工具，您可以在任何您认为奇怪或可能有趣的东西周围画一个气泡，我们会计算气泡内外的所有维度、基线并对其进行排序和差异化。所以您会说“这个气泡很奇怪”，我们会立即告诉您，“它与以下方式不同”。调试的很大一部分就是“这里有我关心的事情，但我为什么关心它？”当您可以立即确定它之所以不同是因为这些请求来自 Android 设备，具有此构建 ID，使用此语言包，在此区域，具有此应用程序 ID，具有大有效负载… 到那时，您可能已经知道到底出了什么问题以及为什么。

这不仅仅是关于统一的数据——尽管这也是一个巨大的部分。它还关于我们如何轻松处理高基数数据，例如唯一 ID、购物车 ID、应用程序 ID、姓氏、名字等。上一代工具无法处理这样的丰富数据，这几乎令人难以置信，因为丰富的高基数数据是最有价值和最具识别性的数据。

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

这是从上一代到新一代可观察性工具的另一个重大转变。在过去，系统、应用程序和业务数据都被隔离在不同的工具中。这是荒谬的——您想问现代系统的每个有趣问题都涉及所有三个方面。

可观察性不仅仅是关于错误、停机或中断。它是关于确保我们正在做正确的事情，我们的用户正在拥有良好的体验，我们正在实现我们想要的业务成果。它是关于建立价值，而不仅仅是运营。 如果您看不到前方的方向，您就无法快速移动，也无法快速更正航向。您对用户正在做什么以及如何使用您的代码的可见性越多，您就越能成为一名更好的、更强大的工程师。

您如何看待可观察性的未来，特别是与 AI 开发相关的方面？

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

它是关于连接业务成果和技术方法之间的点。

同时，也是关于确保我们理解我们向世界投入的软件。随着软件和系统变得越来越复杂，尤其是随着 AI 的日益融入，确保我们以人类的标准来理解和管理软件变得比以往任何时候都更加重要。

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

AI 厂商正在对他们能够比您更好地理解您的软件以及如何处理数据并告诉您的团队采取什么行动做出很多夸张的声明。根据我所见，这是一个昂贵的白日梦。错误的警报代价非常高。没有替代品可以取代您对系统和数据的理解。AI 可以帮助您的工程师做到这一点！但它无法取代您的工程师。

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