GitHub 真的“熟”了吗？ outage 追踪
GitHub Outage Tracker: Is GitHub Cooked?
今天 GitHub 又出事了，所有服务全线告急。我搭建了这个站点，专门用来过滤 GitHub 的历史故障，只关注影响我产品的服务和严重程度。毕竟，每个人的可靠性叙事都取决于他们依赖的服务和期待的 9 的位数。数据显示，自 2016 年 3 月以来，GitHub 已发生 1125 次故障，平均每月 24 次。2026 年 2 月更是惨烈，单月故障高达 37 次。Copilot 和 Actions 的停机时间最长，而 Dashboard 和 Docs 等服务则保持了 100% 的正常运行。通过自定义过滤器，你可以看清属于自己的可靠性真相，避免在讨论中各说各话。
HN 评论区
155- kashnote
我觉得我们应该对 GitHub 多一点同情。当我们还能把任何故障都归咎于迁移到 Azure 时，那些吐槽或许还情有可原；但他们随后披露的数据表明，如今每个人都借助 AI 不断构建和推送代码，他们面临的规模已远超从前。
我认为他们值得称赞的一点是，并没有限制网站访问，也没有（故意）对新用户进行限流。是的，他们确实需要解决这个问题，但多一份同情心会很有帮助。我个人衷心祝愿他们一切顺利，希望他们的值班人员能早日恢复正常的睡眠。
- joshuahedlund
鉴于这些故障是由创纪录的流量引起的，到目前为止，他们只是陷入了 Yogi Berra 式的那种“熟”——“没人再去那儿了，因为人太多了”。
- Fuzzwah
在我担任 GitHub 企业支持工程师的 8 年半时间里，临近离职时，我曾在全体会议上问是否考虑过推出“GitHub Classic”产品。就像《魔兽世界：经典版》一样，我设想它会是一次重写，专注于还原过去更简洁的功能集。
我得到的回应基本上和暴雪当时给的一样：“你以为你想要那个，但其实你并不想要。”
- JeremyHerrman
> “自 2016 年 2 月以来，GitHub 已发生 1125 起事故，意味着月均事故率为 24 起”
1125 起事故除以 126 个月 ≈ 每月 8.9 起，而不是 24 起。
虽然依然糟糕，但第一句话里为什么会出现如此明显的错误……
- crossroadsguy
但在探索了一些针对小型、私有及个人仓库（非开源；至少目前还不是）的替代方案后，我意识到自己还是用免费的 GitHub 私有仓库更划算。对于这类使用场景，根本没有可行的免费替代方案，因为其他选项往往很快就会触达限制——通常是 50MB，多则几百 MB。
有 gitlab.com、bitbucket（？很久没用了），但它们在我的使用场景下没有任何优势。
还有别的吗？
- _heimdall
我能体会到 GitHub 团队如今处理这些问题的不易。但我也完全无法理解，那些掌舵多年的人怎么会没预料到这一点。
GitHub 已被微软收购，无论他们内部是否承认这一点。微软在 LLM 领域投入极深，特别是针对编程用例的 LLM。他们一定意识到，LLM 生成的代码和 PR 实际上会对 GitHub 造成 DDoS 攻击。
我只能假设他们根本不在乎，很可能是被贪婪驱使。
- silver92bullet
我听到了那些说我们应该同情 GitHub 的评论。对于一线的运维/SRE 个人，我确实能表示同情，因为内部协调管理一定非常艰难。但我无法同情这家公司本身。他们既没有为自己，也没有为社区铺平成功之路。我认为，预见问题或至少以能建立信任的方式做出反应，是公司的责任。事实是，公司内部存在系统性问题，导致反复出现不可靠的情况，而他们并未将其根除。
- bushbaba
也许本可以做一个静态页面，上面只写一个大大的“是”，而且很大一部分时间里它都是准确的。