GitLab 史上最大危機:工程師誤刪大量資料,導致線上服務崩潰

作者 | 發布日期 2017 年 02 月 03 日 18:06 | 分類 科技教育 , 網路 , 軟體、系統 follow us in feedly

1 月 31 日晚上恐怕是知名程式源碼代管服務網站 GitLab 最長的一夜,因為一位工程師的疏忽造成大量資料流失,而又發現所有備份方案都無效而崩潰。



在太平洋時間的 31 日晚上,該公司陸續發布了如下一系列震驚大家的推特文:

幕後完整的故事是這樣子的:當晚 GitLab 的工程師們已經花了很長時間對抗垃圾訊息的發送者(spammer),這些大量垃圾訊息已經嚴重影響到資料庫的穩定性跟服務速度,甚至嚴重到鎖死資料庫的寫入功能。更嚴重的是二號資料庫連複製都有困難了,跟上線的一號資料庫的同步已經嚴重延遲,甚至拒絕連線一號資料庫。線上處理的工程師裡,有一位工程師的時區位於荷蘭,當時荷蘭已是深夜,身心俱疲的他決定把不聽話的二號資料庫資料全部刪除再重建。

他本意是要對二號資料庫伺服器特定目錄下 rm -rf(Unix 系的指令,不經 double check 就可以強制刪除所在目錄下的所有資料)指令,結果執行 1 秒或 2 秒後,猛然發現目標伺服器弄錯了,是正在線上服務中的一號伺服器而不是有問題的二號!

這就好像空難電影裡,雙引擎客機要處理故障的右引擎時,卻把維持飛機動力的左引擎給關掉了。

事發後的緊急處理

緊急取消指令後,300GB 的資料被刪到只剩下 4.5GB。而最後一個潛在可用的備份是 6 小時前手動操作的,一時之間連網站都連不進去了。根據該公司 Google docs 的維護紀錄在最新的訊息提到:「這個事件影響了網站資料庫(包括 issue 問題和 merge requests 合併請求),但不影響 git repos(git 版本管控檔案庫和 wiki 服務)。」

由於不是所有資料都遺失了,所以對用戶來說還是稍感安慰,但是該文件在「遇到的問題」(Problems Encountered)小節裡,最後總結:

「因此,換句話說,部署的 5 個不同備份/還原技術中,沒有一個能可靠地工作或第一時間還原回來,我們只能從 6 小時前有效的備份還原。」

看到這句以後,彷彿全世界所有人的臉都震驚地凍結好幾秒,這有點像鐵達尼號的沉沒是連續好幾個安全機制同時失常。該公司只能坦誠地總結了這些錯誤(原文刊登):

  • LVM snapshots are by default only taken once every 24 hours. YP happened to run one manually about 6 hours prior to the outage.
  • Regular backups seem to also only be taken once per 24 hours, though YP has not yet been able to figure out where they are stored. According to JN these don’t appear to be working, producing files only a few bytes in size.
  • SH: It looks like pg_dump may be failing because PostgreSQL 9.2 binaries are being run instead of 9.6 binaries. This happens because omnibus only uses Pg 9.6 if data/PG_VERSION is set to 9.6, but on workers this file does not exist. As a result it defaults to 9.2, failing silently. No SQL dumps were made as a result. Fog gem may have cleaned out older backups.
  • Disk snapshots in Azure are enabled for the NFS server, but not for the DB servers.
  • The synchronisation process removes webhooks once it has synchronised data to staging. Unless we can pull these from a regular backup from the past 24 hours they will be lost
  • The replication procedure is super fragile, prone to error, relies on a handful of random shell scripts, and is badly documented
  • Our backups to S3 apparently don’t work either: the bucket is empty

更糟糕的是,GitLab 去年曾經公開發表一件事:該公司本來使用的雲端已經超載不夠用了,要構築和運行自己的 Ceph 雲端。GitLab 的基礎設施領導人 Pablo Carranza 表示,決定採用自己的基礎設施「將使 GitLab 更具備高效能、一致性、可靠性,因為我們將擁有更多整體基礎設施的所有權。」

回顧完 GitLab 去年的決策,再看這次發生的意外災難最新報告,實在很尷尬。在編寫本文時,GitLab 表示:

  • ±6 小時的資料遺失了
  • 大致上,受到影響的有 4,613 個常規專案、74 個專案分叉(fork)和 350 個導入(import),總共 5,037 個項目。 由於 Git 儲存庫沒有遺失,我們可以重建這些專案在意外發生前所有的用戶/群組,但是我們無法恢復這些項目任何 issue 問題。
  • ±4979(所以 ±5000)註解遺失了。
  • 可能有 707 個用戶不見了,很難從 Kibana 日誌中確定。
  • 1 月 31 日 17:20 之前創建的 Webhook 被復原了,但在此時間後創建的則遺失了。

應有妥善 sop 或防呆機制

GitLab 成立於 2014 年,獲得 2,000 萬美元的風險投資,客戶包含 IBM、Macy’s、ING、NASA 、VMWare 等。在本週,這些投資者的內心恐怕比其用戶更加忐忑不安。

GitLab 這事件發生以後,突顯了幾個議題,除了網站資料備份機制的漏洞,可能還有工程師的超時工作(導致判斷失常)以及工作紀律問題:sudo rm -rf 這樣最高權限不經 double check 就強制執行的指令,在使用時應該要有適當的 sop 或更好的權限防呆。這事件反映出,除軟硬體設備外,人員的良善管理更為重要。

亡羊補牢為時不晚,GitLab 展現誠意以 YouTube 直播與 Twitter 將訊息公諸於網路,但是看來 GitLab 必須非常努力,才能挽回客戶與投資者對該公司的信心。對其他仰賴資訊科技的公司而言,相信這也是很好的借鏡。

(首圖來源:shutterstock) 

關鍵字: ,

發表迴響