GitHub 8 月 17 日故障复盘与改进
The August 17 outage, and the work ahead
8 月 17 日，GitHub 经历了长达 7 小时 47 分钟的严重故障，导致 github.com、GitHub Actions、API 及 Copilot 等服务中断，影响了全球开发者。此次事故并非由代码变更引发，而是核心基础设施在流量激增时未能及时扩容所致。自 4 月以来，GitHub 月均提交量已从 14 亿激增至 29 亿，系统压力剧增。尽管我们已新增数百万 CPU 核心并加速向 Azure 迁移，但此次事件表明可靠性工作仍需加速。我们将通过隔离关键系统、优化重试机制及提升架构扩展性，全力重建开发者信任。
我们对高可用性的承诺不仅仅是一个技术承诺，因为开发者社区依赖 GitHub 来构建、发布和运行他们的工作，而这只有在你们能信赖我们时才成为可能。
HN 评论区
731- afc
> 这两次事故的核心都是容量问题。在需求超过容量之前，我们未能对关键组件进行扩容。
这种思路是错误的，因为根本不存在无限的容量。大型分布式系统往往会同时处于大部分组件空闲、而部分子组件过载的状态。根本原因并非“某个组件容量不足（因为自动扩容失败）”，而是“当需求超过容量时，这个复杂的系统会崩溃（而非优雅降级）”。
当组件达到容量极限时，应拒绝最低优先级的多余流量。被拒绝的流量不应重试——事实上，客户端不仅不应重试这些错误，这些错误还应触发客户端限流。应实施流量隔离——如果过载是由单个客户/系统引起的，其他系统不应受到影响。
近十年前，我曾写过我们在 Google 实施这些保护措施时采用的一些技术：https://sre.google/sre-book/handling-overload/ 据我所知，大多数其他大型互联网服务随后都效仿了这些做法。
- blakesterz
> 自 4 月以来，每月提交量从 14 亿增长到了 29 亿。"
哇，这增长速度在如此短的时间内简直令人难以置信。
- madrox
我赞赏 GitHub。但我认为，无论他们多么英勇，都无法摆脱目前的困境。规模问题只会越来越严重，而且这种恶化似乎并没有给他们带来更多收入。迟早，他们不得不对目前免费的功能收费。
- aesthetics1
> 自 4 月以来，每月提交量从 14 亿增长到了 29 亿
疯了。
你可以看出整个行业都陷入了“生产力恐慌”，而这正是更多证据。肯定有个速度狂热分子在某个地方喜极而泣。
- swedishuser
我想知道流量增长中有多少来自企业用户，又有多少来自业余爱好者？对于企业客户来说，7 小时的停机时间真的非常糟糕，如果这是因为一大群不付费的“氛围码农”造成的，那就更令人难过了。无限免费套餐必须取消，这一点已经变得显而易见。
- iot_devs
> 最初，这是由于 Istio sidecar pod 达到并发限制，且因配置策略错误（该策略仅监控主机服务而未监控 sidecar 限制）导致自动扩容失败。
我曾运营过类似规模的服务，通常我们会预留一些缓冲空间，以便在容量达到 80% 以上（或任何合理的数值）时触发告警。
这样你早上喝完咖啡后，就可以去检查为什么负载均衡器集群没有自动扩容。
我确信对此有一个合理的解释说明为什么这样做不切实际，但知道这个原因会很好。
- arn3n
所有建议他们简单地对提交收费以驱赶重度 AI 用户的观点，都忽略了 GitHub 归 Microsoft 所有，而 Microsoft 有巨大的动力让开发者继续使用 AI。
我怀疑，如果亏损是因为所有用户都在使用他们的模型并支付 OpenAI 订阅费来生成代码，Microsoft 甚至可能更愿意让 GitHub 处于亏损状态。
- cube00
> 这些服务中的错误触发了客户端重试循环，导致恢复期间流量增加
这是更广泛趋势的一个症状：不惜一切代价避免向用户显示任何错误，哪怕这意味着让他们盯着旋转的加载图标看 7 个小时。
> 对单个内部端点的延迟响应触发了 VS Code 中的一个潜在重试 bug，导致流量放大了约 10 倍，并造成 Copilot Token Service 恢复延迟。
详细的根因分析试图将此事轻描淡写地称为“bug”。你总不能严肃地告诉我，客户端重试没有单元测试来确保重试退避行为完全按设计运行吧？在这种情况下，当 token 服务响应变得不稳定时，这种激进的重试显然是为了掩盖问题。
- jdm2212
> 这些服务中的错误触发了客户端重试循环，导致恢复期间流量增加。
我参与过的最糟糕的停机事故，总是包含某种形式的这种情况 :(
- _fzslm
我理解 GitHub 目前正经历前所未有的负载，但这不仅仅是（ admittedly 极端的）提交/推送负载造成的。
他们的 Copilot 云端代理产品正遭受着我所见过的最严重的企业级“多动症”（ADHD）。我们基于它构建了一个云端代理开发流水线，似乎几乎每隔一周，他们就会在没有任何公开公告的情况下静默更改某些内容，给我们的团队造成真正的干扰。
注意：这不是文章中讨论的 Copilot 平台本身的 bug。这是真正的破坏性变更，显然在推送到生产环境前未经过测试/审查，且没有任何公开公告或文档。
支持毫无用处——我们是支付数千美元费用的客户，但我们的工单却无人回应。
我爱（过）GitHub，但我认为他们此刻已经失去了足够的公众信任，时间正在倒数。随着专为代理设计的新型 VCS 的讨论出现，我相信这只是时间问题。说出这话让我有些痛心。