社区所有版块导航
Python
python开源   Django   Python   DjangoApp   pycharm  
DATA
docker   Elasticsearch  
aigc
aigc   chatgpt  
WEB开发
linux   MongoDB   Redis   DATABASE   NGINX   其他Web框架   web工具   zookeeper   tornado   NoSql   Bootstrap   js   peewee   Git   bottle   IE   MQ   Jquery  
机器学习
机器学习算法  
Python88.com
反馈   公告   社区推广  
产品
短视频  
印度
印度  
Py学习  »  Git

开发者彻底怒了,硬气回怼GitHub CTO:“你们平台的优先级工作是可用性,可用性,还是可用性!”

OSC开源社区 • 3 月前 • 157 次点击  

Mitchell Hashimoto 日前宣布其创建的开源终端模拟器 Ghostty 将正式离开 GitHub。

这一决定标志着这位 GitHub 第 1299 号用户、18 年忠实拥趸与该平台关系的重大转折。

Ghostty 是 Hashimoto 于 2024 年推出的终端模拟器项目,采用 Zig 语言编写,以其高性能和原生 UI 特性在开发者社区迅速获得关注。该项目目前完全托管在 GitHub 上,包括代码仓库、Issue 追踪、Pull Request 流程以及 CI/CD 流水线。迁移意味着需要找到能够替代这些基础设施的新平台。

Hashimoto 在文中回顾了自己与 GitHub 的深厚渊源。作为 2008 年 2 月注册的早期用户,他过去 18 年间几乎每天都会打开 GitHub,无论是凌晨四点的大学宿舍、经历感情挫折的低谷期,还是蜜月旅行的清晨。GitHub 不仅是他的工作平台,更是他投入热情和获得快乐的地方。他甚至坦言,当初创建 Vagrant 项目的重要动机之一就是希望借此获得 GitHub 的工作机会。

然而,近年来 GitHub 频繁的服务中断严重影响了 Hashimoto 的工作效率。他在过去一个月里坚持记录日记,几乎每一天都因 GitHub 故障而无法正常工作。就在撰写这篇文章的当天,GitHub Actions 的故障导致他长达约两小时无法进行代码审查。Hashimoto 认为,一个每天将你拒之门外数小时的平台,已经不适合开展严肃的工作。

Hashimoto 透露,Ghostty 团队已经制定了详细的迁移计划,目标是尽可能平稳地完成过渡。他们将在未来几个月内公布具体的目标平台,目前仍在与多个商业和开源提供商进行洽谈。作为过渡措施,Ghostty 将在 GitHub 上保留一个只读镜像,以确保现有链接和引用不会失效。

就在同一天,GitHub 首席技术官 Kyle Daigle 也发布了一篇关于 GitHub 平台可用性的深度更新,坦承自 2025 年 12 月以来,AI 驱动的“智能体代理式开发”浪潮使平台流量出现了前所未有的激增,给基础设施带来了巨大压力,并导致近期发生了两起影响范围较广的故障事件。

Daigle 在文中披露了一组令人瞩目的增长数据:GitHub 平台目前每月新增超过 2000 万个仓库,每周处理的 Pull Request 数量高达 9000 万次,每周产生的代码提交更是达到了惊人的 14 亿次。

与 2023 年相比,平台负载已从原先的 10 倍增长扩大到了 30 倍。这种爆炸式增长的背后,是 AI 编程助手(如 GitHub Copilot)的普及大幅降低了开发门槛,使得更多开发者涌入平台进行代码协作。

GitHub 平台增长数据
GitHub 平台增长数据

然而,流量的激增也直接暴露了基础设施的瓶颈。Daigle 详细介绍了两起近期发生的故障。第一起发生在 2025 年 4 月 23 日,一个代码合并队列(Merge Queue)的漏洞导致系统对队列中的 Pull Request 进行了重复处理,进而引发了级联故障,造成大量用户的合并操作失败。

第二起则发生在 4 月 27 日,GitHub 的 Elasticsearch 集群在峰值负载下不堪重负,导致代码搜索、问题追踪等核心功能出现性能下降甚至不可用的情况。

面对这些挑战,Daigle 称 GitHub 团队正在从短期修复和长期架构重构两个维度同时发力。短期措施包括将 Webhooks 服务从 MySQL 数据库中剥离出来,以减轻数据库压力;重新设计会话缓存机制,提升用户认证系统的稳定性。

在长期规划方面,GitHub 制定了更为激进的路线图:

  1. 将核心服务进行隔离,避免单点故障扩散到整个平台
  2. 逐步将部分关键服务从 Ruby 迁移至 Go 语言,以获得更好的性能和并发处理能力
  3. 推进多云架构部署,增强基础设施的弹性和容灾能力。

Daigle 表示:“我们的工作优先级很明确:首先是平台可用性,其次是平台负载容量,最后才是新功能。我们正在减少不必要的工作,以及改进缓存,隔离关键服务,消除单点故障,并将对性能要求较高的服务迁移到专为这些工作负载设计的系统中。这就是分布式系统的工作:减少隐藏耦合,限制影响范围,并确保 GitHub 在某个子系统压力过大时能够优雅降级。”

虽然 GitHub CTO 亲自出面发布了关于平台可用性的更新,并坦诚交代了平台目前的问题和改进措施。

但用户对此并不满意,称对方并没有真正认识到 GitHub 频繁出现服务中断的严重性,直言其优先级工作只有三项:

可用性
可用性
可用性

事实上,这并非 GitHub 首次因 AI 流量激增而面临可用性危机。早在 2025 年初,GitHub 就曾因 Copilot 的广泛使用导致 API 速率限制频繁触发,引发开发者社区的不满。


随着 AI 编程工具的持续普及,代码托管平台的负载曲线预计将继续陡峭上升。GitHub 此次的基础设施升级经验,无疑将为整个行业提供重要的参考样本。



Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/195695