[譯]GitHub應對1.28當機事故的前前後後

原文：January 28th Incident Report

譯者：傑微刊·張勝超

上週GitHub是不能使用了兩個小時6分鐘。我們理解你們有多麼依賴GitHub，並且考慮到服務的可用性也是我們提供的核心功能之一。 在過去的八年裡，我們已經為了確保你和全世界開發者依靠GitHub取得了相當大的進步, 但一週前我們未能維持您期待的正常執行。 我們深感抱歉, 並且願與你分享發生的事件,我們正在採取的措施以確保你能夠訪問GitHub.

事件記錄

在週四00:23am UTC,2016年1月28日(1月27日星期三,4:23pm PST)(1月28日星期四,8:23am 北京時間)我們主要資料中心的系統伺服器和裝置歷經了短暫供電中斷。我們有略超過25%的伺服器和一些網路裝置進行了重啟。 這導致我們的基礎設施部分執行狀態和生成警報傳送給多個待命的工程師。我們的負載均衡裝置和大量的前端應用程式伺服器未受影響,但你們請求的依賴系統服務是不可用。我們的應用程式開始提供HTTP 503狀態程式碼作為響應,把獨角獸的圖片放到你看到的錯誤頁面。

我們初期對這個事件響應是混亂的,我們許多ChatOps系統在重啟伺服器。 我們有內建多餘的ChatOps系統,但這仍然失敗，在剛開始的時候導致我們的響應有一些混亂和延遲。這種延遲最大的面向客戶的影響之一是：直到00:32am UTC(1月28日星期四,8:32am 北京時間)，status.github.com(面向使用者的監控github.com執行狀態的網址)網站狀態不能修改紅色。8分鐘後,網站無法訪問。我們認為這是一個不能接受的長延遲,並且我將確保未來我們的使用者更快的訪問。

無法訪問伺服器的初始通知和連線redis高峰相關的異常，使我們的調查隊把問題定向於內部網路可能中斷。 我們也明白嘗試連線導致網路問題的增加。而後來的調查顯示，DDoS攻擊不是根本問題，我們早就花時間構建的DDOS防禦系統和網路的健康調查。因為我們有經驗來減輕DDoS攻擊，這是我們的現在已經習慣的反應過程，我們很高興可以迅速行動和一心一意地努力解決這一事件。

啟動我們的DDoS攻擊的防禦，反應小組開始有條不紊地檢查我們的基礎設施和那些已經回到初始故障相關的警報。無法到達的幾個redis叢集的所有成員帶領我們調查整個設施裝置的正常執行時間。我們發現一些伺服器報告正常執行時間是幾分鐘,但是我們的網路裝置無故障執行時間報告,顯示他們沒有重啟。利用這一點，我們認為所有的離線伺服器共享相同的硬體類，和那些啟動沒有問題是一個不同的硬體類。受影響的伺服器有多架排在我們的資料中心，儘管叢集成員被分佈在不同的機架，還是導致一些叢集經歷了他們所有的成員伺服器重啟。.

隨著時間的流逝,我們注意到我們的應用程式程式並沒有像預期的那樣啟動。 工程師開始在我們的應用程式伺服器上檢視程式表和日誌。這就是說後端能力不足是由於我們的Redis叢集離線導致程式無法啟動。我們無意地在應用程式程式碼的引導路徑中增加了一個強型依賴Redis群集。

通過這一點，我們就有了一個很清楚恢復服務的思路，並且朝著結束而工作。 我們需要修復沒有啟動的伺服器，我們需要讓Redis叢集來讓我們的應用程式啟動。 由於物理驅動器已不認可，遠端訪問控制檯截圖從失敗的硬體顯示啟動故障。 一組工程師與現場裝置技術人員分開工作，以使這些伺服器通過漸進的跳蚤電力，使他們從無狀態中喚醒，這樣的磁碟就顯示了出來。另一組工程師開始重新構建受影響的redis叢集硬體改造。這些工作中最困難的關鍵是內部系統在離線硬體上。這使得配置新的伺服器更困難。

一旦Redis叢集資料還原到備用裝置上，我們就能夠把redis伺服器程式重新上線。內部檢查顯示應用程式恢復，並從應用伺服器正常的反應使我們HAProxy負載均衡器返回這些伺服器的後端伺服器池。經過驗證的網站操作，維護頁面被刪除，我們移動到狀態黃色。這發生在2小時6分鐘後，最初的電力中斷。

在接下來的幾個小時裡，確認所有系統都正常執行，並驗證了沒有資料丟失這一事件。我們非常感謝工程師們在保證所有的程式碼、issues、拉請求( pull requests)以及其他關鍵資料的安全和安全的地方，我們的減輕災難工作是成功的。

未來工作

複雜系統的定義是由許多分立元件的相互共同作用來實現的結果。理解一個複雜的系統中的每個元件的依賴關係是重要的，但除非這些依賴關係進行嚴格的測試，可能的系統故障在獨特的和新穎的方式。在過去的一週裡，我們已經投入了大量的時間和精力去了解連鎖故障導致GitHub不可用兩個多小時的性質。我們不相信這是完全可以防止的事件，導致在我們的基礎設施的一個很大一部分失去能力，但我們可以採取措施，以確保恢復發生在一個快速和可靠的方式。我們還可以採取措施，減輕這些事件對我們的使用者帶來的負面影響。

我們確定了硬體的問題，導致伺服器無法檢視自己的驅動器後，功率迴圈作為一個已知的韌體問題，我們正在更新我們的艦隊。更新我們的工具自動在新韌體更新可用的團隊開放的問題將迫使我們對我們環境的更新記錄。

我們將更新我們的應用程式的測試套件，即使某些外部系統是不可用的，也要明確確保我們的應用程式啟動，我們正在改善我們的電路斷路器，這樣我們就可以優雅地降低功能，當這些後端服務。顯然，這種方法有限制，存在一個最小的需要服務請求的要求，但我們可以積極地減少這些依賴關係的列表。

我們正在複查我們的內部系統可用性的必要條件，負責關鍵業務的任務。如配置新的伺服器，使他們與我們的使用者面臨的系統。最終，如果這些系統需要從一個意外中斷的情況中恢復，他們必須是可靠的系統被回收。

一些小的技術改進也正在實施。改善跨部門溝通會縮短恢復時間。預定的升級方案在所有需要的人手準備齊全的情況下使我們的事件協調員要花更多的時間管理恢復工作和更少的時間瀏覽文件。在這個事件中，提高我們的資訊傳遞給你有助於你更好地瞭解發生了什麼，期待未來的更新。

總結

我們瞭解GitHub在您的專案和企業成功的工作流程中是多麼的重要。我們都希望GitHub為該中斷的影響道歉。我們將繼續分析導致這一事件的事件和我們採取的措施，以恢復服務。這項工作將引導我們完善GitHub的系統和過程。

更多精彩內容~