GitHub宕机7小时47分钟，究竟发生了什么？官方发布复盘报告|service|sidecar|复盘报告|宕机|网关|重试

编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

本周一深夜，GitHub 经历了一场长达 7 小时 47 分钟的大规模故障，Issues、Pull Requests、API、Actions 以及 Copilot 等多项核心服务受到影响。巧合的是，就在同一天，马斯克旗下的 Cursor 刚刚发布了代码托管平台，一时间也被不少人视为 GitHub 的潜在替代方案。

而这场持续近 8 小时的故障，究竟是怎么发生的？

GitHub 最新发布了事故复盘报告，终于给出了答案。报告显示，这并不是某一个服务突然“挂了”这么简单，而是从 Istio sidecar 扩容异常，到负载均衡器过载，再到客户端重试放大流量，多个环节接连出现问题，最终将一次局部故障演变成了一场影响多个核心服务的大规模事故。

一场近 8 个小时的宕机事件

根据官方发布的报告显示，8 月 17 日 13:28 UTC，GitHub.com 开始出现大面积错误和延迟，持续了 7 小时 47 分钟，直到 21:15 UTC 才完全恢复。

期间，Issues、Pull Requests、API、Actions 和 Copilot 等多个核心服务均受到影响，Web 和 API 的错误率最高一度达到约 20%，而 archive 和 raw content 下载的错误率甚至接近 50%。与此同时，SAML/OIDC 身份认证、SCIM、Team Sync 等功能也受到波及，部分依赖 GitHub.com 公共 workflow 定义的 GitHub Enterprise Cloud Actions 工作流同样出现异常。

GitHub 指出，这场事故最初发生在美国中部数据中心。

当时，一组运行 Istio sidecar 的 Pod 达到了并发限制，但由于自动扩容策略存在配置问题，扩容没有正常触发。具体来说，这套策略只监控了 host service 的容量，没有正确考虑 sidecar 的并发限制，导致服务无法正常扩容。

随后，一个故障逐渐向其他节点扩散，最终有 4 个 HAProxy 节点耗尽连接流量限制，网关认证链路开始出现大面积延迟和失败。

更麻烦的是，系统原本设计的“retry”机制没有帮上忙，反而让情况进一步恶化。

大量请求在失败后不断重试，进一步增加了内部负载均衡器的压力，形成了典型的“重试风暴”。GitHub 随后将部分流量从美国中部数据中心切换到 Northern Virginia，在那里这些请求一度可以正常处理。与此同时，暂停出现问题的 HAProxy 节点后，服务也迅速出现大范围恢复。