GitHub正式道歉并承諾改進，可用率跌破85%引發開發者強烈不滿

微軟旗下代碼托管平臺GitHub近日發布了一篇措辭誠懇的公開致歉聲明，承認平臺在可用性和穩定性方面存在嚴重問題，并明確寫下了"我們深感抱歉"。

長期以來，開發者們頻繁遭遇服務中斷。就在此次道歉發布前幾天，Hashicorp聯合創始人Mitchell Hashimoto公開宣稱GitHub"已不再是嚴肅開發工作的合適場所"，并宣布將其終端模擬器項目Ghostty遷移至其他平臺。

GitHub在聲明中列舉了近期發生的幾起重大故障。4月23日，Merge Queue功能出現漏洞，導致包含多個Pull Request的合并組生成了錯誤的提交記錄。GitHub指出："在受影響的情況下，此前已合并的Pull Request和提交中的變更，被后續的合并操作意外回滾。"

4月27日，GitHub的Elasticsearch集群因"過載（疑似遭受僵尸網絡攻擊）"而崩潰，導致依賴搜索功能的多處用戶界面無法正常顯示結果。目前，GitHub仍在對此事件進行根本原因分析。

這些問題并非首次出現。今年2月，外媒就已報道GitHub在可用性方面面臨挑戰。根據重建的狀態頁面數據，該服務在2025年的可用率已跌破90%，且整體趨勢持續下滑——4月份的可用率更是已低于85%。

對于問題根源，GitHub將矛頭指向了智能體開發工作流的爆發式增長："主要驅動因素是軟件構建方式的快速變革。自2025年12月下半月以來，智能體開發工作流的使用量急劇攀升。"

在反思問題的同時，GitHub也坦承了自身在容量規劃上的失誤。公司原計劃將容量擴充10倍，并于2025年10月啟動了相關工作。然而到今年2月，實際需求已明顯表明，所需容量是原計劃的30倍。GitHub隨后緊急啟動了應對措施。

"我們的優先級非常明確：首先保障可用性，其次擴充容量，最后才是推出新功能。我們正在減少不必要的系統負載、優化緩存機制、隔離關鍵服務、消除單點故障，并將對性能敏感的路徑遷移至專為此類工作負載設計的系統中。"

對于外界關于遷移至Azure是否是罪魁禍首的質疑，GitHub予以否認，表示此次遷移實際上起到了積極作用，使其能夠"快速部署更多計算資源"。

Hashimoto在其個人網站上也發文表達了不滿："過去一個月，我堅持寫日記，每當GitHub故障影響到我的工作，就在當天日期旁畫一個'X'。幾乎每天都有'X'。就在我寫這篇文章的今天，由于GitHub Actions出現故障，我已經有將近兩個小時無法進行任何Pull Request審查。"

此次道歉聲明由GitHub首席技術官Vlad Fedorov撰寫，他在結尾寫道："我們聽到了你們正在經歷的痛苦。我們閱讀了每一封郵件、每一條社交媒體帖子和每一張支持工單，并將這一切都銘記于心。"

"我們深感抱歉。"

然而，要將開發者的信心恢復到危機前的水平——那時GitHub是存放代碼、協作開發的首選之地——僅憑一紙道歉顯然遠遠不夠。

Q&A

Q1：GitHub近期發生了哪些具體的服務故障？

A：GitHub近期發生了兩起主要故障。4月23日，Merge Queue漏洞導致包含多個Pull Request的合并組生成錯誤提交，此前已合并的變更被意外回滾。4月27日，Elasticsearch集群疑因僵尸網絡攻擊而過載，導致依賴搜索的界面無法顯示結果。目前GitHub仍在對后者進行根本原因分析。

Q2：GitHub可用率下降的主要原因是什么？

A：GitHub將主要原因歸結為智能體開發工作流的爆發式增長。自2025年12月下半月以來，這類工作流的使用量急劇攀升，導致實際所需容量遠超預期。GitHub原計劃擴充10倍容量，但到2025年2月發現實際需要擴充30倍，容量規劃嚴重滯后于需求增長。

Q3：GitHub打算如何解決可用性問題？

A：GitHub表示已明確優先級順序：首先保障可用性，其次擴充容量，最后推出新功能。具體措施包括減少不必要的系統負載、優化緩存、隔離關鍵服務、消除單點故障，以及將性能敏感路徑遷移至專用系統。此外，向Azure的遷移也在幫助平臺快速部署更多計算資源。