2024年最新GitHub赢回开发者信任权威精选指南：排行榜与实战对比分析

过去一年，GitHub对开发者而言已不再是那个习以为常的可靠平台。搜索功能、GitHub Actions乃至依赖它的CI/CD流水线——服务中断接连不断。十二个月内，GitHub记录下数百起故障事件，公开致歉的次数也从最初博得开发者体谅，逐渐演变为引发质疑。

The New Stack 近期专访了GitHub首席运营官Kyle Daigle（同时兼任微软开发者业务首席营销官），深入探讨了这些故障的根源及应对策略。

公司态度坦诚——他们承认，当前正处于智能体编程时代，面临前所未有的增长压力，规模已远超一般超高速云服务公司所能承受的范畴。

Daigle给出的回应是：GitHub已进入“全员应战”状态。

“这已经不是云计算时代那种‘换更大机器’或‘多加几台机器’的常规扩容思路，”Daigle告诉The New Stack，“我们需要在未来一年内实现30到40倍的扩容，而不是像以往那样，仅靠每年翻一番就以为能解决问题。”

Daigle透露，GitHub原本以为从50%增长提速到200%已算意外之喜，“结果证明那只是一个容易达成的数字，真正的挑战还在后头。”目前，工程团队正致力于将系统的提交量、拉取请求和议题处理能力提升至现有水平的30倍。

这里存在一点反讽：正是GitHub自己于2021年推出Copilot，在开发者群体中大力推广AI代码生成，并引导大家形成依赖。如今，它自身却在重压下不堪重负。2025年全年，GitHub处理了10亿次提交；而现在，仅一个月就达到14亿次。Daigle透露，仅智能体每月就会创建超过1700万个拉取请求。

为应对这一需求，GitHub正将基础设施从自有数据中心迁移到微软的Azure云平台。但Daigle强调，这绝不仅仅是单纯扩充容量那么简单。

“我们真正关注的，不只是继续增加CPU、做常规的横向与纵向扩展，更重要的是深入挖掘底层系统，对那些承载核心工作的隐性系统进行更新、重建和优化。”

早期工作重心集中在缓解数据库压力。GitHub首席技术官Vlad Fedorov在今年早些时候的博客中写道，GitHub已解决MySQL资源争用问题，将Webhook完全从MySQL剥离，并重新设计了会话缓存和身份验证流程，以降低数据库负载。

在GitHub Actions方面，Daigle表示任务分发至运行器的机制已被重写。更宏观的架构目标，是把Actions和Git这类关键服务与其他组件相互隔离，防止一个子系统出问题就拖垮其他服务。与此同时，GitHub也在将对性能敏感的代码从Ruby单体架构中逐步抽离，迁移到Go语言实现。

“那些容易摘取的低垂果实，我们已经基本拿下了，”Daigle说，不过他也承认这些改进难以直观呈现，“这就是提升可用性的两难困境——当系统正常运行时，你很难直接指出某项改进的成效。”

GitHub也在积极借助微软的力量。“这确实是全员应战，”Daigle说，“我们获得了前所未有的支持，来自有经验的工程师团队，帮我们快速完成规模化扩展。”这些增援力量大多来自微软，包括那些经历过相似规模系统挑战的工程师。

“我们的第一要务，是打造一个稳定可靠、值得信赖的平台，为全球的开发者——以及如今为全球的智能体——提供服务。”

值得玩味的是，既然可用性被列为当前最优先的事项，GitHub为什么还在Build大会上推出新版Copilot应用及其他新功能？

Daigle认为，不同产品层面的风险并不相同。CLI和新版Copilot应用的迭代处于托管GitHub核心系统的“影响半径”之外，因此可以快速推进，不会干扰正在修复中的系统。后端工作“聚焦于稳定性与韧性”，而重建底层架构有时也会顺带释放出新的功能特性。

“如果我发布一个CLI功能，它对稳定性的要求，与github.com并不在同一量级。”当然，一旦底层基础设施出现故障，这些区分也就无关紧要了。但Daigle似乎对GitHub走出这段历史充满信心。

“希望每个月都能比上个月更好一些，”他说，“我们会以最大的紧迫感全力推进。”

Q&A

Q1：GitHub近期频繁出现服务故障，原因是什么？
A：核心原因是智能体编程时代带来的爆发式增长超出了系统承载能力。2025年全年处理了10亿次提交，而如今单月就达到14亿次，智能体每月还会创建超过1700万个拉取请求。这种高达30到40倍的增速，传统扩容方案根本无法应对。

Q2：GitHub正在采取哪些技术措施来提升系统稳定性？
A：措施包括：将基础设施从自有数据中心迁移到Azure云平台；解决MySQL资源争用，把Webhook从MySQL剥离；重新设计会话缓存和身份验证流程；重写GitHub Actions的任务分发机制；将关键服务与其他组件隔离；以及将性能敏感代码从Ruby单体架构迁移到Go语言。

Q3：GitHub一边修复稳定性问题，一边还在推出Copilot等新功能，这两件事不冲突吗？
A：GitHub COO Kyle Daigle的解释是，不同产品层的风险等级不同。CLI和新版Copilot应用的开发处于核心系统的“影响半径”之外，可以独立迭代，不会影响正在修复的底层系统。后端稳定性工作与前端功能发布可以并行推进，互不干扰。

来源：互联网