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

[[248425]]

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

背景情況

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

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

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

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

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

事件時(shí)間線

10月21日22:52 UTC：

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

10月21日22:54 UTC

內(nèi)部監(jiān)控系統(tǒng)開始發(fā)出警報(bào)，表明系統(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)隊(duì)決定手動(dòng)鎖住內(nèi)部部署工具，以防出現(xiàn)任何另外的變化。響應(yīng)團(tuán)隊(duì)將網(wǎng)站置于黃色警報(bào)狀態(tài)。情形自動(dòng)升級(jí)為活躍事件，并向事件協(xié)調(diào)員發(fā)出警報(bào)。事件協(xié)調(diào)員加入進(jìn)來，2分鐘后決定換成紅色警報(bào)狀態(tài)。

10月21日23:13 UTC

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

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

10月21日23:19 UTC

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

10月22日00:05 UTC

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

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

10月22日00:41 UTC

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

10月22日06:51 UTC

在東海岸數(shù)據(jù)中心，幾個(gè)集群完成了靠備份恢復(fù)的工作，開始復(fù)制來自西海岸的新數(shù)據(jù)。這導(dǎo)致對(duì)于在跨越全國的鏈路上執(zhí)行寫入操作的頁面而言，網(wǎng)站加載時(shí)間緩慢，但如果讀取請(qǐng)求出現(xiàn)在剛恢復(fù)的副本上，從那些數(shù)據(jù)庫集群讀取數(shù)據(jù)的頁面會(huì)返回最新結(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ù)庫延遲幾小時(shí)，因而導(dǎo)致用戶看到不一致的數(shù)據(jù)。我們將讀取負(fù)載分?jǐn)偟烬嫶蟮淖x取副本池上，針對(duì)我們服務(wù)的每個(gè)請(qǐng)求就很有可能“命中”延遲幾小時(shí)的讀取副本。

10月22日13:15 UTC

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

10月22日16:24 UTC

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

10月22日16:45 UTC

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

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

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

10月22日23:03 UTC

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

結(jié)束語

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