GitHub資料庫全球大當機24小時，MySQL資料庫異常，波及Issue、合併請求功能失效

在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分，系統重新上軌運作。