2
0

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 5 years have passed since last update.

本番DB作業をする個人はどのようなオペミス対策をするべきか

Last updated at Posted at 2020-10-26

誤ってテーブル1枚のレコードをすべて delete してしまいました。
343 rows affected という表示は一生忘れないでしょうね...

理想は「スクリプトを流すだけ」など自動化されていることだとは思うのですが、手動運用が残っている部分が存在するというのもまた事実だと思います。
そのような環境で、本番環境を壊さないようにするために個人ができることについて考えてみました。

手順書を作る(コマンドを手打ちしない、ヒストリを使わない)

本番環境に流すコマンドは、事前に書いておいたものをコピペするだけにしましょう。

以下のような行為はオペミスのもとなのでやってはいけません:

  • コマンドをその場で手打ちする
  • ヒストリからほしいコマンドを探して実行する

そのため、以下のような手順書を事前に準備しておくべきです。

begin;

# 事前確認
#   期待値: 1
select count(*) from user where user_id = 1;

# 削除
#   期待値: 1 row affected.
delete from users where user_id = 1;

# 事後確認
#   期待値: 0
select count(*) from user where user_id = 1;


rollback;
# commit;

手順書にないことはしない

手順書にないことはやってはいけません。
どうしてもやる必要があるなら手順書を書くところからもう一度やり直しです。

「手順書作っておいて手順書にないことするわけないじゃん」と思いがちですが、
たとえば1件deleteする予定のはずが空振って0件だった場合、 直打ちで select をして確認をしていたりしないでしょうか?

「それくらい大丈夫じゃない?」という気がしますが、以下のようなオペミスが考えられます:

  • select したつもりが delete で実行してしまってレコードを消してしまう
  • select の where 句が抜けていて、全件検索が走ってしまう

このようなオペミスを防ぐためにも、本番環境では些細と思えるアドリブも徹底して控えることが望ましいです。

検証環境でリハーサルをする

検証環境で手順書に従ってリハーサルをしましょう。
手順書のテストにあたります。

検証環境でやったこと以外は、本番環境でアドリブでやってはいけません。

ダブルチェックをする

本番環境の実行は必ず2人以上でダブルチェックをして実行しましょう。
1人がコマンドの入力をして、実行する前にもうひとりがコマンドに誤りがないか確認してから実行します。

2
0
1

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
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?