[譯]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的系統和過程。

更多精彩內容~