【CSDN編者按】10 月下旬，全球最大的同性交友網站

GitHub 掛了

，引得一大批吃瓜群眾圍觀吐槽。很多人紛紛詬病，「GitHub 也不過如此」、「還我代碼」、「微軟收購 GitHub 真是一團糟」等等，叫嚷著 GitHub 給個說法。時隔數日，GitHub 技術總監 Jason Warner 在其官方博客上終於給出了一份姍姍來遲的技術故障解讀。

以下為譯文：

上周，GitHub經歷了一次意外事件，導致服務降級24小時11分鐘。雖然我們平台的一部分沒有受到此次事件的影響，但多個內部系統均受到影響，導致顯示信息陳舊且不一致。萬幸沒有用戶數據丟失；但是，我們依然在手工核對幾秒鐘的數據庫寫入事件。此次事件的主要影響是，GitHub無法提供Webhook事件的服務，也不能構建以及發布GitHub Pages網站。

GitHub所有員工在此謹對受此次事件影響的每個人表達真誠的歉意。我們明白您對GitHub的信任，並自豪地為各位構建彈性系統，以確保我們平台的高可用性。在此次事件中，我們出現了失誤，我們深感抱歉。

雖然我們在很長一段時間內依然無法消除GitHub無法使用而造成的影響，但是我們可以解釋導致此次事件發生的始末，我們吸取的教訓，以及公司採取的相應措施，確保不會再次發生這種情況。

1.背景

大多數面向用戶的GitHub服務都在我們自己的數據中心設施上運行。數據中心的拓撲旨在提供強大且可擴展的邊緣網路，該網路背後是多個區域數據中心，為我們的計算和存儲工作負載提供動力。盡管物理和邏輯組件中設計了多層冗餘，但站點之間仍然可能無法在一段時間內相互通信。

在UTC時間（世界標準時間）10月21日22:52，在日常維護工作中更換發生故障的100G光纖設備時，引發了美國東海岸的網路中心與美國東海岸主要的數據中心之間的連接中斷。這兩個地方之間的連接在43秒後得到了恢復，但是這次短暫的中斷引發了一系列事件，導致了24小時11分鐘的服務降級。

過去，我們曾經討論過如何利用MySQL存儲GitHub的元數據，以及MySQL的高效利用方案。GitHub上運行了多個MySQL集群，其大小從幾百GB到將近5TB不等，每個集群最多有幾十個只讀副本來存儲非Git的元數據，確保我們的應用程序提供拉取請求和問題、管理身份驗證、協調後台處理等服務，還可以提供原始Git對象存儲之外的其他功能。應用程序不同部分的不同數據通過功能分區存儲在各個集群中。

為了提高大規模服務的性能，我們的應用程序會直接寫入每個集群中的主服務器，但在絕大多數情況下讀取請求交由副本服務器處理。我們使用Orchestrator來管理我們的MySQL集群拓撲並處理自動故障轉移。在這個過程中Orchestrator會考慮許多因素，並根據Raft共識算法構建拓撲。 Orchestrator可能會生成應用程序無法支持的拓撲，因此必須謹慎地配置Orchestrator，保證它與應用層的期望一致。

2.事件的時間線

2018年10月21日22:52 UTC

在前面提到的網路分區中，Orchestrator正好在主數據中心激活，並根據Raft共識算法開始了主管者選舉過程。美國西海岸數據中心美國東海岸公共雲Orchestrator節點成功地達到了法定人數，並開始了故障轉移過程，將寫請求直接導向至美國西海岸數據中心。Orchestrator繼續生成美國西海岸的數據庫集群拓撲。在連接恢復後，我們的應用程序將寫入請求導向了西海岸的新的主服務器。

於是，在那一短暫時刻發生的寫操作留在了美國東海岸數據中心的數據庫服務器中，沒有被復制到美國西海岸的數據中心。現在，由於兩個數據中心中的數據庫集群都包含另一個數據中心沒有的寫入數據，因此我們無法安全地將主數據庫重新轉移回美國東海岸數據中心。

2018年10月21日22:54 UTC

我們的內部監控系統開始出現警報，表明我們的系統遇到了大量故障。這時已經有幾位工程師在積極響應並對傳入的通知進行分揀。

到23:02 UTC時，我們的第一響應團隊的工程師已經確定許多數據庫集群的拓撲處於意外狀態。Orchestrator API的查詢結果顯示，數據庫副本拓撲僅包含來自美國西海岸數據中心的服務器。

2018年10月21日23:07 UTC

在這一刻，響應團隊決定手動鎖定我們的內部部署工具，以防止引入其他變化。到23:09 UTC時，響應團隊宣布網站進入黃色狀態。這一舉動會自動將情況升級為意外事件，並向事件協調員發送警報。事件協調員於23:11 UTC加入，並在兩分鐘後宣布此次事件為紅色狀態。

2018年10月21日23:13 UTC

