与 Maude Lemaire 聊 Slack 和 GitHub 的规模化

现在可在 YouTube、Apple 和 Spotify 上收听和观看。本页顶部可查看本期节目文字稿，底部可查看本期节目时间戳。

本期赞助商

• turbopuffer – tpuf 工程团队正在从第一性原理出发，彻底重新设计他们的存储架构。而且他们把整个过程都记录了下来！他们取得了重大进展；来看看吧：turbopuffer.com/v3

• Antithesis – 使用 AI 智能体处理关键系统，而无需担心正确性问题。Antithesis 会在敌对环境中运行你的完整系统，分析其行为，并完美复现每一个问题。了解更多

• Entire – Entire 推出了自己的 Git forge，发布了 Continuous Memory，并重新发明了拉取请求（称为 Trails）。当智能体在根据反馈迭代后不断推送新更改时，Trails 是一种自然得多的工作流——而且你能更好地掌握上下文，并控制更改何时可以合并。来看看吧

为智能体开发重新构想的拉取请求概念：Entire 将其称为“Trails”

本期内容

在 Slack 和 GitHub 这样的公司，扩展大型热门产品都涉及哪些工作？

我们从 Maude Lemaire 那里获得了内部视角。她是一名首席工程师，也是《大规模重构：重新掌控你的代码库》一书的作者。她在 Slack 工作了近八年，领导后端性能基础设施团队，之后加入 GitHub 应对数据库扩展挑战。最近，她致力于提升 Cursor 的性能——包括首 token 时间。

在The Pragmatic Engineer 的本期节目中，Maude 和我深入探讨了扩展世界上一些最大软件产品所面临的挑战。我们探究了 Slack 如何应对不断增长的企业客户数量、它如何演进其负载测试方法，以及 Maude 在近八年扩展 Slack 基础设施期间学到的经验。

她还向我们讲述了 2024 年 Copilot 蓬勃发展时加入 GitHub 的感受、应对 GitHub 庞大 Rails 单体架构的挑战，以及 Maude 如何在工作中使用 AI——同时将判断和决策牢牢掌握在自己手中。

与 Maude 对话的要点

以下是我们讨论中的八个有趣观点：

1. 即使没有竞争，性能也应该很重要。2015 年，Rent the Runway 的首页由于网站上有一张高分辨率的头图，完整加载最多需要 10 秒。有人告诉 Maude 这不是问题，因为不用担心有竞争对手。她却不这么认为：“最好的竞争是与自己竞争，知道自己可以做得更好，知道自己可以带来更好的体验，”她说。Maude 利用一些空闲时间加快了网站速度，并没有为此请求许可，因为这是正确的决定。

2. Slack 将自定义表情符号限制为 23 个，以避免惊群效应。这里有一个惊群效应的例子：一个拥有 10 万成员的 Slack 频道的 CEO 发帖说“大家周五放假！”作为回应，人们开始发布自定义表情符号——成百上千个。问题在于，每一个自定义表情符号都必须分发给全部 10 万用户。10 个自定义表情符号就是 100 万次分发，100 个就是 1000 万次；网络负载很大！Slack 将自定义表情符号限制为 23 个以避免这个问题。实际上，缺失的第 24 个自定义表情符号并不会让人感到遗憾。

3. 事件洪流可能会拖垮 Slack 重度用户的机器。事件洪流是惊群效应的近亲：当单个客户端被通过其自身 WebSocket 传来的事件淹没时，就会发生这种情况。例如，当一名 IT 工作人员登录了许多繁忙的频道，而这些频道都收到了“大家周五放假！”的消息——以及所有相关的自定义表情符号和消息。这位“重度用户”会突然收到大量消息，且没有去重，于是他们难以应对。

4. 用简单方式对 50 万个 WebSocket 连接进行负载测试，每次运行将花费 15 万美元。一位拥有 50 万用户的新客户即将注册 Slack，Maude 需要运行负载测试来确认服务能否承受该负载。起初，她计划启动无头 Chrome 实例——每个实例运行一个 Slack 会话，而每个实例每五小时会话将花费 0.37 美元。总价会高得离谱。于是，Maude 构建了一个名为 Koi Pond 的工具，它会启动 Slack 的精简版本（“Koi”），用 Go 编写以建立 WebSocket 连接。

5. Active Record 的缺点：数据库负载过高！GitHub 曾经是一个 Ruby on Rails 单体应用，使用 Active Record 作为数据库抽象层。这造成了意外的负载：GitHub 的首页在大多数重新加载时都会从数据库获取实时数据，而加载首页通常会触发跨三个数据库集群的 100 次 SQL 查询。这向 Maude 揭示了像 Active Record 这类抽象的一个缺点：当开发者使用它时，他们不知道也不关心在为手头工作获取数据时无意中给数据库增加的额外负载。

6. 由于分散查询问题，GitHub 无法增加超过 16 个数据库分片。分散查询是指没有主键（分片键）的查询，它需要在所有分片实例上运行。但分片越多，此类查询就越慢。

当年在 GitHub，通过 Active Record 发起的大量查询（其中许多来自首页）都是分散查询。这一限制使 GitHub 无法将分片数量增加到 16 个以上。我觉得这个细节很有意思：它说明了一个对开发者友好的抽象（Active Record）实际上可能在基础设施层面造成严重问题！

7. 对于平台工作，Maude 会亲自验证她从 LLM 得到的一切。在做基础性工作时，Maude 非常注重验证 LLM 的输出，因为她认为宏大的结构只能建立在稳定的基础之上。将“基础性”和“非基础性”工作区分开来，以便对前者——最关键的一类——给予更多关注，这是一种有趣的做法。

8. 平台工程师和产品工程师应该更多地轮岗。与 Maude 共事过的最优秀的平台工程师，都是产品工程师出身：他们多次重新实现类似功能，对重复性的苦差事感到沮丧，于是构建工具来一劳永逸地消除这些工作。但当一个平台工程师脱离产品开发、逐渐远离工程师使用产品的体验时，问题就出现了。为解决这个问题，Maude 建议实行轮岗周期：让一名平台工程师加入产品团队构建功能，同时让一名产品工程师加入平台团队。