GitLabのプロダクションデータベースがエンジニアによって削除されました。300ギガバイト。

この動画の要点

• 2017年1月31日: プライマリのデータディレクトリでrm -Rvfを実行。約300GBが削除され、4.5GBが残る。
• 5つのバックアップすべてが失敗: 空のS3バケット (pg_dumpバージョン不一致)、DBにAzureスナップショットなし、レプリカがワイプ、Webフックなしの日次LVMコピー
• 2月1日18:00 UTC: GitLab.comが6時間前の手動スナップショットから復旧。ライブドキュメント、ライブストリーム、修正リスト付きの非難なしの事後分析

翻訳されたトランスクリプト

オリジナルの英語ナレーションから翻訳されています。利用可能なオーディオとキャプションはYouTubeによって管理されています。

0:00 GitLabのエンジニアが間違ったデータベースサーバーでrm -rfを実行し、 GitLab.comの300ギガバイトが1〜2秒で消滅。 ホスト名を読み取るのにかかる時間とほぼ同じ。 2017年1月31日午後11時27分、 UTC。GitLabは誤って本番データを削除したとツイートし、 インシデントメモをインターネットに公開し、復旧をYouTubeでストリーミング。 プラットフォームで2番目に人気のあるライブストリームとなる。 翌日、文書化された情報: 5つのバックアップ手法のうち、

0:25 信頼できるものは一つも機能していなかった。 なぜそれが起こったのか、なぜそれが可能なのか、そして誰が実際に責任を負うのか。 これはThe Daily Diff、事後分析です。 午後5時20分: エンジニアが本番環境のスナップショットを作成し、 ステージング環境のロードバランサーをテストします。 午後7時: スパムがデータベースを攻撃し、さらにGitLabの従業員をハード削除するジョブが、 荒らしの報告により実行されます。 午後11時: レプリカが大幅に遅延し、プライマリが必要なログをすでに破棄していたため、

0:48 唯一の修正方法はレプリカをワイプしてプライマリを再度コピーすることでした。 pg_basebackupは出力なしでハングアップします。 実際には、プライマリを静かに待っていたのですが、誰もそのことを知らず、 ランブックにも記載がありませんでした。 午後11時には退勤するつもりだったエンジニアは、空のデータディレクトリが 問題だと判断し、削除します。 db1上で。プライマリです。 彼は1〜2秒後に気づきます。およそ300ギガバイトのうち、

1:11 4.5ギガバイトが残っていました。バックアップは。 1つ目: pg_dumpをS3に日次で。 バケットは空でした。 cronジョブはデータベースのないアプリサーバーで実行されるため、パッケージは 9.6データベース用のPostgreSQL 9.2バイナリを選択し、失敗し、 DMARC不足のためにバウンスされた失敗メールを送信します。 2つ目: Azureディスクスナップショット、ファイルサーバー向けには有効でしたが、 データベース向けには無効でした。

1:32 3つ目: レプリカ、1時間前に意図的にワイプされていました。 4つ目: 24時間前の日次スナップショット、ステージング同期によってすべてのWebhookが 削除されていました。5つ目: 無関係なテスト用の午後5時20分の手動スナップショット。 これが採用されます。 復元とは、ステージングディスクをAzureの安価なストレージ経由で 毎秒60メガビットで本番環境にコピーし直すことで、18時間かかります。 GitLab.comは2月1日午後6時に UTCで復旧しますが、6時間分のデータは古くなります。

1:58 git blame: 1文字違いの2つのホスト名と、誰も 復元したことのない5つのバックアップシステム。 エンジニアではありません。 CEOが署名した事後分析では、彼の匿名性を保ち、 本番プロンプトを赤くし、データ耐久性に責任者を割り当てます。 なぜなら、それまで責任者はいなかったからです。 被害範囲: 18時間の停止、6時間分のデータ損失、 約5000のプロジェクト、5000のコメント、

2:18 700人の新規ユーザー、そしてプログレスバーを見守る5000人。 Hacker Newsはライブドキュメントに1,162ポイントを与え、彼らに 「5つのバックアップのうち、なし」という一文を引用します。 評決、事後分析: 対応についてはSHIP IT。 彼らはインシデントを公開し、プロセスを非難し、修正リストを 課題番号とともに公開します。 月曜日の行動: バックアップを復元する。 一度も復元したことがなければ、それはバックアップではありません。

2:42 まだ話せないインシデントを コメントまたはdailydiff.devまでお寄せください。 以上が今日のdiffです。 AxrisiのNikoでした。 責任を持ってマージしましょう。

情報源

1. GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
2. GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
3. @gitlabstatus, "We accidentally deleted production data…"twitter.com
4. @gitlabstatus, emergency maintenance noticetwitter.com
5. Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
6. Hacker News, the postmortem thread (377 points)news.ycombinator.com