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

[[248425]]

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

背景情況

面向用戶的GitHub服務(wù)大多數(shù)在我們自己的數(shù)據(jù)中心設(shè)施中運行。數(shù)據(jù)中心拓?fù)浣Y(jié)構(gòu)旨在提供一個強大且可擴(kuò)展的邊緣網(wǎng)絡(luò)，該網(wǎng)絡(luò)在幾個區(qū)域數(shù)據(jù)中心的前端運行，為處理我們的計算和存儲工作負(fù)載提供支持。盡管該設(shè)計中的物理和邏輯部件已內(nèi)置了多層冗余機制，但站點仍然有可能有一段時間無法彼此聯(lián)系。

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

GitHub網(wǎng)絡(luò)架構(gòu)的大體描述，包括兩個物理數(shù)據(jù)中心、3個接入點(POP，又譯入網(wǎng)點)以及通過對等互聯(lián)(peering)的多個區(qū)域中的云容量。

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

為了大規(guī)模提高性能，我們的應(yīng)用程序?qū)懭胍矫總€集群的相關(guān)主系統(tǒng)，但在絕大多數(shù)情況下，將讀取請求委派給一小部分的副本服務(wù)器。我們使用Orchestrator來管理我們的MySQL集群拓?fù)浣Y(jié)構(gòu)，并處理自動故障切換。Orchestrator在此過程中考慮了諸多變化因素，并建立在Raft之上以確保共識。Orchestrator可以實現(xiàn)應(yīng)用程序無法支持的拓?fù)浣Y(jié)構(gòu)，因此必須小心謹(jǐn)慎，讓Orchestrator的配置與應(yīng)用程序級別的期望保持一致。

事件時間線

10月21日22:52 UTC：

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

10月21日22:54 UTC

內(nèi)部監(jiān)控系統(tǒng)開始發(fā)出警報，表明系統(tǒng)遇到眾多故障。工程師查明，眾多數(shù)據(jù)庫集群的拓?fù)浣Y(jié)構(gòu)處于意外的狀態(tài)。查詢Orchestrator API后顯示，數(shù)據(jù)庫復(fù)制拓?fù)浣Y(jié)構(gòu)只包括來自西海岸數(shù)據(jù)中心的服務(wù)器。

10月21日23:07 UTC

響應(yīng)團(tuán)隊決定手動鎖住內(nèi)部部署工具，以防出現(xiàn)任何另外的變化。響應(yīng)團(tuán)隊將網(wǎng)站置于黃色警報狀態(tài)。情形自動升級為活躍事件，并向事件協(xié)調(diào)員發(fā)出警報。事件協(xié)調(diào)員加入進(jìn)來，2分鐘后決定換成紅色警報狀態(tài)。

10月21日23:13 UTC

這時我們知道這個問題影響了多個數(shù)據(jù)庫集群。GitHub數(shù)據(jù)庫工程團(tuán)隊的工程師開始調(diào)查現(xiàn)狀，以便搞清楚需要采取什么措施，才能手動配置東海岸的數(shù)據(jù)庫作為每個集群的主數(shù)據(jù)庫，并重新構(gòu)建復(fù)制拓?fù)浣Y(jié)構(gòu)。東海岸集群中的幾秒寫入數(shù)據(jù)沒有復(fù)制到西海岸，因而新寫入數(shù)據(jù)無法復(fù)制回到東海岸。

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

10月21日23:19 UTC

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

10月22日00:05 UTC

事件響應(yīng)團(tuán)隊的工程師開始制定計劃以解決數(shù)據(jù)不一致性，并為MySQL落實故障切換程序。我們更新了狀態(tài)，告知用戶我們將對內(nèi)部數(shù)據(jù)存儲系統(tǒng)執(zhí)行有節(jié)制的故障切換。

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

10月22日00:41 UTC

開始對所有受影響的MySQL集群進(jìn)行備份。同時，多個工程師團(tuán)隊設(shè)法縮短傳輸和恢復(fù)時間，又不進(jìn)一步降低網(wǎng)站可用性或?qū)е聰?shù)據(jù)損壞。

10月22日06:51 UTC

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

10月22日11:12 UTC

所有主數(shù)據(jù)庫在東海岸再次建立。由于寫入內(nèi)容現(xiàn)在被引到與我們的應(yīng)用層在同一物理數(shù)據(jù)中心的數(shù)據(jù)庫服務(wù)器，這導(dǎo)致網(wǎng)站響應(yīng)極其緩慢。仍有眾多數(shù)據(jù)庫讀取副本比主數(shù)據(jù)庫延遲幾小時，因而導(dǎo)致用戶看到不一致的數(shù)據(jù)。我們將讀取負(fù)載分?jǐn)偟烬嫶蟮淖x取副本池上，針對我們服務(wù)的每個請求就很有可能“命中”延遲幾小時的讀取副本。

10月22日13:15 UTC

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

10月22日16:24 UTC

副本同步后，我們切換到原始拓?fù)浣Y(jié)構(gòu)，以解決延遲/可用性問題。我們開始處理積壓的數(shù)據(jù)時，讓服務(wù)繼續(xù)處于紅色警報狀態(tài)。

10月22日16:45 UTC

我們不得不均衡分?jǐn)倲?shù)據(jù)積壓帶來的更大負(fù)載，讓服務(wù)盡快回到100%的可用性。排入隊列的有500多萬個鉤子事件和8000多個Pages構(gòu)建。

我們在重新處理這些數(shù)據(jù)時，處理了約200000個因超出內(nèi)部TTL而丟棄的Web鉤子載荷。一發(fā)現(xiàn)這個問題，我們暫停了處理工作，暫時調(diào)高了該TTL。

為了避免進(jìn)一步影響狀態(tài)更新的可靠性，我們?nèi)蕴幱谛阅芙导墵顟B(tài)，直到處理完全部積壓的數(shù)據(jù)，并確保服務(wù)明顯回到正常的性能級別。

10月22日23:03 UTC

所有待處理的Web鉤子和Pages構(gòu)建已處理完畢，所有系統(tǒng)的完整性和正常操作運行已得到了核實。網(wǎng)站狀態(tài)更新到綠色，以示正常。

結(jié)束語

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