到此為止，我們明白該問題影響了多個數據庫集群，更多來自GitHub數據庫工程團隊工程師加入了戰鬥。他們開始調查當前的狀態，以確定需要採取哪些操作來手動為美國東海岸數據庫的每個集群配置主服務器並重建復制拓撲。這項工作充滿了挑戰，因為到目前為止，西海岸數據庫集群已經接收了應用層近40分鐘的數據寫入。另外，東海岸集群中還存在幾秒鐘的數據寫入，而這些數據沒有復制到西海岸，導致西海岸的數據無法復制到東海岸。

保護用戶數據的機密性和完整性是GitHub的首要任務。為了保護這些數據，我們作出判斷，寫到美國西海岸數據中心的30多分鐘的數據導致我們只能將錯就錯，才能保護用戶數據的安全。但是，在東海岸運行的應用程序依賴於向西海岸的MySQL集群寫入信息，這些應用程序無法應對跨國數據庫調用帶來的額外延遲。因此，這一決定必然會導致許多用戶無法使用我們的服務。我們認為，必須進行大範圍的服務降級，才能保證用戶數據的一致性。

2018年10月21日23:19 UTC

通過查詢數據庫集群的狀態，我們認為我們必須停止運行一切寫入與推送等相關元數據的作業。我們選擇了暫停webhook交付和GitHub Pages構建進行部分降級，以免危害我們已經從用戶收到的數據。換句話說，我們的策略是優先考慮站點可用性和恢復時間的數據完整性。

2018年10月22日00:05 UTC

參與事件響應團隊的工程師開始制定解決數據不一致的計劃，並實施MySQL的故障恢復程序。我們計劃從備份還原，同步兩個數據中心中的副本，退回到穩定的服務拓撲，再繼續處理排隊的作業。我們更新了狀態，以通知用戶我們將執行內部數據存儲系統的受控故障恢復。

雖然MySQL數據備份每四個小時發生一次並保留多年，但備份遠程存儲在公共雲blob存儲服務中。恢復TB級別的備份數據所需的時間導致該過程長達數小時，其中大部分時間用在了遠程備份服務的數據傳輸上。而解壓大型備份文件、校驗和準備並加載到新配置的MySQL服務器上的過程也需要花費大量時間。該過程至少每天都會進行一次測試，因此我們很了解恢復所需的時間，但在這次事故之前我們從來沒遇到過真正需要從備份重建整個集群的情況，一般都是依賴於其他策略，如延遲復制等。

2018年10月22日 00:41 UTC

此時我們已經開始了對所有受影響的MySQL的備份過程，一些工程師在監視該過程的進度。同時還有多個團隊在調查怎樣才能加快數據傳輸和恢復的速度，避免造成更多的服務降級，也避免數據損壞的風險。

2018年10月22日06:51 UTC

東海岸數據中心的幾個集群完成了備份恢復，開始從西海岸復制數據。這導致一些必須執行跨國寫操作的頁面的加載速度變慢，但對於那些需要從這些集群讀取信息的頁面來說，如果讀取請求落在了剛剛恢復的集群上，就能獲得正常的速度。其他大型數據庫集群依然在恢復中。

我們的團隊已經找到了從西海岸直接恢復數據的方法，來避免從離線存儲下載造成的帶寬限制，同時我們也看到了備份恢復即將完成的曙光，而建立健康的復制拓撲的時間只取決於追趕西海岸集群所需的時間了。這個時間與復制的遙測數據呈線性關係，於是我們更新了狀態頁面，表明大約兩個小時之後恢復即可完成。

2018年10月22日 07:46 UTC

GitHub發布的一篇博文（https://blog.github.com/2018-10-21-october21-incident-report）提供了更多信息。我們內部使用GitHub Pages，而幾個小時之前所有網站的構建都被暫停了，所以我們大費周折才成功地發布這篇文章。我們為延遲道歉，本該更早地發布這篇文章，而且以後我們會保證能夠在各種限制下依然能及時地更新我們的進度。

2018年10月22日11:12 UTC

東海岸所有的主數據庫都建立起來了。這樣整個網站就可以響應更多的請求了，因為所有寫請求都會被導至與應用層處於同一物理數據中心的數據庫服務器上。雖然現在性能大幅度提高了，但依然有多個數據庫讀副本落後於主服務器幾個小時。這些延遲的復制會導致用戶看到不一致的信息。我們將讀請求分散到許多讀副本上，所以每個請求都有可能看到延遲幾個小時的副本。

實際上，追趕復制需要的時間不是線性的，而是呈指數形式下降。隨著歐洲和美國的用戶開始工作後，寫請求會大幅度增加，因此恢復過程比預計的長了很多。

2018年10月22日13:15 UTC

現在，我們達到了GitHub.com網站的負載峰值。事故響應團隊討論了處理方案。顯然，復制的延遲並沒有減少，而是在增加，我們開始在美國東海岸的公有雲上部署更多的MySQL讀副本。這些副本上線後，就可以很容易地將讀請求分散到更多服務器上，從而整體減少讀副本的負載，加速復制的進度。

2018年10月22日16:24 UTC

副本同步之後，我們進行了故障恢復，以恢復到以前的拓撲結構，並解決延遲和可用性的問題。我們有意識地在一段時間內提高了數據完整性的優先級，所以在處理積攢下的數據時，服務的狀態依然為紅色。

