8月17日的故障

故障原因与扩容争论

• 很多人把这些事件看作典型的容量断崖：系统平时运行良好，但一个很小的负载增量（例如每月 28 亿 → 29 亿次提交）就会触发隐藏的瓶颈和级联故障。
• 也有人认为 GitHub 应该更早看到“接近满载”的状态，并设计出避免这种断崖的方案；仅仅“加更多硬件”（300 万 CPU 核、120 PB 存储）被认为是不够的，还需要更好的架构和韧性。
• 一些评论者指出，这类故障在超大规模系统中很常见；也有人说 GitHub 的 RCA 看起来像是一个团队直到现在才在建立成熟的大规模实践。

AI 驱动的流量爆炸

• 大量提交增长普遍被归因于 AI/agentic 编码和自动化工作流，而不是更多的人类开发者。
• 很多人形容 GitHub 被“AI slop”淹没：频繁、低质量、自动生成的提交、PR 和 issue（Bun 被反复引用为极端例子）。
• 对于这种增长到底是从基础设施角度看“令人印象深刻”，还是更像会贬损服务、却几乎不增加价值的“癌症式增长”，各方意见不一。

Azure、Microsoft 与架构

• 很多人强烈怀疑“迁移到 Azure”是解决方案，尤其因为在一些人看来 Azure 本身就是可靠性大问题，特别是对于像 GitHub/LinkedIn 这类历史上基于 colo 的产品。
• 也有人反驳：任何大平台（AWS、Azure、GitHub）都会出故障；把问题全怪到 Azure 上被认为过于简化。

重试、惊群与韧性

• 重试风暴（尤其来自 Copilot/VS Code 客户端）被视为教科书式的“惊群效应”/重试放大问题。
• 关于最佳实践有很长的讨论：带抖动的指数退避、熔断器、客户端限流、令牌桶，以及明确区分可重试与不可重试错误。
• 有几位认为真正的根因是缺乏优雅降级和负载削减，而不只是容量不足。

免费层、AI slop 与商业模式

• 许多人怀疑 GitHub 的经济模型承压：巨量的免费托管（包括 AI 生成代码和 Actions）与有限的基础设施预算之间存在矛盾。
• 建议的缓解措施包括：按用户或按组织限制提交次数、速率限制、最低付费层（例如每月 1 美元）、将免费与付费容量池分开。
• 反方观点：Microsoft 可能愿意补贴 GitHub，把它当作亏损引流产品，以推动 AI 采用并收集代码作为训练数据，即使这会损害可靠性。

替代方案与自托管

• 人们对自托管的 GitLab、Forgejo/Gitea、Codeberg、Sourcehut，以及新的“AI-native”代码托管平台表现出强烈兴趣。
• 讨论的权衡包括：
  • 自托管：持续的管理成本不高，但控制力更强、能隔离 AI slop，而且没有单点故障。
  • GitLab：成熟但更贵且“笨重”；故障更少，但并非不会出问题。
  • Forgejo/Codeberg：FLOSS、更轻量，但 CI/应用生态较弱；Codeberg 的政治立场让一些人担忧。
  • Sourcehut：基于电子邮件的工作流受到称赞，但收费且小众。

GitHub 产品体验与工作流

• 有人认为 GitHub 在集成 issue/PR/CI 方面是“最复杂的”；但很多其他人说它“各方面都最差”，只是靠整合和网络效应取胜。
• 现在很多严肃团队把 GitHub 仅仅当作 git 托管，把规划/issue 跟踪放到别处（例如 Linear）。
• Actions 经常被提及在高负载下不可靠，并且对企业用户来说是个痛点。

领导力、沟通与信任

• 有人明显不满 GitHub 博客文章使用了企业化措辞（“we let you down”），却没有明确说“sorry”，也没有对付费客户做出具体退款/补偿承诺。
• 有些人介意 GitHub CTO 的公开资料显示过去一年里没有可见的代码贡献；也有人认为 CTO 的工作是领导，不是亲自写代码。
• 尤其是企业用户对“故障似乎同时影响付费和免费用户”感到沮丧，并希望为付费客户提供严格隔离或独立基础设施。

更广泛的担忧：价值、环境与软件质量

• 几个讨论线程质疑，爆炸式的提交增长是否带来了明显更好的软件或用户体验；很多人说，尽管代码更多了，消费级软件却变得更糟。
• 也有人反驳说，AI 让非程序员也能开发工具，并让爱好者能构建过去根本做不到的东西，不过这些收益往往是个人层面的，并不广泛可见。
• AI/数据中心的环境影响引发争论：有些人认为 AI 的能耗适中，而且可以被效率提升抵消；另一些人则认为这对气候目标是严重倒退，尤其是在主要提供商取消 CO₂ 目标的背景下。