【懺悔】稼働中の本番DBで殆どのテーブルをtruncateしてしまった話 - Qiita

これは8年ほど前のある日のことです。 本番環境のテーブルを淡々とtruncateし続けたことがあります。 リリース前などではなく、稼働中のサービスでした。 思い出せる限り、私のエンジニア歴において最大の「やらかし」です。 「そんなミスありえないだろ…」「どんだけ迂闊なんだよ」という感想を持たれる方もいらっしゃるかと思います。 むしろ、それが正常だと思います。しかし、当時の私はやってしまった。 ただ、それでエンジニアをやめるようなこともなく、現在では人を指導する機会も増えました。 どうしたらそんな事が起きるのか？ その後、どのような対応が行われたのか？ 教訓はなにか？ この機に記させていただきたいと思います。 量産現場の社二病社員 当時働いていた職場では、「同じような機能を持ったスマートフォンアプリ」を量産する部署がありました。 私は、そこに配属されました。 当時、新卒２年目。社二病真っ只中

[hatest]

やっちまった本人ではなく、やっちまえるプロセスが悪い

[Keisuke69]

よく聞く話ではあるが本番手作業ってやっぱり怖いので2人くらいでやりたい

[rAdio]

DBに関する対象ミスって稀によくある。気を付けていても起きるし、大抵はうっかり度合いも低く「正しいつもり」でやらかしてしまうんだよなぁ……。多分、確認手段が適切でないとかフェイルセーフが効いてない。

[ryuichi1208]

PITR便利

[yuki_2021]

こういうの聞くと、背筋がピンとするな。

[rryu]

操作するサーバを間違えるとだいたい大事故になる。サーバ自体を間違える可能性は一度間違った経験者でないと意外と思い付かないものである。

[knjname]

データストアは自分で作るのだけは本当に避けたいわ　アプリはいくらでも飛ばしてもいいけど、データストアは飛ばしたら取り返しが付かない

[ryer]

あるある。俺も大手ECの本番DBふきとばした。あるんだよ。

[interferobserver]

まあ似たようなのは俺もある。本番環境ではなく、複数あるテスト環境の接続先を間違えた。

[kanehama]

かなり昔バックアップ＋バイナリログから巻き戻し対応を行ったのを思い出した。

[dorapon2000]

“ポイントインタイムリカバリは、RDSインスタンスのある時点の状態を、別のRDSインスタンスで再現する機能です。”

[uxoru]

“すごい！すごいぞAWS！ありがとう！ありがとう...”

[umai_bow]

赤裸々。DB本番はよくないわな

[programmablekinoko]

恐ろしい

[R2M]

はわわ

[odakaho]

“本番環境のテーブルを淡々とtruncateし続けた”