<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 表示歉意並承諾改進