原文：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的系統和過程。