GitHub 的 1127 次事故追踪：当“是不是崩了“成了新一代开发者的心理阴影

GitHub 的 1127 次事故追踪当是不是崩了成了新一代开发者的心理阴影“GitHub 到底还行不行”——这个看起来像吐槽的问题现在真有人给数据做出了统计。一个开源的第三方站点GitHub Outage Tracker爬遍了 GitHub 自 2016 年 3 月以来的全部事故记录整理出这样一串数字累计1127 次事故过去三个月平均每月24.7 次最长连续不宕机的纪录只有8 天最差的2026 年 2 月一个月就崩了37 次。这篇文章不打算下GitHub 药丸的结论而是想顺着这些数字认真聊聊一个更值得琢磨的问题当全世界的代码、CI、模型、Agent 都长在一家平台上时它的可靠性到底该怎么被衡量又该怎么被理解。一、先看清这几行数字1127、24.7、8 天“isgithubcooked.com这个站点的作者说得很直白他做这个工具的初衷是想按自己维护的产品所依赖的服务和严重等级过滤出 GitHub 的事故史。每个人对靠不靠谱的判断本质上都取决于你在意的是哪几项服务、期望几个 9”。站方给出的一组基础盘点1127 次事故从 2016 年 3 月算起GitHub 累计报告的事故次数。过去 3 个月平均 24.7 次/月相比再往前 3 个月还下降了约 1%。最长零事故区间只有 8 天这段纪录在 2025 年 12 月 31 日结束。最差月份是 2026 年 2 月单月37 次事故。单看这些很容易得出GitHub 经常崩的结论。但别急着下判断——这正是这个站点的价值它逼着我们把感觉变成口径。你的它老崩是哪几类服务的崩是Critical严重还是Minor轻微这直接决定了结论完全不同。二、把事故按严重等级摊开81% 是轻微站方给出的事故影响分布非常关键Critical严重28 次占2%Major重大186 次占17%Minor轻微913 次占81%也就是说绝大多数超过八成Reported 的问题其实是轻微级别的——可能是某个功能短暂抖动、某个界面偶发错误并不等于整站不可用。真正称得上严重瘫痪的只占 2%。这提醒我们一个信息论的陷阱事故数量 ≠ 故障损失。一次 Critical 能让全世界 CI 漂红几个小时一百次 Minor 可能只让你刷新一下网页。只看1127 次这个总数恰恰可能做出与真实影响相反的判断。三、逐项服务算 UptimeCopilot 垫底仓库与 Gists 最稳站方还按服务拆出了过去 3 个月的可用性uptime排行。这里藏着很多反直觉的东西排序服务可用性折算停机1Copilot97.93%7 天 13 小时2Actions98.20%6 天 14 小时3Pull Requests98.58%5 天 4 小时4Search99.11%3 天 5 小时5Webhooks99.40%2 天 4 小时6Issues99.43%2 天 2 小时7Pages99.45%1 天 23 小时8Git Operations99.49%1 天 20 小时9Codespaces99.52%1 天 17 小时10API Requests99.53%1 天 17 小时…………21Repositories99.916%7 小时 24 分钟22Audit Log99.950%4 小时 21 分钟23Gists99.987%1 小时 10 分钟24-26Dashboard / Discussions / Docs / Mobile100%无最扎眼的是Copilot97.93%足足 7 天 13 小时停机。Actions也不遑多让6 天 14 小时。而反直觉的是——最底层的 Repositories仓库和 Gists 反而最稳都是几个 9 的水平。为什么因为越是新、越是 AI、越是计算密集的特性越容易在扩容和更新的过程中波动。Copilot 和 Actions 是重计算、重推理、重调度的一层而纯存储的仓库/Gists 则成熟、稳定、几乎不碰边缘的宿主环境。一个平台的底线和它的炫技层稳定性从来不在一个量级。四、NVIDIA × GitHub × Hugging Face这串数字为什么刚好卡在 AI 时代就在这批事故数据的同一天前后另一条新闻震动了整个圈层NVIDIA 宣布收购 Hugging Face并联手拿下GitHubAI GitHub。理由毫无悬念——所有人都在押注AI 时代的基础设施模型、数据集、推理、以及承载研发协作的代码平台。于是GitHub 是否 cooked这个问题就不再只是一个社区闲谈而变成了资本与算力的战略问题站在开发者角度GitHub 是我写代码的地方我关心的是 Actions、Copilot、Pages 这些日常吞吐是否稳定。站在AI 时代角度GitHub 还承载着海量开源的训练语料、模型权重、Agent 的 CI/CD。它的每一次 Critical都可能让一整套 Agent 工作流原地停摆。这恰恰解释了为什么一个事故追踪器能在 HN 上拿到 225 分、144 条评论——因为在 2026 年GitHub 的可靠性早就不只是代码托管商的 KPI而是整个 AI 研发链路的最短那块木板。五、数字的另一面月均 24.7 次但它在变好再回头把数字读一遍还有一层不能漏过去 3 个月 24.7 次/月其实比再往前 3 个月下降了约 1%。也就是说在绝对次数很多的表象之下趋势是边际收敛的而不是恶化的。站方主页那句Simmering慢火慢炖。最后一次事故在 1 天前很形象。GitHub 的现状更像一锅一直没熄过火的汤不断有小气泡Minor/Major冒出来但很少真的炸锅Critical 仅 2%。“cooked这个词在英文里既指熟了/完了”也暗合这种一直在炖的慢热状态——作者挑这个词当站点名本身就是个双关的幽默。六、结语与其问GitHub 行不行不如问你的 9’s 到底是几个回到开头的那个拆解每个人对可靠性的判断都是服务子集 × 严重等级 × 期望的 9 的个数的函数。这家站点最有价值的一点是它把感觉式吐槽拉回到了可过滤、可对照、可声明的口径——你能对同事说“我构建的是 X、Y、Z 服务它们过去 3 个月的可用性是 99.5%我的 9’s 是这么算的。”在 AI 时代当模型、Agent、CI 全都跑在同一个平台上这种可靠性语言会比以往任何时候都更重要。因为当你的整个研发链路都架在一家平台上时它行不行不是一个舆论问题而是一个运维决策、一个保险精算问题、甚至一个资本定价问题。GitHub 过去十年的 1127 次事故里81% 只是溅出的小水花2% 才是真正的炸锅。至于它到底 cooked 没有——答案在你自己维护的那张服务表里。