本番環境でSQLをなるべく安全に実行するパターン

起こりうる事故

ロックにより他のオンライン中のサービスに影響を与える。

トランザクション設定ミスにより途中の状態でコミットされる

スロークエリ発行により、全体をスローダウンさせる。

統計情報が取得できておらず、SQL実行時間が長くなったりデータベースのリソースを喰ってしまったりする。

接続先を誤認して、本番環境でDELETE やTRUNCATE、DROP TABLEなどを発行してしまう

ターミナルの操作ミスによって、クリップボードから誤ったSQLなどを発行してしまう。

パターン

リハーサル

コンテキスト

本番一発勝負では、不測の事態に陥ることもあるため、事前にリハーサルを行なって安全性を確認しておきたい。

フォース

本番相当の環境を用意できる。

マスクして持ってくることが定められたセキュリティポリシーに反していない。

ソリューション

本番相当のデータをテスト環境やステージング環境に構築し、そこでリハーサルを行う。

リハーサルでの確認観点は以下のようなものがある。

実行結果が正しいか? 更新されていることだけでなく、更新対象以外が更新されていないことも確認する。

実行時間が現実的か?

負荷テストなどで使ったテストシナリオがあれば、それを流しながらリハーサル実施すると、より本番に近い環境となる。

切り戻しのSQL

コンテキスト

ミスに気づいた後、元の状態に戻せる方法があるなら、事前にそれも用意しておく。

フォース

切り戻しのSQLが準備可能である。

ソリューション

切り戻しのSQLを事前に作っておく。

ロールバックを使った切り戻しは、最終手段(操作ミスによってコミットしてしまうこともあるため)。バックアップを取得しておいて、戻せるようにしておく

データの洗い替えなどは、作業前に現在の状態をCREATE TABLE 〜 AS SELECTしてバックアップを取得する。

切り戻しのリハーサルも計画・実施する。

インデックスの一時削除

コンテキスト

大量のデータに対する登録・更新・削除処理を行う

フォース

作業中に発行されると予測されるSQLに対して、インデックスを消してもあまり影響がないことが分かっている。

ソリューション

インデックスの削除と作成SQLを用意しておき、大量更新処理前後で実行する。

リハーサルでインデックスの一時削除が必要かどうか判断するとよい。

インデックスの断片化を解消する副次的効果もあるので、更新・削除が多く実行されるテーブルでは、とりあえずインデックスの一時削除もやっておくとよい。

操作対象レコードの特定

コンテキスト

ちょっと件数や対象のデータを確認しておいたならば気づくことができた事故もある。

フォース

データの更新、削除を行う作業である。

ソリューション

本番環境で更新のSQLを実行する前に、対象となる件数が想定と一致しているか確認する。

件数だけでなく、操作対象のレコードを数件表示させて、合っていそうかを目視で確認しておくと、うっかりミスに気づくこともある。

半自動化

コンテキスト

完全なる手作業ではタイプミスによる事故が懸念されるし、かといって十分リハーサルができていない自動スクリプトでは、実行途中に問題に気づかず被害を拡大させしまうことがある。

フォース

ターミナルからの作業である。

ソリューション

ターミナルのスクリプト機能(TeraTerm MacroやApple Scriptなど)を使って、一行ずつ確認しながらコマンド、SQLを実行する仕組みを作る

プロンプトを変える

コンテキスト

自分がどの環境に接続しているか、特に意識朦朧とする深夜作業だとわからなくなる。

フォース

開発環境にも本番環境にもログインできる権限を持つ人が作業する。

ソリューション

ターミナルのプロンプトや背景色や、ブラウザのメンテナンスページの色を変える。

例えばAWSのコンソールから作業するにしても、ChromeのExtensionなどを作って環境によって背景色などを変えたり、バナーを差し込んだりすることができる。