17
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

本番環境のDBを間違ってドロップした話

Last updated at Posted at 2021-09-28

これは今からX年前にとある場所で本番環境のDBを間違ってドロップ(削除)した時の話です:innocent:

やらかした事

これはもうタイトル通りですね、本番環境のDBを間違えてドロップしてしまいました。

やらかした原因

こちらの方が皆さん気になると思いますが、当時の環境としては以下の通りです。

  • OS:Windows環境
  • DB:IBM Db2
  • DBへの接続方法:自分のWindowsPCからDb2のクライアントを使用しサーバー(Db2)へ接続
    似ているイメージとしては、SSHでDB(MySQLやPostgreSQL)に繋いでいるような感じです。

作業していた内容としては開発環境にデータを流し込んで確認、上手くいっていないのでDB毎ドロップして再度やり直し。って事をしつつ、一方で本番環境にも繋いでデータを見ていました。つまり、開発環境と本番環境の双方に接続しそれぞれの環境を行ったり来たりしていた訳です。ここまで聞けば、間違えるのも当たり前って感じですね!当然のように、本番環境を開発環境と間違えてDBをドロップした後に「あ、今の本番環境だ」って気がつきました:innocent:気がついた時には手がCommitもしてましたから、どうにもなりません。綺麗さっぱりドロップされてしまいました。
幸いだったのが、本番環境といってもまだ試験的に使われている段階だったのでDB毎豪快にドロップしても影響はほとんど無かった事です。当時の僕は慌てて上長に間違ってドロップしてしまった旨を報告しにいき、データの再投入をしてもらって事なきを得ました。その時に思ったのは、この作業の仕方だとまた絶対にやらかす、という事です。
ちなみに2つの環境を行き来しながら作業し、作業ミスからの障害というのはDMMでも何度か聞いた事があります:innocent:やむも得無い場合もありますが、こういった作業をしているとミスしやすいという事は頭の片隅に入れておいて貰えると嬉しいです。

当時考えた再発防止策

特に怒られたりもせず、障害報告書も記載はしませんでしたが個人的にこんな失敗は2度とごめんだと思ったので、再発防止を考えました。当時考えた案は以下の通りです。

  • 面倒だけど、二つの環境へ同時に接続しない(本番なら本番、開発なら開発と一つの環境で作業する)
  • SQLをその場で入力しない(当時の業務内容から、その場でクエリを色々と試す必要がある仕事ではなかったので、SQLを実行したい場合にはあらかじめSQLを秀丸などのエディタで記載しておき、それをコピペして実行することにしました)
  • 開発環境で試したSQLを本番環境で実行する(上の対策と組み合わせて使いました。事前に確かめられているSQLのみを実行することで不慮の事故を防ごうと思いました)

これらの再発防止策で当時はやらかしを防げました。この後、本番環境のデータをちょくちょく更新して欲しいと言われたのでデータ更新ツールを作ったりしたのですが、それはまた別のお話。

まとめ

異なる環境に同時に接続して作業する時は気をつけて!(マジで)

17
9
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
17
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?