以下是我們為改善可用性與可靠性所做的努力，以及仍在進行中的工作。

鑑於近期發生的兩起事件，我想在此更新 GitHub 的可用性狀況。這兩起事件都無法接受，我們對其造成的影響深感抱歉。我想分享一些關於這些事件的細節，並說明我們已採取以及正在採取的措施來改善我們的可靠性。

我們於 2025 年 10 月開始執行一項計畫，目標是將 GitHub 的容量提升 10 倍，以大幅改善可靠性與故障轉移能力。到了 2026 年 2 月，我們清楚需要為一個需要現今規模 30 倍的未來進行設計。

主要驅動因素是軟體開發方式的快速變化。自 2025 年 12 月下半月以來，代理式開發工作流程已急劇加速。從幾乎所有指標來看，方向已經很明確：儲存庫建立、提取請求活動、API 使用量、自動化和大型儲存庫工作負載都在快速增長。

這種指數級的成長並非一次只會對單一系統造成壓力。一個提取請求可能會影響 Git 儲存、合併性檢查、分支保護、GitHub Actions、搜尋、通知、權限、Webhook、API、背景作業、快取和資料庫。在高規模下，微小的效率低下會累積：佇列加深、快取遺失導致資料庫負載增加、索引落後、重試放大流量，以及一個緩慢的依賴項可能會影響多個產品體驗。

我們的優先事項很明確：首先是可用性，然後是容量，最後是新功能。我們正在減少不必要的工作、改善快取、隔離關鍵服務、移除單點故障，並將效能敏感的路徑轉移到專為這些工作負載設計的系統中。這是分散式系統的工作：減少隱藏的耦合、限制爆炸半徑，並在一個子系統面臨壓力時讓 GitHub 能夠優雅地降級。我們正在快速取得進展，但這些事件是仍有工作要做之處的範例。

短期內，我們必須解決各種比預期更早出現的瓶頸，包括將 Webhook 移至不同的後端（移出 MySQL）、重新設計使用者會話快取，以及重做驗證和授權流程以大幅減少資料庫負載。我們也利用遷移到 Azure 的機會，啟用了更多的運算資源。

接下來，我們專注於將 Git 和 GitHub Actions 等關鍵服務與其他工作負載隔離，並透過最小化單點故障來限制爆炸半徑。這項工作始於對依賴項和不同層級流量進行仔細分析，以了解需要分離哪些內容以及如何最大限度地減少對各種攻擊的合法流量的影響。然後，我們按照風險順序解決這些問題。同樣地，我們加速了將效能或規模敏感的程式碼從 Ruby 單體遷移到 Go 的部分工作。

雖然我們已經在將較小的自訂資料中心遷移到公有雲的過程中，但我們也開始著手進行多雲策略。這項長期措施對於實現未來所需的彈性、低延遲和靈活性至關重要。

GitHub 上的儲存庫數量正在以前所未有的速度增長，但更具挑戰性的擴展難題是大型單體儲存庫的興起。在過去三個月裡，我們一直在大力投資以應對這一趨勢，無論是在 Git 系統內部還是在提取請求體驗方面。

我們將很快發布另一篇部落格文章，詳細介紹我們所做的廣泛工作以及為提高效率和規模而設計的新 API。作為這項工作的一部分，我們投資優化合併佇列操作，因為這對於每天有數千個提取請求的儲存庫至關重要。

最近的兩起事件在原因和影響上有所不同，但都反映了我們為何要加強對可用性、隔離和爆炸半徑縮減的關注。

4 月 23 日，提取請求出現了影響合併佇列操作的回歸。

透過合併佇列使用壓縮合併方法合併的提取請求，在合併群組包含多個提取請求時產生了不正確的合併提交。在受影響的情況下，先前合併的提取請求和先前提交的變更被後續的合併無意中撤銷了。

在事件發生期間，有 658 個儲存庫和 2,092 個提取請求受到影響。我們最初分享的數字略高，因為我們的初步評估是故意保守的。該問題並未影響合併佇列之外的提取請求，也沒有影響使用合併或 rebase 方法的合併佇列群組。

沒有發生資料遺失：所有提交都仍然儲存在 Git 中。然而，受影響預設分支的狀態不正確，我們無法自動安全地修復每個儲存庫。更多詳細資訊可在事件根本原因分析中找到。

這次事件暴露了多項流程失敗，我們正在改變這些流程以防止這類問題再次發生。

4 月 27 日，一起事件影響了我們的 Elasticsearch 子系統，該子系統為 GitHub 的多項搜尋支援體驗提供動力，包括提取請求、問題和專案的部分功能。

我們仍在完成根本原因分析，並將很快發布。我們現在知道的是，該叢集過載（很可能是由於網路釣魚攻擊）並停止返回搜尋結果。沒有發生資料遺失，Git 操作和 API 並未受到影響。然而，依賴搜尋的 UI 部分顯示無結果，這造成了重大中斷。

這是我們尚未完全隔離以消除單點故障的系統之一，因為在我們的風險優先級可靠性工作中，其他領域的優先級更高。這種影響是無法接受的，我們正在使用上述相同的依賴項和爆炸半徑分析來降低未來發生此類故障的可能性和影響。

我們也聽到了客戶在事件期間需要更大透明度的明確回饋。

我們最近更新了 GitHub 狀態頁面，以包含可用性數字。我們也承諾會報告大小事件，這樣您就不必猜測問題是出在您這邊還是我們這邊。

我們正在繼續改進事件分類方式，以便更容易理解其規模和範圍。我們也正在尋找更好的方法，讓客戶在發生中斷時能夠報告事件並與我們分享訊號。

GitHub 的角色始終是透過開放且可擴展的平台來支援開發人員。

GitHub 的團隊對我們的工作充滿熱情。我們聽到了您正在經歷的痛苦。我們閱讀了每一封電子郵件、社群貼文、支援票證，並將它們銘記在心。我們感到抱歉。

我們致力於提高可用性、增強彈性、為軟體開發的未來擴展規模，並在此過程中進行更透明的溝通。

編輯備註：本文於 2026 年 4 月 28 日更新，以更新 4 月 23 日事件中受影響的儲存庫數量。