问 HN:GitHub 员工,发生了什么?为什么?

GitHub 日益频繁的宕机被认为是多种因素共同作用的结果:从旧基础设施艰难迁移到 Microsoft Azure、AI 生成编码活动激增(据称一年内 commits 增长了 14 倍),以及 Actions 和 Copilot 等功能带来的沉重负载。评论者争论 Microsoft 的所有权和 Azure 的可靠性是否是核心问题,还是任何大型平台在这么短时间内扩展一个成熟复杂系统时都会吃力。许多人预计 GitHub 会对高流量和免费使用实施更严格的限制或新的定价,但也担心长期不稳定已经在侵蚀这个已成为核心开发者基础设施的平台信任。

高层诊断

  • 主要有两种解释占据主导:
    • AI 驱动的流量大幅增长(commits、Actions、webhooks)正在压迫一个成熟平台。
    • 从 GitHub 的旧技术栈和自有数据中心迁移到 Azure 的艰难多年进程,暴露了新的故障模式。
  • 很多人认为这两者是在相互作用:新的负载模式撞上了处于迁移中的架构。

Microsoft 收购与 Azure 迁移

  • 历史正常运行时间图显示,收购前较为稳定,之后则出现了更多事故。
  • 一些人认为原因在于:
    • 更多功能(Actions、Copilot、Codespaces、安全、packages)以及更大的故障面。
    • 持续迁移到 Azure,包括部分/双环境,据说“很痛苦”。
  • 也有人把这种相关性视为 Microsoft 和/或 Azure 才是根本问题;反驳者则指出,Azure 成功运行着许多超大规模服务。

AI 驱动增长与“slop”

  • 有人引用 GitHub 领导层的说法,称 commits 增长约 14 倍,用户增长迅速,归因于 AI 编码和 agents。
  • 许多人怀疑大量低价值或机器人流量:
    • 仓库里有成千上万的微小 commits。
    • 机器人自动创建仓库、安装应用并触发 webhooks。
    • 抓取攻击和 CI/Actions 过度使用。
  • 讨论焦点在于:这究竟是合理借口,还是规划失误,因为 AI 驱动的增长已经可见一年多了。

扩展性、架构与边界

  • 讨论包括:
    • GitHub 作为有共享状态的系统(仓库、PR、issues),而不是大多无状态的 LLM API,因此更难扩展。
    • Rails vs. “现代”技术栈;有人责怪 Ruby,也有人说架构和设计比语言更重要。
    • 缺乏激进限制和限流被视为根本原因;有人呼吁按用户或仓库设置节流并定价。
  • 一条很详细、像内部人士的评论把这描述为一个在已巨大系统上的、百年一遇级别的扩展事件,而不是简单的无能。

业务、组织与用户影响

  • 基础设施被视为成本中心,与 AI 项目和其他优先事项竞争。
  • 多轮裁员被归咎于经验流失和恢复缓慢。
  • 用户建议:
    • 结束或收紧免费无限私有仓库。
    • 向高频/滥用用户收费或限制每日 commits 上限。
  • 也有人担心,提高收费并不能解决质量问题,而切换成本使企业即使在可用性很差的情况下也仍被锁定。

近期事故复盘(2026 年 8 月 17 日)

  • 官方报告(在帖子中被引用)将一次重大故障归因于:
    • 新流量峰值使负载均衡器达到饱和。
    • Istio sidecar 自动扩缩配置错误。
    • HAProxy 流耗尽和重试风暴,尤其来自 VS Code/Copilot 的 token 逻辑。
  • 后续包括修复自动扩缩策略、重试行为和客户端放大问题,但参与者认为这证明了系统性可靠性和运维方面的缺口。