原文：January 28th Incident Report
譯者：杰微刊·張勝超
上周GitHub是不能使用了兩個(gè)小時(shí)6分鐘痹栖。我們理解你們有多么依賴(lài)GitHub惫撰，并且考慮到服務(wù)的可用性也是我們提供的核心功能之一。 在過(guò)去的八年里模软，我們已經(jīng)為了確保你和全世界開(kāi)發(fā)者依靠GitHub取得了相當(dāng)大的進(jìn)步, 但一周前我們未能維持您期待的正常運(yùn)行伟骨。 我們深感抱歉, 并且愿與你分享發(fā)生的事件,我們正在采取的措施以確保你能夠訪問(wèn)GitHub.
事件記錄
在周四00:23am UTC,2016年1月28日(1月27日星期三,4:23pm PST)(1月28日星期四,8:23am 北京時(shí)間)我們主要數(shù)據(jù)中心的系統(tǒng)服務(wù)器和設(shè)備歷經(jīng)了短暫供電中斷。我們有略超過(guò)25%的服務(wù)器和一些網(wǎng)絡(luò)設(shè)備進(jìn)行了重啟燃异。 這導(dǎo)致我們的基礎(chǔ)設(shè)施部分運(yùn)行狀態(tài)和生成警報(bào)發(fā)送給多個(gè)待命的工程師携狭。我們的負(fù)載均衡設(shè)備和大量的前端應(yīng)用程序服務(wù)器未受影響,但你們請(qǐng)求的依賴(lài)系統(tǒng)服務(wù)是不可用。我們的應(yīng)用程序開(kāi)始提供HTTP 503狀態(tài)代碼作為響應(yīng),把獨(dú)角獸的圖片放到你看到的錯(cuò)誤頁(yè)面回俐。
我們初期對(duì)這個(gè)事件響應(yīng)是混亂的,我們?cè)S多ChatOps系統(tǒng)在重啟服務(wù)器逛腿。 我們有內(nèi)置多余的ChatOps系統(tǒng),但這仍然失敗，在剛開(kāi)始的時(shí)候?qū)е挛覀兊捻憫?yīng)有一些混亂和延遲仅颇。這種延遲最大的面向客戶(hù)的影響之一是：直到00:32am UTC(1月28日星期四,8:32am 北京時(shí)間)单默，status.github.com(面向用戶(hù)的監(jiān)控github.com運(yùn)行狀態(tài)的網(wǎng)址)網(wǎng)站狀態(tài)不能修改紅色。8分鐘后,網(wǎng)站無(wú)法訪問(wèn)忘瓦。我們認(rèn)為這是一個(gè)不能接受的長(zhǎng)延遲,并且我將確保未來(lái)我們的用戶(hù)更快的訪問(wèn)搁廓。
無(wú)法訪問(wèn)服務(wù)器的初始通知和連接redis高峰相關(guān)的異常，使我們的調(diào)查隊(duì)把問(wèn)題定向于內(nèi)部網(wǎng)絡(luò)可能中斷耕皮。 我們也明白嘗試連接導(dǎo)致網(wǎng)絡(luò)問(wèn)題的增加境蜕。而后來(lái)的調(diào)查顯示，DDoS攻擊不是根本問(wèn)題凌停，我們?cè)缇突〞r(shí)間構(gòu)建的DDOS防御系統(tǒng)和網(wǎng)絡(luò)的健康調(diào)查汽摹。因?yàn)槲覀冇薪?jīng)驗(yàn)來(lái)減輕DDoS攻擊，這是我們的現(xiàn)在已經(jīng)習(xí)慣的反應(yīng)過(guò)程苦锨，我們很高興可以迅速行動(dòng)和一心一意地努力解決這一事件逼泣。
啟動(dòng)我們的DDoS攻擊的防御，反應(yīng)小組開(kāi)始有條不紊地檢查我們的基礎(chǔ)設(shè)施和那些已經(jīng)回到初始故障相關(guān)的警報(bào)舟舒。無(wú)法到達(dá)的幾個(gè)redis集群的所有成員帶領(lǐng)我們調(diào)查整個(gè)設(shè)施設(shè)備的正常運(yùn)行時(shí)間拉庶。我們發(fā)現(xiàn)一些服務(wù)器報(bào)告正常運(yùn)行時(shí)間是幾分鐘,但是我們的網(wǎng)絡(luò)設(shè)備無(wú)故障運(yùn)行時(shí)間報(bào)告,顯示他們沒(méi)有重啟。利用這一點(diǎn)秃励，我們認(rèn)為所有的離線服務(wù)器共享相同的硬件類(lèi)氏仗，和那些啟動(dòng)沒(méi)有問(wèn)題是一個(gè)不同的硬件類(lèi)。受影響的服務(wù)器有多架排在我們的數(shù)據(jù)中心，盡管集群成員被分布在不同的機(jī)架皆尔，還是導(dǎo)致一些集群經(jīng)歷了他們所有的成員服務(wù)器重啟呐舔。.
隨著時(shí)間的流逝,我們注意到我們的應(yīng)用程序進(jìn)程并沒(méi)有像預(yù)期的那樣啟動(dòng)。 工程師開(kāi)始在我們的應(yīng)用程序服務(wù)器上查看進(jìn)程表和日志慷蠕。這就是說(shuō)后端能力不足是由于我們的Redis集群離線導(dǎo)致進(jìn)程無(wú)法啟動(dòng)珊拼。我們無(wú)意地在應(yīng)用程序代碼的引導(dǎo)路徑中增加了一個(gè)強(qiáng)型依賴(lài)Redis群集。
通過(guò)這一點(diǎn)流炕，我們就有了一個(gè)很清楚恢復(fù)服務(wù)的思路澎现，并且朝著結(jié)束而工作。 我們需要修復(fù)沒(méi)有啟動(dòng)的服務(wù)器每辟，我們需要讓Redis集群來(lái)讓我們的應(yīng)用程序啟動(dòng)剑辫。 由于物理驅(qū)動(dòng)器已不認(rèn)可，遠(yuǎn)程訪問(wèn)控制臺(tái)截圖從失敗的硬件顯示啟動(dòng)故障渠欺。 一組工程師與現(xiàn)場(chǎng)設(shè)備技術(shù)人員分開(kāi)工作妹蔽，以使這些服務(wù)器通過(guò)漸進(jìn)的跳蚤電力，使他們從無(wú)狀態(tài)中喚醒挠将，這樣的磁盤(pán)就顯示了出來(lái)讹开。另一組工程師開(kāi)始重新構(gòu)建受影響的redis集群硬件改造。這些工作中最困難的關(guān)鍵是內(nèi)部系統(tǒng)在離線硬件上捐名。這使得配置新的服務(wù)器更困難旦万。
一旦Redis集群數(shù)據(jù)還原到備用設(shè)備上，我們就能夠把redis服務(wù)器進(jìn)程重新上線镶蹋。內(nèi)部檢查顯示應(yīng)用程序恢復(fù)成艘，并從應(yīng)用服務(wù)器正常的反應(yīng)使我們HAProxy負(fù)載均衡器返回這些服務(wù)器的后端服務(wù)器池。經(jīng)過(guò)驗(yàn)證的網(wǎng)站操作贺归，維護(hù)頁(yè)面被刪除淆两，我們移動(dòng)到狀態(tài)黃色。這發(fā)生在2小時(shí)6分鐘后拂酣，最初的電力中斷秋冰。
在接下來(lái)的幾個(gè)小時(shí)里，確認(rèn)所有系統(tǒng)都正常運(yùn)行婶熬，并驗(yàn)證了沒(méi)有數(shù)據(jù)丟失這一事件剑勾。我們非常感謝工程師們?cè)诒ＷC所有的代碼、issues赵颅、拉請(qǐng)求( pull requests)以及其他關(guān)鍵數(shù)據(jù)的安全和安全的地方虽另，我們的減輕災(zāi)難工作是成功的。
未來(lái)工作
復(fù)雜系統(tǒng)的定義是由許多分立組件的相互共同作用來(lái)實(shí)現(xiàn)的結(jié)果饺谬。理解一個(gè)復(fù)雜的系統(tǒng)中的每個(gè)組件的依賴(lài)關(guān)系是重要的捂刺，但除非這些依賴(lài)關(guān)系進(jìn)行嚴(yán)格的測(cè)試，可能的系統(tǒng)故障在獨(dú)特的和新穎的方式。在過(guò)去的一周里族展，我們已經(jīng)投入了大量的時(shí)間和精力去了解連鎖故障導(dǎo)致GitHub不可用兩個(gè)多小時(shí)的性質(zhì)森缠。我們不相信這是完全可以防止的事件，導(dǎo)致在我們的基礎(chǔ)設(shè)施的一個(gè)很大一部分失去能力仪缸，但我們可以采取措施贵涵，以確保恢復(fù)發(fā)生在一個(gè)快速和可靠的方式腹殿。我們還可以采取措施独悴，減輕這些事件對(duì)我們的用戶(hù)帶來(lái)的負(fù)面影響例书。
我們確定了硬件的問(wèn)題锣尉，導(dǎo)致服務(wù)器無(wú)法查看自己的驅(qū)動(dòng)器后，功率循環(huán)作為一個(gè)已知的固件問(wèn)題决采，我們正在更新我們的艦隊(duì)自沧。更新我們的工具自動(dòng)在新固件更新可用的團(tuán)隊(duì)開(kāi)放的問(wèn)題將迫使我們對(duì)我們環(huán)境的更新記錄。
我們將更新我們的應(yīng)用程序的測(cè)試套件树瞭，即使某些外部系統(tǒng)是不可用的拇厢，也要明確確保我們的應(yīng)用程序啟動(dòng)，我們正在改善我們的電路斷路器晒喷，這樣我們就可以?xún)?yōu)雅地降低功能孝偎，當(dāng)這些后端服務(wù)。顯然凉敲，這種方法有限制衣盾，存在一個(gè)最小的需要服務(wù)請(qǐng)求的要求，但我們可以積極地減少這些依賴(lài)關(guān)系的列表爷抓。
我們正在復(fù)查我們的內(nèi)部系統(tǒng)可用性的必要條件势决，負(fù)責(zé)關(guān)鍵業(yè)務(wù)的任務(wù)。如配置新的服務(wù)器蓝撇，使他們與我們的用戶(hù)面臨的系統(tǒng)果复。最終，如果這些系統(tǒng)需要從一個(gè)意外中斷的情況中恢復(fù)渤昌，他們必須是可靠的系統(tǒng)被回收侯谁。
一些小的技術(shù)改進(jìn)也正在實(shí)施轩褐。改善跨部門(mén)溝通會(huì)縮短恢復(fù)時(shí)間。預(yù)定的升級(jí)方案在所有需要的人手準(zhǔn)備齊全的情況下使我們的事件協(xié)調(diào)員要花更多的時(shí)間管理恢復(fù)工作和更少的時(shí)間瀏覽文檔。在這個(gè)事件中报腔，提高我們的信息傳遞給你有助于你更好地了解發(fā)生了什么，期待未來(lái)的更新扑庞。
總結(jié)
我們了解GitHub在您的項(xiàng)目和企業(yè)成功的工作流程中是多么的重要氏淑。我們都希望GitHub為該中斷的影響道歉。我們將繼續(xù)分析導(dǎo)致這一事件的事件和我們采取的措施，以恢復(fù)服務(wù)骇径。這項(xiàng)工作將引導(dǎo)我們完善GitHub的系統(tǒng)和過(guò)程躯肌。
