<p>微软的代码托管平台 GitHub 发布了一篇关于其可用性和可靠性问题的长篇道歉信，其中包含了 “我们很抱歉” 的字样。</p>
<p>使用该服务的开发者们面临着反复的停机，而这份道歉是在 Hashicorp 联合创始人 Mitchell Hashimoto 宣布该平台 “已不再是严肃工作的地方” 并计划将他的终端仿真器项目 Ghostty 转移到其他地方后几天发布的。</p>
<p>GitHub 在其帖子中强调了几起最近的事件。4 月 23 日，一个合并队列的错误导致包含多个拉取请求的合并组产生了错误的提交。</p>
<p>GitHub 指出：“在受影响的情况下，之前合并的拉取请求和先前提交的更改被后续合并意外地还原。”</p>
<p>然后在 4 月 27 日，依赖于搜索的用户界面的部分在 GitHub 的 Elasticsearch 集群变得 “过载（可能是由于僵尸网络攻击）” 后停止显示结果。GitHub 仍在进行根本原因分析。</p>
<p>这些问题并不新鲜。根据 <em>The Register</em> 的报道，GitHub 在 2 月份就面临可用性问题。根据重建的状态页面，该服务的正常运行时间在 2025 年降至 90% 以下，且趋势一直在下降。4 月的正常运行时间现在低于 85%。</p>
<p>根据消息来源，人工智能是一个因素：“主要驱动因素是软件构建方式的快速变化。自 2025 年 12 月下半月以来，代理开发工作流程急剧加速。”</p>
<p>在一片担忧之中，GitHub 承认它曾计划将容量提高 10 倍，并表示从 2025 年 10 月开始着手进行此项工作。然而，到今年 2 月，显然需要的容量是 30 倍。GitHub 此后一直在忙于解决这些问题。</p>
<p>“我们的优先事项很明确：首先是可用性，然后是容量，最后是新功能。我们正在减少不必要的工作，改善缓存，隔离关键服务，消除单点故障，并将性能敏感的路径迁移到为这些工作负载设计的系统中。”</p>
<p>那么迁移到 Azure 呢？这并不是罪魁祸首。GitHub 表示，迁移实际上有所帮助，使其能够 “快速提供更多计算能力”。</p>
<ul>
<li>IBM 的 AI 编码 “伙伴” Bob 正式上线</li>
<li>微软的 GitHub 在成本危机中转向计量 AI 计费</li>
<li>Tokenmaxxing 不是一种 AI 策略</li>
<li>Claude Opus 4.7 变成了一个过于热心的查询警察，开发者们抱怨</li>
</ul>
<p>昨天，Hashimoto 在他的网站上抱怨道：</p>
<p>“在过去一个月里，我一直在写日记，每当 GitHub 停机对我的工作产生负面影响时，我就在每个日期旁边标记一个 'X'。几乎每天都有一个 'X'。在我写这篇文章的当天，由于 GitHub Actions 停机，我无法进行任何 PR 审查，持续了大约 2 小时。”</p>
<p>GitHub 的道歉是由首席技术官 Vlad Fedorov 撰写的，他最后说：“我们听到了你们所经历的痛苦。我们阅读每一封电子邮件、每一条社交帖子、每一个支持票据，并将其铭记于心。”</p>
<p>“我们很抱歉。”</p>
<p>恢复开发者对危机前水平的信心——当时它是存储代码和协作项目的首选之地——需要的不仅仅是言辞。</p>
<p>®</p>

ESTC

全球科技股指数 ETF - iShares

标普软件与服务 ETF - SPDR

云计算 ETF - GlobalX

北美科技软件股指数 ETF - iShares

<p>GitHub 对其近期的可用性和可靠性问题表示歉意，承认重复的停机时间导致开发者质疑其在严肃工作中的可行性。值得注意的事件包括合并队列错误和 Elasticsearch 过载。2025 年 4 月的正常运行时间已降至 85% 以下，GitHub 承认低估了所需的容量。该公司正在优先改善可用性和容量，同时解决这些停机的根本原因。GitHub 的首席技术官对开发者的挫败感表示同情，强调需要恢复对平台的信心</p>