2018年10月22日16:45 UTC

在恢復階段，我們必須平衡積攢下的數據帶來的越來越多的負載，以及可能會給生態系統的合作夥伴們帶來的大量通知，並盡快讓服務恢復到100%的水平。現在隊列里已經積攢了500萬個webhook事件和八萬多個GitHub Pages構建請求。

重新開始處理數據後，我們處理了大約20萬個超過生命期的webhook負載，結果這些都被拋棄了。發現了這一點後，我們暫停了處理，並且做了更改，暫時增加了webhook的生命期。

為了避免事件惡化，我們依然保持服務降級的狀態，直到處理完所有積攢的數據，並確保服務完全恢復到正常的性能水平。

2018年10月22日23:03 UTC

所有等待的webhook和Pages構建都處理完畢，所有系統的完整和正常工作也得到了確認。網站狀態更新為綠色。

3.下一步

解決數據不一致

在恢復過程中，我們發現受影響集群的MySQL的二進制日志包含了一些主站點的寫入，這些寫入沒有被同步到西海岸。沒有被復制到西海岸的寫入請求數量相對較小。例如，最繁忙的集群之一有954個寫操作受到了影響。

我們現在正在分析這些日志，判斷哪些寫操作能夠被自動同步，哪些需要額外處理。多個團隊參與了這項工作，我們已經分析出了一部分寫操作已經被用戶重復過，從而正確保存了。

這次分析的主要目標是保證用戶保存到GitHub上數據的完整性和準確性。

溝通

為了能在事故過程中給用戶提供一些有用的信息，我們根據積攢數據的處理比率做了一些時間的估算並公開。現在回顧起來，我們的估算並沒有考慮到所有因素。我們為造成的困擾致以歉意，並爭取在以後能夠提供更準確的信息。

技術任務

分析過程中發現了多個技術任務。我們內部依然在進行更廣泛的事故分析，希望能找出更多需要改進的地方。

• 調整Orchestrator的配置，避免跨區域邊界提升主數據庫。Orchestrator的行為完全符合其配置，但我們的應用層無法支持這種拓撲邏輯的改變。在同一區域內的主管者選舉通常是安全的，但突然的跨區域延遲才是這次事故的主要原因。我們以前只從內部網路分區的層次上考慮過這個問題，因此這種行為就成了緊急事故。
• 加快我們狀態報告系統的遷移進度，提供一個更豐富的論壇，讓我們能用更清晰、更明確的語言來溝通事故的狀況。盡管GitHub的許多部分在事故過程中依然可用，但我們只能把狀態設置為綠、黃或紅。我們認識到，這無法給用戶提供準確的信息，無法告訴他們什麼功能可以使用、什麼功能不能使用，所以以後我們會對平台的各個部分分別顯示，讓用戶知道每個服務的狀態。
• 在事故發生前一周，我們啟動了一項全公司範圍的工程任務，以支持多個數據中心的active/active/active架構。該項目的目標是支持設施級別的N+1的冗餘度，從而在不影響用戶的前提下，容忍單一數據中心的完全故障。這項工作需要巨大的努力，而且需要大量時間，但我們相信，多個地理位置上連接良好的數據中心是物有所值的。而這次事故則提高了這項工作的緊迫性。
• 我們將在測試假設方面採取更積極的態度。GitHub是個迅速增長的公司，在過去時間內積攢了非常多的複雜性。隨著我們不斷增長，將各種歷史遺留問題和歷史決策轉移給新員工的難度越來越大。

組織層面的任務

這次事故改變了我們對於網站可靠性的認知。

我們認識到，對於我們這樣複雜的服務，僅憑更緊密的經營控制或更快的響應時間是不夠的。為支持這些工作，我們還會從體制上啟動一項故障驗證工作，保證故障在發生之前就能得到驗證。這項工作會導致GitHub未來在錯誤注入和混亂工程工具方面的投入增加。

結論

我們清楚你們的項目和業務成功十分依賴於GitHub。沒有人比我們對於服務的可用性和數據的正確性更有熱情。我們會繼續分析這次事故，以便今後為你們提供更好的服務，不辜負你們對我們的信任。

原文：https://blog.github.com/2018-10-30-oct21-post-incident-analysis/

作者：Jason Warner，GitHub技術總監。

譯者：彎月，責編：郭芮

_「征稿啦_」

CSDN 公眾號秉持著「與千萬技術人共成長」理念，不僅以「極客頭條」、「暢言」欄目在第一時間以技術人的獨特視角描述技術人關心的行業焦點事件，更有「技術頭條」專欄，深度解讀行業內的熱門技術與場景應用，讓所有的開發者緊跟技術潮流，保持警醒的技術嗅覺，對行業趨勢、技術有更為全面的認知。

如果你有優質的文章，或是行業熱點事件、技術趨勢的真知灼見，或是深度的應用實踐、場景方案等的新見解，歡迎聯繫 CSDN 投稿，聯繫方式：微信（guorui_1118，請備註投稿+姓名+公司職位），郵箱（[email protected]）。