摘要

  • GitHub 称，8 月 17 日的故障持续 7 小时 47 分钟。网页和 API 的峰值错误率约为 20%，归档文件和仓库原始内容下载的错误率约为 50%；Issues、Pull Requests、Actions、企业身份服务和 Copilot 均受到影响。
  • 公司把起点归因于 Istio sidecar 达到并发上限，而扩容策略只监测宿主服务、没有监测 sidecar。随后 4 个 HAProxy 节点耗尽流量上限，重试又把 Copilot Token Service 从正常的每秒 7,000–9,000 次请求推高到 70,000–100,000 次。

把失败流量从 Central US 转向 Northern Virginia 后，一部分请求得到了正常处理。但在这次事故中，“有备用区域”和“已经恢复”并不是同一件事。

GitHub 在事件 zkxwbgr0cnmx 的详细更新中，将影响时间界定为 8 月 17 日 13:28 至 21:15 UTC。Issues、Pull Requests、API、Actions 和 Copilot 出现错误或延迟。网页与 API 的错误率一度约为 20%，归档和仓库原始内容下载的错误率约为 50%。

企业控制入口也进入了同一影响面。GitHub 点名 SAML、OIDC、SCIM 和 Team Sync。采用数据驻留的 GitHub Enterprise Cloud 客户，如果 Actions 工作流依赖托管在 GitHub.com 上的公共步骤定义，也会受到影响。这并不等于数据离开所选区域，更不证明数据驻留承诺失效；公开记录说明的是执行路径仍可能依赖另一个服务面。

GitHub 认为，直接原因是 Central US 数据中心的负载均衡器遇到新的流量峰值后发生网络饱和。一个 Istio sidecar pod 达到并发上限。扩容策略观察的是宿主服务，而不是 sidecar 自身的上限，因此真正受限的组件没有随需求增加容量。

瓶颈随后向外扩散，最终有 4 个 HAProxy 节点耗尽 flow limit，共用的网关身份验证路径开始出现延迟和失败。GitHub 表示，同时暂停这些节点上的 HAProxy 后，多个服务立即广泛恢复。到 16:36 UTC，大多数服务已恢复；Actions 则持续受影响到约 18:03。

Copilot 的恢复更晚，因为慢响应触发了新的请求。GitHub 称，某个内部端点的延迟暴露了 VS Code 中一个潜伏的重试缺陷。一次失败的 token 操作可能派生出多次请求并进入循环。Copilot Token Service 的流量由正常每秒 7,000–9,000 次，升至每秒 70,000–100,000 次，约为常态的十倍。

这段恢复过程的重点不是继续增加接收能力，而是停止放大。GitHub 临时减少网关重试，在负载均衡器处对部分 Copilot token 请求返回 HTTP 403，再按站点逐步恢复流量。Token Service 于约 21:02 UTC 完全恢复，13 分钟后事件记录关闭。

状态记录还提到，针对 codeload 端点的多起抓取攻击增加了处置难度。GitHub 没有量化这部分流量对饱和或恢复时长的贡献，也没有把它列为最初原因。已披露的主链条仍是 sidecar 并发限制、错误的扩容观察对象、HAProxy 流量耗尽和重试放大。

产品文档解释了为什么看似不同的功能会跨过相同边界。GitHub 允许可复用工作流调用公共仓库中的定义；托管 runner 文档则把 GitHub.com、API、Actions 域名和 codeload.github.com 列为执行任务或下载 action 所需访问的目标。

身份系统也是核心依赖。GitHub 将 SAML SSO 与 SCIM用于企业访问与账号生命周期管理，并在数据驻留说明中介绍专用 GHE.com 子域和多区域选择。存储位置回答“数据放在哪里”，却不会自动回答每次身份验证、工作流取用或 token 签发要经过哪些共享服务。

GitHub 公布的后续措施包括：让扩容策略识别 sidecar 并发和容量，审计 Istio 的请求及扩容限制，检查网关与客户端的重试和退避，修正 VS Code 的相关行为，并改善负载均衡器容量监测和区域故障转移。这些目前是承诺，而不是已经验证的结果。之后需要观察公司是否公布实施证据，以及类似异常能否在形成重试风暴前被限制。

客户无法看到 GitHub 的内部遥测，但可以把自身验收拆成若干路径：仓库读取、API 请求、SSO 登录、团队成员同步、公共工作流定义下载、runner 启动和 Copilot token 获取。主网页恢复，并不能替代这些逐项结果。

GitHub 的 REST API 最佳实践也要求集成方遵守 Retry-After 和限流重置时间，并在连续失败时逐步增加等待。该文档针对外部 API 客户端，不是在解释这次内部故障；但它对应同一条运营原则：没有边界的重试会把等待转化为新负载。

来源