事件背景
2026 年 8 月 17 日,全球最大的代码托管平台 GitHub 经历了一次持续 7 小时 47 分钟的严重宕机。事故从当日 13:28 UTC 开始,到 21:15 UTC 才完全解决。期间 Issues、Pull Requests、API、Actions、Copilot 等多项核心服务大面积报错,Web 与 API 的错误率一度达到约 20%,原始内容与归档下载的错误率则爬升到约 50%。
事故直接拖累了大量依赖 GitHub 做协作与持续集成的团队,其中 Copilot Token Service 受到的冲击最深——这条为 GitHub Copilot 提供鉴权与计量的关键链路,在 17 日当天的流量从正常的 7–9K RPS 一路飙升到 70–100K RPS,足足放大了近一个数量级。
三层连环失效
官方事后报告把这场故障拆成了一次典型的「三层连环失效」。
第一层位于数据中心网络。事故起始于美国中部数据中心的一组负载均衡器出现网络饱和,触发原因是峰值流量撞上了一个 Istio sidecar 的并发上限,而 GitHub 的自动扩容策略只监控宿主服务的指标,没有把 sidecar 的容量纳入视野。结果一个 Pod 撑不住,连锁到四台 HAProxy 节点耗尽 flow limit,把鉴权链路拖垮。
第二层是「乐观重试」叠加。GitHub 内部网关采用了乐观重试,本来用于容灾的小机制,这次反而把已经堵死的负载均衡器进一步压垮。GitHub 的应对是「同时暂停」那四台 HAProxy,服务面这才出现真正的好转。
第三层是 VS Code 客户端的隐式重试。GitHub 解释,North Virginia 区域因为某个内部端点的延迟响应,触发了 Visual Studio Code 中的一个潜在重试 Bug,直接把这个延迟信号放大到了 10 倍的请求量,原本只是一条普通的接口抖动,演变成了对 Copilot Token Service 的「请求风暴」。
要压住这一层需要更精细的处置:一是临时用 PR 把网关重试逻辑调到保守档;二是在负载均衡层用 403 拒掉会触发重试的响应,然后再按站点逐步放流量,让客户端能逐步「断舍离」重试循环。
为什么 AI 时代这层故障变得格外刺眼
这场事故有几个值得 AI 工程师单独留意的特征。
其一,AI 开发者对 Copilot 类编码助手的依赖度,已经高到一次认证链路不可用,就会直接影响日常开发节奏。Copilot 不是「用则锦上添花」的可选项,而是大量团队 GitOps 工作流的一部分。
其二,事故响应本身要同时管理两类完全不同的时间常数:基础设施层的容器/网络故障(秒级可见、分钟级恢复)和客户端层的重试风暴(可能延后数小时才被反卷回来)。AI 助手客户端往往会默认开启高频自动重试以追求「用户感知不到」的体验,这在故障场景下却会把后端反复捶打。
其三,自动扩容策略如果只盯宿主 CPU/内存、不盯 service mesh sidecar 的并发/流量指标,在今天的服务网格架构下就是埋着一颗哑弹。一旦新版 Mesh 控制面升级或是流量形态变化,这类策略会突然看不见真正的瓶颈。
补救清单与未来启示
GitHub 在报告里给出了明确的后续动作:
- 修正自动扩容策略,把 sidecar 并发与容量纳入视野;
- 对受影响服务做一遍 Istio 请求、并发、扩缩容上限的审计;
- 复查网关与客户端的重试上限和退避行为;
- 专门修复把 Copilot Token Service 流量放大的 VS Code 重试行为;
- 加强负载均衡容量监控与跨区域 failover 保护。
这几条对国内做大规模 AI 推理平台与代码助手服务的团队同样适用。模型上线之后,真正决定可用度的往往是流量调度、限流、客户端重试与服务网格配置这些「看不见的地方」,而不是模型本身的 benchmark。一次看似普通的 HAProxy 流量饱和,在 AI Copilot 这种高 QPS 鉴权场景下,被客户端重试放大成 10 倍后,恢复时间自然以小时计算。
GitHub 在这次 8 小时级别的故障里,首次明确把责任分摊到「数据中心 + 网关 + VS Code 客户端」三层,这也意味着依赖 Copilot 的开发者,从今往后需要把「客户端关闭自动重试」、「关键工位准备备选 IDE」、「CI 把重试策略调保守」加入自己的应急预案。AI 工具越深入工作流,我们对它的可用性预期就越该逼近云数据库一样的严肃程度。
事故原始报告见 GitHub Status Incident 报告 (githubstatus.com)。