【核心提要】 全球最大的代码托管平台 GitHub 本周发生持续约 8 小时的服务中断，导致 Issues、Pull Requests 及 Copilot 等核心功能大面积受损。 技术调查显示，此次事故是由负载均衡器网络饱和、自动扩容配置错误以及 Visual Studio Code（VS Code）中的重试 Bug 共同导致的连锁反应。 由于今年 GitHub 故障频发，部分知名开源项目已开始考虑迁移至其他替代平台以降低风险。 【正文报道】 作为全球最大的代码托管平台，GitHub 近期再次遭遇严重的系统宕机事故。此次故障从 8 月 17 日 13:28 UTC 开始，一直持续到 21:15 UTC，总计影响时间达 7 小时 47 分钟。在故障期间，包括 Issues、Pull Requests（PR）、API、Actions 以及 GitHub Copilot 在内的核心服务均出现大规模异常，严重干扰了全球开发者的正常工作流。 针对此次事故，GitHub 发布了详细的技术说明。官方指出，导致宕机的直接诱因是位于美国中部数据中心的负载均衡器（Load Balancer）遭遇网络饱和。然而，问题的复杂性在于后续产生的连锁反应：由于自动扩容策略（Auto-scaling policy）的配置存在缺陷，系统未能及时应对流量压力；与此同时，Visual Studio Code 插件中一个导致请求量放大 10 倍的重试 Bug（Retry bug）进一步加剧了流量冲击，导致故障持续时间远超预期。 此次宕机并非孤立事件。由于 GitHub 在今年频繁出现稳定性问题，其可靠性已受到开发者社区的高度关注。近期，已有多个知名开源项目公开宣布计划迁移至其他平台。这一趋势反映出核心基础设施的稳定性对于开源生态的重要性——当核心工具链出现高频故障时，为了保障项目的持续运行，许多团队开始寻求更具稳定性的替代方案。 【背景链接】 GitHub 官方状态页：https://www.githubstatus.co... 相关技术分析报道：https://www.theregister.com... 【小编观点】 此次事故暴露了大型云服务在处理极端流量时，单一配置错误与下游工具（如 VS Code）Bug 耦合可能产生的巨大风险。对于开发者而言，虽然 GitHub 的生态极其强大，但“单点故障”的隐患始终存在。建议核心项目维护者在关键基础设施上采取多重备份或混合云策略，以降低对单一平台的过度依赖。
【核心提要】
【正文报道】
作为全球最大的代码托管平台，GitHub 近期再次遭遇严重的系统宕机事故。此次故障从 8 月 17 日 13:28 UTC 开始，一直持续到 21:15 UTC，总计影响时间达 7 小时 47 分钟。在故障期间，包括 Issues、Pull Requests（PR）、API、Actions 以及 GitHub Copilot 在内的核心服务均出现大规模异常，严重干扰了全球开发者的正常工作流。
针对此次事故，GitHub 发布了详细的技术说明。官方指出，导致宕机的直接诱因是位于美国中部数据中心的负载均衡器（Load Balancer）遭遇网络饱和。然而，问题的复杂性在于后续产生的连锁反应：由于自动扩容策略（Auto-scaling policy）的配置存在缺陷，系统未能及时应对流量压力；与此同时，Visual Studio Code 插件中一个导致请求量放大 10 倍的重试 Bug（Retry bug）进一步加剧了流量冲击，导致故障持续时间远超预期。
此次宕机并非孤立事件。由于 GitHub 在今年频繁出现稳定性问题，其可靠性已受到开发者社区的高度关注。近期，已有多个知名开源项目公开宣布计划迁移至其他平台。这一趋势反映出核心基础设施的稳定性对于开源生态的重要性——当核心工具链出现高频故障时，为了保障项目的持续运行，许多团队开始寻求更具稳定性的替代方案。
【背景链接】
【小编观点】
此次事故暴露了大型云服务在处理极端流量时，单一配置错误与下游工具（如 VS Code）Bug 耦合可能产生的巨大风险。对于开发者而言，虽然 GitHub 的生态极其强大，但“单点故障”的隐患始终存在。建议核心项目维护者在关键基础设施上采取多重备份或混合云策略，以降低对单一平台的过度依赖。