代码托管平台 GitHub 于 8 月 17 日遭遇一次持续 7 小时 47 分钟的大规模中断，影响范围覆盖 Issues、Pull Requests、API、Actions 与 Copilot 等核心服务。GitHub 官方随后发布详细复盘报告，将事故归因于负载均衡器饱和、自动扩容策略盲区与 Visual Studio Code 客户端重试缺陷的叠加效应。

中断发生在 8 月 17 日 13:28 至 21:15（UTC），期间 GitHub.com 各项服务错误率显著攀升，峰值时网页与 API 错误率约 20%，存档与原始内容下载错误率约 50%，SAML/OIDC 认证、SCIM、Team Sync 等企业功能同样受到影响，全球大量开发者的日常工作被打断。

图：GitHub 是全球开发者的核心协作平台，一次长时间中断影响面巨大

故障链路：一个未被监控的瓶颈引发连锁反应

事故的起点是一个 Istio sidecar 容器达到并发上限。GitHub 的部分服务运行在 Istio 服务网格之上，每个应用容器旁都部署了负责网络通信的 sidecar，而事发时多个 sidecar 已达到最大并发处理能力。问题在于，GitHub 的自动扩容策略只监控主服务而忽略了 sidecar，系统因此未能及时扩容。

流量随后持续涌入，中央数据中心负载均衡器逐渐饱和，四个 HAProxy 节点耗尽流限制，形成网络拥塞。与此同时，Visual Studio Code 客户端存在的一个潜在重试缺陷开始发挥作用——认证令牌的重试请求被成倍放大，Copilot 相关令牌流量约膨胀至正常水平的 10 倍，演变为一场"重试风暴"，进一步拖慢整个平台的恢复进程。

恢复时间线

根据官方状态记录，大部分服务在 16:36 UTC 左右恢复，距故障开始约 3 小时；GitHub Actions 持续降级至 18:03 UTC 才恢复；Copilot Token Service 则最晚恢复正常。整体中断时长接近 8 小时，是 GitHub 近期影响最大的一次服务事故。

修复措施与教训

GitHub 宣布将调整自动扩容策略，把 sidecar 等周边组件纳入扩容监控范围；同时限制客户端的重试行为、修正 Istio 相关配置，并推动 Visual Studio Code 客户端修复重试缺陷，避免类似事故重演。此次事件也为行业提供了典型样本：分布式系统中"未被监控的瓶颈"与"过度激进的重试"相互叠加，足以让一次局部故障演变为全球性中断。