在2017年2月時,GitLab傳出誤刪資料事件,導致損失300GB正式環境數據,也波及超過五千個軟體專案。而天有不測風雲,這一次苦主輪到GitHub。從昨日(10/22)清晨7點開始,GitHub服務開始出現異常,直到今日清晨7點才回歸正常運作,當機將近24小時。從昨日事件爆發,系統回報錯誤比例開始提升時,GitHub就著手介入調查,同時展開維修工作。

而GitHub技術副總裁Jason Warner也親自在GitHub部落格上撰文,解釋事發經過。他表示,事發初期,GitHub.com上面部分服務已出現異常,接著資料庫也開始故障。接獲許多系統警戒後,GitHub當機立斷採取行動,藉以保障使用者資料的一致性。

故障期間,雖然GitHub頁面上未能呈現完整資訊,不過Jason Warner表示,沒有任何使用者數據遺失。Git儲存庫也維持運作,事發期間仍可進行存取。不過,用以儲存網頁中介資料的MySQL資料庫故障下,Issue及合併請求這兩個功能則無法正常運作。

GitHub對開源社群的重要度不在話下,許多重要開源專案都選用GitHub作為協作平臺。Jason Warner表示,該公司已開始進行調查,未來幾天就會發布事件報告。

事故第一階段臺灣時間10/22 7~14點:出現故障

從臺灣時間清晨7點(CST時間)起,系統錯誤率提升,GitHub開始進行故障轉移,著手搬遷資料儲存系統,試圖讓開發者能重新存取服務。歷經3小時後,工程團隊開始維修資料儲存系統。

事故第二階段10/22 14~23點:展開復原,但比預期耗時更久

到了下午2點51分,搶修時間已經超過7小時,GitHub已經進入復原工作的尾聲。目標在下午5點前完成資料一致性的復原工作。不過復原工作比GitHub預期的還耗時。

事故第三階段10/23 0~2點:完成資料一致性復原

剛過23日,GitHub完成資料一致性的復原工作。當中GitHub一度終止Webhook的運作,直到凌晨2點26分又再重新啟用。

事故第四階段10/23 2~7點:修復Github網頁

從凌晨2點40分起至清晨5點46分,GitHub團隊都在著手修復GitHub網頁,同步監控頁面的修復狀況。到了今日清晨7點03分,系統重新上軌運作。


Advertisement

更多 iThome相關內容