--- title: "エンジニアが間違ったデータを消した日：GitLab 2017年の話" url: https://www.thinnd.site/ja/monogatari/gitlab-2017-machigatte-deta-wo-keshita-hi/ language: ja author: "Nhu Duy Thin (Thinnd)" published: 2026-10-29 updated: 2026-10-29 section: "ストーリー" tags: ["障害", "バックアップ", "誤削除", "GitLab", "ポストモーテム", "運用"] summary: "2017年1月31日、GitLab.comのデータベースの副サーバーを作り直している最中に、エンジニアが副サーバーでなく主サーバーのデータディレクトリを消すコマンドを実行し、止めるまでに約300GBを失いました。バックアップを探すと、使える層はなく、GitLabは約6時間前のスナップショットから約18時間かけて復旧し、少なくとも5,000のプロジェクト、5,000のコメント、約700のアカウントのデータを失いました。GitLabの主な教訓：復元を試したことのないバックアップは、まだバックアップではない。打ち間違いは、運用上の失敗の連鎖の最後の輪にすぎなかった。" license: "Cite with the author name and the canonical URL above." --- # エンジニアが間違ったデータを消した日：GitLab 2017年の話 > これは**実話ですが、私自身の話ではありません**。GitLabが2017年2月10日に公表した事後分析（末尾にリンク）に沿って振り返ります。エンジニアの名前は書きません。GitLabの最初の作業メモには名前がありましたが、同社は以後の障害では名前を伏せると述べています。 > > その人が何を考え、何を感じたかは分からないので、記事ではそれを事実として描きません。私の推測や提案の部分は、そう明記します。 --- ## 先に要点 - 2017年1月31日、GitLab.comのデータベースの副サーバーを作り直している最中に、エンジニアが副サーバーでなく**主サーバー**で削除コマンドを実行しました。1、2秒後に止められましたが、**約300GB**が消えていました。 - その後、**バックアップの層が1つずつ失敗するか、使えないと分かりました**。復旧できた唯一のコピーは、同じエンジニアが約6時間前に偶然、手で取ったスナップショットでした。 - サービスは**約18時間停止**。GitLabは、少なくとも**5,000のプロジェクト、5,000のコメント、約700の新規アカウント**の変更が失われたと推定しました。Gitリポジトリとwikiは影響を受けませんでした。 - 打ち間違いは**最後の輪**にすぎませんでした。その前に、負荷の急増、文書のない手作業の手順、誰も気づかないバックアップの失敗がありました。 - GitLabは**すべてを公開**しました：共有文書、復旧のライブ配信、長い事後分析。技術的な教訓と同じくらい学ぶ価値があります。 --- ## むずかしい言葉をやさしく | 用語 | やさしい意味 | |---|---| | **主サーバー（プライマリ）** | 実際に使われ、利用者のすべての変更を受けるデータベースのマシン。 | | **副サーバー（セカンダリ）** | 主サーバーをリアルタイムで複製し、故障時に代わるマシン。 | | **レプリケーション** | 副サーバーが主サーバーから変更の記録を受け続け、同じ状態を保つこと。 | | **バックアップ** | 障害後に復旧するためのデータのコピー。レプリケーションとは別。 | | **スナップショット** | ディスクのある瞬間の状態を写し取ったもの。 | | **災害復旧** | 深刻なデータ損失の後にサービスを取り戻すこと。 | | **ポストモーテム** | 障害の記録：何が起き、なぜで、何を直すか。 | | **ブレームレス** | 責める相手でなく、仕組みや手順に目を向ける分析の仕方。 | --- ## 1. いつもの日が、悪い方へ向かう 以下の時刻はすべて、2017年1月31日のUTCです。 **17:20ごろ。** あるエンジニアが、本番データベースのディスクのスナップショットを取り、テスト環境に読み込みます。接続の振り分け装置の負荷試験のためです。この作業は通常、毎日01:00に自動で行われていました。この手作業のスナップショットが、その夜を救うことになりますが、まだ誰も知りません。 **19:00ごろ。** データベースの負荷が急増。チームはスパムを疑い、多くの人がコメントを投稿できません。負荷の一部は、GitLabの従業員1人のデータを消すバックグラウンド処理でした。その人のアカウントが、不正利用として誤ってマークされ、削除が予約されていたのです。GitLabによると、不正利用の報告システムは細部を見落としやすいものでした。 **23:00ごろ。** 副サーバーが遅れ、複製が止まります。主サーバーがすでに片付けた変更ログが必要で、当時のGitLab.comはそれを再利用のために保管していませんでした。唯一の方法は、**副サーバーを手作業で最初から作り直す**ことでした。 チームが作業を始めます。再構築のツールは、何も表示せず黙って固まります。設定を調整すると、PostgreSQLが再起動を拒み、さらに調整します。運用をやったことのある人には、おなじみの夜です：小さな作業が小さな作業を呼び、どの段階も筋が通って見えます。 --- ## 2. 23:30ごろ：1つのコマンド、間違ったマシン 複製を作り直すには、**副サーバー**のデータディレクトリを消して、読み込み直す必要があります。GitLabの事後分析によると、エンジニアはその削除を**主サーバー**で実行しました。 約1、2秒後に止めました。しかし**約300GB**のデータは、すでに消えていました。 その人の頭の中で何があったかを知る方法はありませんし、推測もしません。自信を持って言えるのは、事後にGitLabが、とても素朴な項目を対策リストに入れたことです：**シェルのプロンプトに、今どのマシンのどの環境にいるかを分かりやすく表示する**。この項目だけで、当時、2台を見分けることが十分に分かりやすくなかったと見ていることが分かります。 --- ## 3. バックアップを探す：5つの層、どれも使えない 直後に、バックアップを探しました。この部分が、この話を教訓にしています： | 守りの層 | 何が起きたか | |---|---| | **毎日のバックアップ（pg_dump）** | 実際のデータベースと違うバージョンのツールで動かして失敗。クラウドの保管先は空。失敗の通知はメールで送られたが、メール認証の設定がなく拒否され、**誰も知らなかった**。 | | **クラウドのディスクスナップショット** | ファイルサーバーでは有効だが、他の層で十分と考えて、データベースサーバーでは**有効にしていなかった**。 | | **LVMスナップショット** | 24時間ごと。ステージングへのコピー用で、**災害復旧のためではない**。手作業のものが約6時間前に1つだけ。 | | **副サーバーへの複製** | **障害時の切り替え**用で、災害復旧用ではない。しかも副サーバーは、作り直すために消したばかりだった。 | | **ステージング環境のコピー** | データはあったが、別のリージョンの遅いディスクの上。 | 目立つ点が2つあります。**1つ目**、各層はそれぞれ違う理由で失敗し、どの理由ももっともらしく聞こえます。**2つ目**、GitLabによると、バックアップには**責任者がおらず**、復元できるかを定期的に確かめる人がいませんでした。 --- ## 4. 復旧：18時間のコピー チームは、24時間前のものより失うデータが少ないので、6時間前の手作業のスナップショットを選びました。 - データはステージングの遅いディスクの上にあり、本番へ戻すコピーに**約18時間**かかりました。ディスクは約60Mbpsに絞られ、ボトルネックはディスクでした。 - データベースは、1月31日の**17:20 UTC**の状態に復元されました。 - **2月1日の17:00 UTC**：GitLab.comは、一時的にWebhookなしで再開。Webhookは、別に取り出したデータから作り直されました。 - データベースのID用の数え上げの番号を**10万増やし**、障害前に発行されたIDの再利用を避けました。 - 最終確認は、同日の18:00 UTCごろに終わりました。 **被害。** GitLabは、17:20ごろ以降の変更が、少なくとも**5,000のプロジェクト、5,000のコメント、約700の新規アカウント**で失われたと推定しました。（事後分析では、期間の終わりが、被害の節では約23:30、冒頭では00:00とあるので、その境目を正確とは思わないでください。）17:20以降に作られたプロジェクトは、Gitリポジトリだけが復元され、イシューとマージリクエストはありません。Gitリポジトリとwikiは別に保管されていたので影響を受けず、自社運用の顧客も影響を受けませんでした。 --- ## 5. GitLabが公の場でどう対応したか 技術以外で、私が最も学ぶ価値があると感じた部分です。 - チームは、各手順を記録する**公開の共有文書**を保ちました。 - 復旧を**YouTubeでライブ配信**し、ピーク時には約5,000人が見て、Twitterでも更新しました。 - わずか10日後に、約**15の対策タスク**の一覧を添えた**長い事後分析**を公表しました。 - 最初の文書がエンジニアの名前を挙げていたことを認め、**今後の障害では名前を伏せると約束**しました。 このやり方は**ブレームレス**とよく呼ばれます：1人の間違いを、仕組みがそれを許した印と捉え、「誰が間違えたか」でなく「次に誰もこう間違えないためにはどうするか」を問います。 --- ## 6. 打ち間違いは、最後の輪にすぎない 事後分析から解きほぐすと、1つの間違ったコマンドの背後には、鎖があります： 1. スパムと、誤って動いたデータ削除処理による負荷の急増。 2. システムが変更ログを保管していなかったため、副サーバーが複製を止めた。 3. 手作業で文書の乏しい再構築の手順と、黙って固まるツール。 4. 毎日のバックアップが静かに失敗し、通知は遮られた。 5. データベースでクラウドのスナップショットが有効でなかった。 6. バックアップと復元テストに責任者がいなかった。 7. 取り違えやすい2台のマシンと、見分けのつかないプロンプト。 この鎖の中で、**打ち間違い**は、個人のレベルでは最も防ぎにくく、仕組みのレベルでは最も防ぎやすい輪かもしれません。 --- ## 7. GitLabが直したこと GitLabの公開の対策リストには、次のような項目がありました： - **シェルのプロンプトに、マシンと環境を分かりやすく表示。** - 公開ダッシュボードによる**バックアップの監視**。 - 本番データベースの**1時間ごとのLVMスナップショット**（GitLabは完了と報告）。 - データベースサーバーの**クラウドディスクスナップショット**。 - バックアップの**自動の復元テスト**。 - 継続的なログ保管による**ある時点への復旧**。 - 複製の再構築の**文書と手順書**。 - **データの耐久性に責任を持つ人**の指名。 注目すべきは、GitLabが、危険なコマンドを防ぐことだけでなく、**復旧できること**と**マシンを明確に見分けること**に重点を置くと述べたことです。打ち間違いはまた起きると捉え、その結果を小さくしたかったのです。 --- ## 8. 私が学ぶこと：削除コマンドを打つ前の1分 *この部分は私の提案で、GitLabの結論ではありません。* 1. **どのマシンにいるか？** プロンプトのホスト名を読み、決めつけない。2台が似ているなら、本物のプロンプトに色を付ける。 2. **どのディレクトリにいるか？** 消す前に、現在のパスを表示する。 3. **まず一覧表示だけのモードで。** 本当に消す前に、何が消えるかを見る。 4. **バックアップは本当にあるか？** 「たぶん」でなく、一度復元して、データが戻るのを見た。 5. **2人目が画面を見る。** 本番データでは、もう1組の目は安い。 6. **疲れ切っているときや、修正の途中ではやらない。** 止まり、休み、それから行う。これは一般的な経験からの推測で、GitLabの事後分析は、そのエンジニアが疲れていたとは述べていません。 7. **間違えた直後の1分の計画を持つ。** コマンドを止め、すぐ誰かに伝え、黙って直そうとしない。ここでは、1、2秒後にコマンドを止めたことが、残りを救いました。 --- ## 9. AIがコマンドを実行できるとき この話は2017年で、人の代わりにコマンドを実行するAIエージェントが現れる前のことです。でもこれは1つのことを示唆します：**削除の権限を持つAIエージェントは、決して疲れず、そして「何かおかしい」とも決して感じない、コマンドを打つ者です**。[AIを鵜呑みにしてはいけない理由](https://www.thinnd.site/ja/gijutsu/ai-wo-unomi-ni-shinai-riyu/)は別の公開された事件に触れ、[MCPとは何か](https://www.thinnd.site/ja/gijutsu/mcp-towa-konsento-de-setsumei/)はAIのヒューズ、つまり最小限の権限、読み取り専用から始める、重要な作業は人が承認する、を扱います。それらの原則は、新しい種類のコマンドを打つ者に当てはめた、GitLabの教訓です。 --- ## 10. バランスの取れた見方 - **主な情報源は1つです。** 私は主にGitLab自身の事後分析に拠っています。細部（たとえばデータ損失の期間の終わり）が節によって違います。 - **エンジニアが何を感じたかは分かりません。** 記事は感情を事実として描きません。 - **この障害は10年近く前のことです。** ツールは変わりましたが、原因（復元したことのないバックアップ、責任者の不在、取り違えやすいマシン）は今もとても身近です。 - **「ブレームレス」は責任がないという意味ではありません。** 責任を、1人から、仕組みとそれを設計する人たちへ移すのです。 --- ## 11. 結論 1人のエンジニアが、1つのコマンドを打ち間違えました。けれど、この話を痛いものにしたのは、5層のバックアップがすべて、必要なときに使えなかったことです。教訓は2か所にあります：**間違ったコマンドを打ちにくくする**こと、そして**それでも起きたときに、結果を小さくする**こと。 今日の小さな一歩：今信頼しているバックアップを1つ選び、**今週中に復元を試す**。一度も試したことがないなら、バックアップはなく、あるのは希望だけです。 自分で誤ってデータを消した話があるなら、7つの問いに答える形で書き留めてください：いつ起きたか、直前に何をしていたか、何を失ったか、どう気づいたか、どう復旧したか、その後何を変えたか、他の人に何を持ち帰ってほしいか。 --- ## 参考資料 - [Postmortem of database outage of January 31（GitLab、2017年2月10日）](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/) - [Postmortem of GitLab Database Outage of January 31（Linux.com）](https://www.linux.com/?p=474688) - ブログ内の関連記事：[AIを鵜呑みにしてはいけない理由](https://www.thinnd.site/ja/gijutsu/ai-wo-unomi-ni-shinai-riyu/)、[MCPとは何か？コンセントで説明する](https://www.thinnd.site/ja/gijutsu/mcp-towa-konsento-de-setsumei/)、[実際のプロジェクトでAIエージェントと働いた3時間](https://www.thinnd.site/ja/genba-noto/ai-agent-jissai-no-purojekuto-nikki/)