上周，GitHub經歷了一次故障事件，導致服務質量下降了24小時又11分鐘。雖然我們平臺的某些部分不受此事件影響，但多個內部系統還是受到了影響，導致我們顯示過時且不一致的信息。最終，用戶數據沒有丟失;然而，數據庫寫入操作還是出現了幾秒鐘的手動協調。就事件過程中的大多數時間而言，GitHub也無法處理Web鉤子(webhook)事件，也無法構建和發布GitHub Pages網站。

[[248425]]

我們GitHub的所有人都為這次事件給您們每個人帶來的影響深表歉意。我們深智您們對GitHub寄予的信任，并為構建的彈性系統讓我們平臺能夠保持高可用性而引以為豪。但在這次事件中，我們讓您們失望了，對此深感抱歉。雖然我們消除不了GitHub平臺長時間無法使用所帶來的問題，但我們可以解釋導致此事件發生的事件、吸取的教訓以及我們公司采取的步驟，以便更好地確保不再發生這種情況。

背景情況

面向用戶的GitHub服務大多數在我們自己的數據中心設施中運行。數據中心拓撲結構旨在提供一個強大且可擴展的邊緣網絡，該網絡在幾個區域數據中心的前端運行，為處理我們的計算和存儲工作負載提供支持。盡管該設計中的物理和邏輯部件已內置了多層冗余機制，但站點仍然有可能有一段時間無法彼此聯系。

10月21日22：52UTC，由于100G光設備出故障，更換該設備的日常維護工作導致我們的美國東海岸網絡中心與我們主要的美國東海岸數據中心之間的連接斷開。這兩個地方之間的連接在43秒后恢復正常，但正是這次短暫的故障引發了一系列事件，導致服務質量下降了24小時又11分鐘。

GitHub網絡架構的大體描述，包括兩個物理數據中心、3個接入點(POP，又譯入網點)以及通過對等互聯(peering)的多個區域中的云容量。

在過去，我們已討論了我們如何使用MySQL來存儲GitHub元數據以及為確保MySQL高可用性采用的方法。GitHub運行多個MySQL集群，集群大小從幾百GB到約5TB不等，每個集群最多有幾十個讀取副本來存儲非Git元數據，因此我們的應用程序可以提供合并請求(pull request)和問題單(issue)、管理身份驗證、協調后臺處理，并且提供原始Git對象存儲之外的其他功能。應用程序不同部分的不同數據通過功能分區(sharding)存儲在各個集群上。

為了大規模提高性能，我們的應用程序將寫入引到每個集群的相關主系統，但在絕大多數情況下，將讀取請求委派給一小部分的副本服務器。我們使用Orchestrator來管理我們的MySQL集群拓撲結構，并處理自動故障切換。Orchestrator在此過程中考慮了諸多變化因素，并建立在Raft之上以確保共識。Orchestrator可以實現應用程序無法支持的拓撲結構，因此必須小心謹慎，讓Orchestrator的配置與應用程序級別的期望保持一致。

事件時間線

10月21日22:52 UTC：

美國東海岸數據中心的數據庫服務器含有無法復制到西海岸數據中心的短暫寫入內容。由于兩個數據中心中的數據庫集群現在含有另一個數據中心中沒有的寫入內容，我們在故障后無法將主數據庫安全地切換到東海岸數據中心。

10月21日22:54 UTC

內部監控系統開始發出警報，表明系統遇到眾多故障。工程師查明，眾多數據庫集群的拓撲結構處于意外的狀態。查詢Orchestrator API后顯示，數據庫復制拓撲結構只包括來自西海岸數據中心的服務器。

10月21日23:07 UTC

響應團隊決定手動鎖住內部部署工具，以防出現任何另外的變化。響應團隊將網站置于黃色警報狀態。情形自動升級為活躍事件，并向事件協調員發出警報。事件協調員加入進來，2分鐘后決定換成紅色警報狀態。

10月21日23:13 UTC

