一次没有单一“元凶”的宕机
8 月 17 日 13:28（UTC），GitHub 的状态页面开始变红：Issues 加载失败、Pull Requests 合不了、API 报错，Actions 流水线成排挂起，连带 Copilot 一起罢工。直到当天 21:15 UTC，服务才完全恢复，前后持续 7 小时 47 分钟。8 月 20 日，GitHub 公布了事故原因：这不是某个模块的孤立故障，而是一串错误互相咬合的连锁反应。
复盘：三块多米诺骨牌
按 GitHub 的解释，事故链条大致可以拆成三段：
第一块骨牌是位于公司美国中部数据中心的负载均衡器网络饱和。请求涌入的速度超过了入口层的处理能力，负载均衡器先于后端服务倒下，整个区域的前门被堵死。
第二块骨牌是自动扩容策略的配置错误。按设计，流量激增时扩容机制应当自动顶上去，但配置问题让扩容没有按剧本执行，系统失去了自我恢复的手段，故障窗口被大幅拉长。
第三块骨牌最值得开发者警惕：Visual Studio Code 中的一个重试 bug 导致流量被放大了 10 倍。当服务变慢或出错时，客户端没有退避等待，而是高频重试，把本已饱和的入口进一步压垮，典型的重试风暴（retry storm）。
换句话说，服务端的一个容量问题，被客户端的一个健壮性 bug 放大成了近八小时的全球性故障。
为什么这次格外扎眼
对开发者而言，GitHub 出问题从来不只是“一个网站挂了”。Actions 停摆意味着依赖它的 CI/CD 流水线集体中断，PR 流程冻结直接影响协作节奏，API 报错则让大量围绕 GitHub 构建的工具链跟着抖三抖。代码托管早已是软件行业的公共基础设施，但它仍是单点的、中心化的基础设施。
值得注意的是，这只是 GitHub 今年一系列宕机中的最新一次。据 Solidot 报道，频繁的事故已促使多个知名开源项目宣布迁出，Codeberg、GitLab 以及各类自托管 Forgejo/Gitea 实例成了常见替代。对个人开发者，迁移也许只是换个 remote 地址；对深度依赖 Actions、Packages 与 GitHub 身份体系的组织，切换则是伤筋动骨的手术。
还有一层微妙之处：VS Code 与 GitHub 同属微软，Copilot、PR 扩展、内置的 Git 集成把客户端和服务端绑得越来越紧。这次事故恰好演示了深度绑定的反面，客户端的 bug 可以直接反噬服务端容量。生态整合带来便利的同时，也开辟了新的故障传播路径。
点评：三条老教训，再来一次
这次事故里几乎没有新技术，全是分布式系统的经典课题：
- 重试必须退避加抖动。 指数退避配合随机抖动是防重试风暴的标准答案，任何“失败立刻重试”的实现都是潜在放大器。这次是 VS Code，下次可能是你写的某个客户端。
- 扩容策略是需要演练的代码。 自动扩容配置平时看不出问题，出事时才发现它没按预期工作。容量预案应当像灾备一样定期验证，而不是只在事后复盘里被读到。
- 关键基础设施要有 B 计划。 给重要仓库做镜像、保留二级 CI 通道、在选型时预留迁移可能——“鸡蛋不放一个篮子”在平台频繁宕机的年份不再是多虑。
GitHub 这次公开且具体的事故复盘值得肯定，毕竟很多平台连这一步都做不到。但对用户而言，透明的复盘只能解释事故，不能阻止下一次。在“全球开发者共享一个单点”的格局下，这八小时提醒我们：基础设施的可靠性，最终还是要靠架构里的冗余来兜底。