GitHub 复盘 8 月 17 日近 8 小时故障：一次 sidecar 扩容失配，如何演变成重试风暴
GitHub.com 在 8 月 17 日 13:28 至 21:15 UTC 出现大范围延迟和错误，持续 7 小时 47 分钟。Issues、Pull Requests、API、Actions、Copilot 以及 SAML/OIDC 认证均受影响；高峰时 Web/API 错误率约 20%，archive 和 raw 下载错误率约 50%。
GitHub 的复盘显示，最初问题出在 Central US 数据中心：一个 Istio sidecar Pod 达到并发上限，但自动扩缩容策略只监控宿主服务，没有覆盖 sidecar 的容量限制，因此未能及时扩容。
随后，流量压力传导到 4 台 HAProxy 节点并耗尽其流量限制，网关认证链路出现延迟和失败。客户端的乐观重试又将内部负载进一步放大；其中，VS Code 一个潜伏的重试问题让部分请求量增加约 10 倍，Copilot Token Service 的流量从平时的 7–9K RPS 飙升到 70–100K RPS。
恢复过程中，GitHub 将部分流量切往 Northern Virginia，暂停受影响的 HAProxy 节点后立即获得较广泛恢复；同时下调网关重试，并暂时对 Copilot Token 请求返回 HTTP 403，以阻断重试循环。多数服务在 16:36 UTC 恢复，Actions 持续受影响至约 18:03，Copilot Token Service 至 21:02 才完全恢复。
后续措施包括：修正 sidecar 容量纳入自动扩缩容策略、审计 Istio 的请求和并发限制、收紧网关与客户端的重试和退避策略、修复 VS Code 的重试放大问题，并加强负载均衡容量监控与跨区域故障转移保护。
这起事故的重点不只是“某个 Pod 到了上限”。在分布式系统里，扩缩容指标漏掉一个关键瓶颈，再叠加未经约束的重试，局部容量问题就能迅速变成跨服务故障。对依赖 Copilot、CI 和 GitHub API 的开发团队来说，客户端重试预算和降级路径同样是可靠性设计的一部分。
GitHub.com 在 8 月 17 日 13:28 至 21:15 UTC 出现大范围延迟和错误，持续 7 小时 47 分钟。Issues、Pull Requests、API、Actions、Copilot 以及 SAML/OIDC 认证均受影响；高峰时 Web/API 错误率约 20%，archive 和 raw 下载错误率约 50%。
GitHub 的复盘显示，最初问题出在 Central US 数据中心：一个 Istio sidecar Pod 达到并发上限，但自动扩缩容策略只监控宿主服务，没有覆盖 sidecar 的容量限制，因此未能及时扩容。
随后，流量压力传导到 4 台 HAProxy 节点并耗尽其流量限制，网关认证链路出现延迟和失败。客户端的乐观重试又将内部负载进一步放大；其中，VS Code 一个潜伏的重试问题让部分请求量增加约 10 倍，Copilot Token Service 的流量从平时的 7–9K RPS 飙升到 70–100K RPS。
恢复过程中，GitHub 将部分流量切往 Northern Virginia，暂停受影响的 HAProxy 节点后立即获得较广泛恢复；同时下调网关重试，并暂时对 Copilot Token 请求返回 HTTP 403，以阻断重试循环。多数服务在 16:36 UTC 恢复，Actions 持续受影响至约 18:03，Copilot Token Service 至 21:02 才完全恢复。
后续措施包括：修正 sidecar 容量纳入自动扩缩容策略、审计 Istio 的请求和并发限制、收紧网关与客户端的重试和退避策略、修复 VS Code 的重试放大问题，并加强负载均衡容量监控与跨区域故障转移保护。
这起事故的重点不只是“某个 Pod 到了上限”。在分布式系统里，扩缩容指标漏掉一个关键瓶颈，再叠加未经约束的重试，局部容量问题就能迅速变成跨服务故障。对依赖 Copilot、CI 和 GitHub API 的开发团队来说，客户端重试预算和降级路径同样是可靠性设计的一部分。