<p>Microsoft's code hosting shack Github has published a lengthy mea culpa about its availability and reliability woes - one that includes the words &#34;we are sorry.&#34;</p>
<div class="lb-trans"><p>微软的代码托管平台 GitHub 发布了一篇关于其可用性和可靠性问题的长篇道歉信，其中包含了 “我们很抱歉” 的字样。</p>
</div><p>Developers using the service have faced repeated downtime, and the apology comes days after Hashicorp co-founder Mitchell Hashimoto declared the platform is &#34;no longer a place for serious work&#34;, announcing plans to move his terminal emulator project, Ghostty, elsewhere.</p>
<div class="lb-trans"><p>使用该服务的开发者们面临着反复的停机，而这份道歉是在 Hashicorp 联合创始人 Mitchell Hashimoto 宣布该平台 “已不再是严肃工作的地方” 并计划将他的终端仿真器项目 Ghostty 转移到其他地方后几天发布的。</p>
</div><p>GitHub highlighted several recent incidents in its post. On April 23th, a Merge Queue bug caused merge groups containing more than one pull request to produce incorrect commits.</p>
<div class="lb-trans"><p>GitHub 在其帖子中强调了几起最近的事件。4 月 23 日，一个合并队列的错误导致包含多个拉取请求的合并组产生了错误的提交。</p>
</div><p>&#34;In affected cases,&#34; notes GitHub, &#34;changes from previously merged pull requests and prior commits were inadvertently reverted by subsequent merges.&#34;</p>
<div class="lb-trans"><p>GitHub 指出：“在受影响的情况下，之前合并的拉取请求和先前提交的更改被后续合并意外地还原。”</p>
</div><p>Then on April 27th, parts of the user interface dependent on search stopped showing results after GitHub's Elasticsearch cluster became &#34;overloaded (likely due to a botnet attack).&#34; GitHub is still working on a root cause analysis.</p>
<div class="lb-trans"><p>然后在 4 月 27 日，依赖于搜索的用户界面的部分在 GitHub 的 Elasticsearch 集群变得 “过载（可能是由于僵尸网络攻击）” 后停止显示结果。GitHub 仍在进行根本原因分析。</p>
</div><p>The problems are not new. In February, <em>The Register</em> noted that GitHub was struggling with availability. Uptime for the service, according to a reconstructed status page, dropped below 90 percent in 2025, and the trend has been downward. April's uptime is now below 85 percent.</p>
<div class="lb-trans"><p>这些问题并不新鲜。根据 <em>The Register</em> 的报道，GitHub 在 2 月份就面临可用性问题。根据重建的状态页面，该服务的正常运行时间在 2025 年降至 90% 以下，且趋势一直在下降。4 月的正常运行时间现在低于 85%。</p>
</div><p>AI is a factor, according to the source shack: &#34;The main driver is a rapid change in how software is being built. Since the second half of December 2025, agentic development workflows have accelerated sharply.&#34;</p>
<div class="lb-trans"><p>根据消息来源，人工智能是一个因素：“主要驱动因素是软件构建方式的快速变化。自 2025 年 12 月下半月以来，代理开发工作流程急剧加速。”</p>
</div><p>In between the handwringing, GitHub admits it had planned to up capacity by 10X and said it began work to do this in October 2025. However, by February this year, it became clear that 30 times as much capacity is required. GitHub has since scrambled to deal with the issues.</p>
<div class="lb-trans"><p>在一片担忧之中，GitHub 承认它曾计划将容量提高 10 倍，并表示从 2025 年 10 月开始着手进行此项工作。然而，到今年 2 月，显然需要的容量是 30 倍。GitHub 此后一直在忙于解决这些问题。</p>
</div><p>&#34;Our priorities are clear: availability first, then capacity, then new features. We are reducing unnecessary work, improving caching, isolating critical services, removing single points of failure, and moving performance-sensitive paths into systems designed for these workloads.&#34;</p>
<div class="lb-trans"><p>“我们的优先事项很明确：首先是可用性，然后是容量，最后是新功能。我们正在减少不必要的工作，改善缓存，隔离关键服务，消除单点故障，并将性能敏感的路径迁移到为这些工作负载设计的系统中。”</p>
</div><p>What about the migration to Azure? That is not the culprit. GitHub says the migration has actually helped, allowing it to &#34;stand up a lot more compute&#34; quickly.</p>
<div class="lb-trans"><p>那么迁移到 Azure 呢？这并不是罪魁祸首。GitHub 表示，迁移实际上有所帮助，使其能够 “快速提供更多计算能力”。</p>
</div><ul>
<li>IBM's AI coding 'partner' Bob hits general availability</li>
<li>Microsoft's GitHub shifts to metered AI billing amid cost crisis</li>
<li>Tokenmaxxing isn't an AI strategy</li>
<li>Claude Opus 4.7 has turned into an overzealous query cop, devs complain</li>
</ul>
<div class="lb-trans"><ul>
<li>IBM 的 AI 编码 “伙伴” Bob 正式上线</li>
<li>微软的 GitHub 在成本危机中转向计量 AI 计费</li>
<li>Tokenmaxxing 不是一种 AI 策略</li>
<li>Claude Opus 4.7 变成了一个过于热心的查询警察，开发者们抱怨</li>
</ul>
</div><p>Yesterday, Hashimoto complained in a post on his website:</p>
<div class="lb-trans"><p>昨天，Hashimoto 在他的网站上抱怨道：</p>
</div><p>&#34;For the past month I've kept a journal where I put an 'X' next to every date where a GitHub outage has negatively impacted my ability to work. Almost every day has an 'X'. On the day I am writing this post, I've been unable to do any PR review for ~2 hours because there is a GitHub Actions outage.&#34;</p>
<div class="lb-trans"><p>“在过去一个月里，我一直在写日记，每当 GitHub 停机对我的工作产生负面影响时，我就在每个日期旁边标记一个 'X'。几乎每天都有一个 'X'。在我写这篇文章的当天，由于 GitHub Actions 停机，我无法进行任何 PR 审查，持续了大约 2 小时。”</p>
</div><p>GitHub's apology was penned by Chief Technology Officer, Vlad Fedorov, who closed with: &#34;We hear the pain you're experiencing. We read every email, social post, support ticket, and we take it all to heart.&#34;</p>
<div class="lb-trans"><p>GitHub 的道歉是由首席技术官 Vlad Fedorov 撰写的，他最后说：“我们听到了你们所经历的痛苦。我们阅读每一封电子邮件、每一条社交帖子、每一个支持票据，并将其铭记于心。”</p>
</div><p>&#34;We're sorry.&#34;</p>
<div class="lb-trans"><p>“我们很抱歉。”</p>
</div><p>Restoring developer confidence to pre-crisis levels - when it was the go-to place for stashing code and collaborating on projects - will take more than words.</p>
<div class="lb-trans"><p>恢复开发者对危机前水平的信心——当时它是存储代码和协作项目的首选之地——需要的不仅仅是言辞。</p>
</div><p>®</p>
<div class="lb-trans"><p>®</p>
</div>

由于正常运行时间的下降和开发者的抱怨，GitHub 表示歉意并承诺改进