這時我們知道這個問題影響了多個數據庫集群。GitHub數據庫工程團隊的工程師開始調查現狀，以便搞清楚需要采取什么措施，才能手動配置東海岸的數據庫作為每個集群的主數據庫，并重新構建復制拓撲結構。東海岸集群中的幾秒寫入數據沒有復制到西海岸，因而新寫入數據無法復制回到東海岸。

對于絕大多數數據庫調用而言，在東海岸運行、依賴將信息寫入到西海岸MySQL集群的應用程序目前無法處理橫越全國的往回帶來的額外延遲。因此導致許多用戶無法使用我們的服務。但為了確保用戶數據的一致性，我們認為延長服務降級的時間是必要的。

10月21日23:19 UTC

查詢數據庫集群的狀態后，我們顯然需要停止運行中的任務，這些任務在寫入關于推送等操作的元數據。我們明確決定，暫停Web鉤子傳送和GitHub Pages構建，局部降低網站可用性，而不是危及我們已經從用戶處收到的數據。換句話說，數據完整性比網站可用性和恢復時間來得更重要。

10月22日00:05 UTC

事件響應團隊的工程師開始制定計劃以解決數據不一致性，并為MySQL落實故障切換程序。我們更新了狀態，告知用戶我們將對內部數據存儲系統執行有節制的故障切換。

雖然MySQL數據每隔4小時備份一次、保留多年，但備份內容存儲在異地的公共云存儲服務中。恢復數TB備份數據花了幾小時，時間主要花在了傳輸來自遠程備份服務的數據上。解壓縮、校驗和、準備以及將龐大備份文件裝入到剛配置好的MySQL服務器上用去了大部分的時間。

10月22日00:41 UTC

開始對所有受影響的MySQL集群進行備份。同時，多個工程師團隊設法縮短傳輸和恢復時間，又不進一步降低網站可用性或導致數據損壞。

10月22日06:51 UTC

在東海岸數據中心，幾個集群完成了靠備份恢復的工作，開始復制來自西海岸的新數據。這導致對于在跨越全國的鏈路上執行寫入操作的頁面而言，網站加載時間緩慢，但如果讀取請求出現在剛恢復的副本上，從那些數據庫集群讀取數據的頁面會返回最新結果。其他較龐大的數據庫集群仍在恢復中。

10月22日11:12 UTC

所有主數據庫在東海岸再次建立。由于寫入內容現在被引到與我們的應用層在同一物理數據中心的數據庫服務器，這導致網站響應極其緩慢。仍有眾多數據庫讀取副本比主數據庫延遲幾小時，因而導致用戶看到不一致的數據。我們將讀取負載分攤到龐大的讀取副本池上，針對我們服務的每個請求就很有可能“命中”延遲幾小時的讀取副本。

10月22日13:15 UTC

這時GitHub.com上的流量負載接近峰值。復制延遲在增加，而不是逐步降低。我們開始在東海岸公共云配置更多的MySQL讀取副本。

10月22日16:24 UTC

副本同步后，我們切換到原始拓撲結構，以解決延遲/可用性問題。我們開始處理積壓的數據時，讓服務繼續處于紅色警報狀態。

10月22日16:45 UTC

我們不得不均衡分攤數據積壓帶來的更大負載，讓服務盡快回到100%的可用性。排入隊列的有500多萬個鉤子事件和8000多個Pages構建。

我們在重新處理這些數據時，處理了約200000個因超出內部TTL而丟棄的Web鉤子載荷。一發現這個問題，我們暫停了處理工作，暫時調高了該TTL。

為了避免進一步影響狀態更新的可靠性，我們仍處于性能降級狀態，直到處理完全部積壓的數據，并確保服務明顯回到正常的性能級別。

10月22日23:03 UTC

所有待處理的Web鉤子和Pages構建已處理完畢，所有系統的完整性和正常操作運行已得到了核實。網站狀態更新到綠色，以示正常。

結束語

我們知道您們的項目和公司多么依賴GitHub。我們服務的可用性和您們數據的正確性備受關注。我們將繼續分析這次事件，以便有機會為您們提供更好的服務，并不負寄予我們的信任。