2025年某日深夜2時。疲労困憊の中で打った1つのコマンドが、本番データベースのテーブルを全削除した。これは、その夜から72時間の記録である。
00:00 — 発端
深夜のメンテナンス作業。ステージング環境のデータをリセットするつもりで、ターミナルのタブを間違えた。DROP TABLEを実行した瞬間の沈黙。次に画面に表示されたのは「Query OK, 0 rows affected」。全テーブルが消えた。心拍数が一気に上がったのを覚えている。
00:05 — 初動
直後にSlackの #incident チャンネルに「P0: 本番DB全テーブル削除」と投稿。手が震えていた。CTO、SREチーム、バックエンドリーダーに電話。全員が5分以内に集まったのは、チームの練度の高さだった。
00:30 — バックアップからの復旧開始
日次バックアップの最新は6時間前。つまり、6時間分のデータが失われる可能性がある。しかし、binlog（バイナリログ）が有効だったことが不幸中の幸い。バックアップをリストアし、binlogで6時間分を再生する方針に決定。
08:00 — 復旧完了
約8時間の作業を経て、データ損失ゼロで復旧完了。binlogの再生でトランザクションレベルの整合性も確認。サービスのダウンタイムは約5時間。
事後対策
①本番DBへの直接接続を原則禁止（踏み台サーバー経由+承認フロー）、②ターミナルプロンプトに環境名を色付き表示（本番=赤、ステージング=黄）、③DROP/DELETE文の実行前に確認プロンプトを強制するラッパースクリプト導入。ヒューマンエラーはゼロにできない。だからこそ、エラーの影響範囲を最小化する仕組みが必要だ。
# comment