検証のつもりで、本番のデータを消していた

あなたが置かれている状況

水曜 15:40。 不具合の再現のため、検証環境のテスト注文を整理することになった。

手元のターミナルで、いつもの手順を踏む。

$ export $(cat .env.staging | xargs)
$ npm run db:console
> DELETE FROM orders WHERE created_at < '2026-09-01';
Query OK, 12847 rows affected

12,847 行。 検証環境のテスト注文にしては多い。

「テストデータ生成を何度も回したからだろう」と思い、作業を続けた。

15:52、Slack に通知が飛んだ。 監視のアラート。「注文一覧 API のレスポンスが空です」。

本番の管理画面を開く。9月以前の注文が、1件も無い。

.env.staging を確認する。DB_HOST の行がコメントアウトされていた。3日前に別の作業で誰かがコメントアウトし、戻していなかった。

環境変数が設定されなかったため、アプリは既定値を使った。その既定値は、db.production.internal だった。

取り返しのつく操作ではなかった。

このケースで問われること

このケースは、取り返しのつかない操作をしてしまった後を扱います。

多くの障害対応は「壊れたものを直す」話ですが、これは「壊れたものが戻らないかもしれない」話です。焦りの中で、さらに悪化させない判断が要ります。

そして、この事故の原因を「作業者の不注意」で終わらせるかどうかが問われます。注意していれば防げた、は正しいですが、対策にはなりません。

順に 5 つの判断点があります。それぞれで一度自分の答えを決めてから、先へ進んでください。結論を先に読むと、判断の練習になりません。

扱う範囲は ops/configuration・ops/backup-restore・security/audit-log・data/soft-delete にまたがります。