21CTO导读：GitHub称宕机是因为监控盲区导致流量激增，负载均衡设备不堪重负所致。

GitHub 发布了本周近 8 小时的服务中断之事件报告，将开发者遇到的问题归咎于负载均衡器流量饱和、自动伸缩策略存在缺陷以及“Visual Studio Code 中的潜在重试错误”。

GitHub 的解释是这样说的。

问题开发始于世界标准日期 8 月 17 日 13:28 UTC，直到 21:15 才完全解决。共持续了 7 小时 47 分钟的停机事件，这导致 Issues、Pull Requests、API、Actions 和 Copilot 中出现大量的错误。

其直接原因是该公司位于美国中部数据中心的负载均衡器网络饱和，是由于 Istio sidecar 达到并发限制而触发。

自动扩缩容理应在达到这些限制时增加容量，然而事实并未出现。配置错误的策略监控了宿主机服务，却忽略了辅助服务的并发限制，导致级联故障的发生。

GitHub 这样称道：“乐观重试逻辑加剧了这个问题，它使内部负载均衡器过载。”

工程师们通过修改代码暂时减少网关重试次数，并将负载均衡器配置为拒绝使用 HTTP 403 响应的入站 Copilot Token Service 请求，这才缓解了该问题。

是的，是Copilot的原因。GitHub 这样解释说：“对单个内部端点的延迟回复触发了 VS Code 中的一个潜在重试错误，导致流量增加了大约 10 倍，并造成 Copilot Token Service 恢复延迟。”

其大多数的服务在 UTC 时间 16:36 恢复，而操作在 UTC 时间 18:03 才恢复，Copilot Token 服务直到 UTC 时间 21:02 得以修复。

GitHub向用户们补充道：“阻碍恢复的复杂因素包括针对代码加载节点的多次网络攻击。”

微软表示将纠正自动缩放策略，审查重试限制，审核 Istio 并发设置，并解决 VS Code 的行为“加剧了 Copilot 令牌流量”。

此次事件可能成为转折点，促使开发者们加速寻求替代方案。

CloudBees 首席执行官 Moritz Plassnig 在 LinkedIn 上发帖指出:

“Cursor、OpenAI 和一些规模较小的初创公司已经在构建具有竞争力的解决方案。GitHub 不会成为未来的默认解决方案，我们将面临一个更加分化的生态系统（这既有利也有弊）。”

这些发现会让开发者和工程师们感到震惊。配置错误和反复重试导致许多组织赖以生存的关键基础设施性能下降，使得人们数小时无法正常工作。

GitHub 的可靠性问题已由来已久，远不止本周，它自己也承认这一点。开发者们开始寻找新的选择，而对于这个开源平台来说，得不偿失的利弊似乎并不乐观。

正如 Plassnig 所指出的那样，替代方案开始涌现——有时甚至在最不合时宜的时候出现。

这不，在 GitHub 的运行步履蹒跚之际，马斯克 SpaceX 旗下的 Cursor宣布推出了 Origin 代码托管服务的早期测试版。

作者：场长