代码托管网站 GitHub 在本周出现大规模长时间的中断，此次中断时间非常长因此也导致大量用户的正常使用受影响。按惯例 GitHub 会在问题解决后发布详细的复盘报告来保持透明度，此次中断问题由外部流量太高引起，而 GitHub 内部基础设施存在多种错误，这些问题叠加起来导致长时间中断。
美国中部数据中心首先出现网络堵塞：
GitHub 部分服务通过 Istio Service Mesh 运行，应用容器旁会部署负责网络通信的 Sidecar。事故发生时其中部分 Sidecar 已经达到最大并发处理能力，但 GitHub 的自动扩容策略主要根据应用自身判断是否扩容，没有充分考虑 Sidecar 的连接和并发状态。
因此即便网络代理已经接近处理极限，系统仍然没有及时增加实例。随着部分节点无法继续正常处理流量，请求开始转移到其他节点，随后更多高可用负载均衡器节点也逐渐达到容量上限，最终导致负责身份验证等关键服务的网络路径严重堵塞。
由于 GitHub.com、GitHub API、GitHub Actions 等诸多服务都依赖身份验证和网关基础设施，因此路径发生严重堵塞后影响范围被迅速扩大。
自动重试形成的重试风暴：
正常情况下服务暂时出现错误时进行自动重试可以提高请求成功率，但在此次事故中自动重试机制反而加剧故障，当身份验证请求开始超时时，大量客户端和内部服务不断发起新请求，已经过载的负载均衡器因此收到更多流量，这种现象被称为重试风暴。
简单来说原本只是部分请求失败，但系统为提高成功率自动重新发送请求，结果让后端服务压力继续增加并导致更多超时，然后系统再次触发更多重试最终形成恶性循环。GitHub 后续通过暂停部分异常负载均衡器节点将部分流量转移到其他数据中心才逐渐恢复主要服务。
GitHub Copilot 中存在的严重错误：
GitHub Copilot 是此次事故中恢复时间最长的服务，调查发现适用于 Microsoft Visual Studio Code 中的 GitHub Copilot 存在异常重试问题，当负责签发身份验证令牌的服务响应缓慢或失败时，部分客户端会持续请求新的身份验证令牌。
正常情况下签发身份令牌的服务每秒需要处理 7000~9000 个请求，但在事故发生时请求量暴增到每秒 7 万次～10 万次，相当于正常水平的 10 倍，这些额外请求继续增加身份验证基础设施的压力，所以其他服务恢复后 GitHub Copilot 仍然无法正常工作。
海量爬虫请求也加大基础设施压力：
在复盘报告中 GitHub 还提到，事故恢复期间 Codeload 代码下载服务遭遇多轮大规模自动化爬取流量，这些异常流量并不是此次事故的主因，但在恢复期间这些流量给基础设施造成更大压力并加大故障恢复难度。
针对此次事故暴露的问题，GitHub 表示将调整自动扩容策略，同时还会重新检查内部网关和客户端的自动重试策略，避免发生故障后大量重试请求反而会压垮后台服务。
消息源：GitHub Status