就在年假即將收假的昨天(2017年2月1日),網路上發生了一件堪稱工程師惡夢的事件。 在業界常被用來當程式碼版本控制倉庫的GitLab網站,因為各種意想不到的狀況,突然停止服務了。GitLab服務離線,首當其衝的就是使用GitLab儲存程式碼的個人與單位;如果沒有本地備份或是備援機制,放在GitLab的程式碼、issue tickets與commit logs,就相當於從網路世界中憑空消失。 災難發生 根據 GitLab 所提供的事件紀錄,GitLab 工程師在台北時間2月1日凌晨五點時進行資料庫維護作業,刪除一批造成資料庫異常負載的大量spam users;起初操作都沒甚麼問題,工程師即開始進行資料庫清理作業[footnote]PostgreSQL 刪除資料行後不會立即釋放空間,而是標記為刪除;當垃圾資料量過大時,可能會造成讀寫效能低落,因此需要設定定期自動清理,或是手動下指令清理,減少資料檔案的容量。[/footnote]。
GitLab服務災難與危機處理的啟示:開誠布公,才能贏回信任
GitLab服務災難與危機處理的啟示:開誠布公,才能贏回信任
GitLab服務災難與危機處理的啟示:開誠布公,才能贏回信任
就在年假即將收假的昨天(2017年2月1日),網路上發生了一件堪稱工程師惡夢的事件。 在業界常被用來當程式碼版本控制倉庫的GitLab網站,因為各種意想不到的狀況,突然停止服務了。GitLab服務離線,首當其衝的就是使用GitLab儲存程式碼的個人與單位;如果沒有本地備份或是備援機制,放在GitLab的程式碼、issue tickets與commit logs,就相當於從網路世界中憑空消失。 災難發生 根據 GitLab 所提供的事件紀錄,GitLab 工程師在台北時間2月1日凌晨五點時進行資料庫維護作業,刪除一批造成資料庫異常負載的大量spam users;起初操作都沒甚麼問題,工程師即開始進行資料庫清理作業[footnote]PostgreSQL 刪除資料行後不會立即釋放空間,而是標記為刪除;當垃圾資料量過大時,可能會造成讀寫效能低落,因此需要設定定期自動清理,或是手動下指令清理,減少資料檔案的容量。[/footnote]。