システム運用において「環境の取り違え」は、誰にでも起こり得るヒューマンエラーです。
開発環境、検証環境、本番環境と複数の接続先を扱う現場では、ほんの一瞬の思い込みが重大な事故につながることもあります。
今回は、チームメンバーがSQLの実行環境を誤った事例と、そこから得た学びについて振り返ります。
発生した現象
本番環境で実行する予定だった更新系クエリを、誤って検証環境で実行してしまいました。
幸いにも、WHERE句で指定していた条件が検証環境には存在しなかったためエラーとなり、データが更新されることはありませんでした。作業者はこのエラーをきっかけに、実行環境を誤っていたことに気づきました。
実行時にはダブルチェック担当者（社員）も同席していましたが、その場では環境の誤りに気づくことができませんでした。結果として、実害はなかったものの、「重大事故になり得たミス」が発生した形になります。
原因の整理
まず、作業者およびダブルチェック担当者双方の確認不足が挙げられます。
画面上に表示されている接続先情報を十分に確認せず、「本番に接続しているはず」という前提で作業を進めてしまいました。
さらに、当時は検証環境で受入テストを行いながら、本番環境の調査対応も並行して進めるなど、複数環境に同時接続した状態で作業することが常態化していました。接続タブが複数開いている状況では、視覚的な識別だけに頼るのは危険です。
加えて、ダブルチェック担当者の時間確保が難しく、短時間で別案件や複数環境のデータメンテナンスをまとめて実施するケースが多くなっていました。余裕のない状況では、チェックも形式的になりやすく、見落としが発生しやすくなります。
個人的に実施している対策
チームとして明確な再発防止策が定められたわけではありませんでしたが、私はこの件をきっかけにいくつかの対策を個人的に実施しています。
まず、いかなる環境であっても必ずトランザクションを張ること。
即時コミットを避け、確認後に明示的にコミットする運用にすることで、誤実行時の被害を最小限に抑えられます。
次に、複数環境に同時接続しないこと。可能であればツール設定で同時接続を制限し、少なくとも更新系作業時は単一環境のみを開くようにしています。
そして、クエリ実行前に実行環境を声に出して確認すること。ダブルチェック担当者にも環境名を確認してもらい、「今から本番環境で実行します」と明示的に宣言するようにしています。形式的に見えるかもしれませんが、声に出すことで思い込みを断ち切る効果があります。
結論
この件について、チーム全体で新たな対策が制度化されたわけではありません。作業者への口頭注意にとどまったと記憶しています。
しかし、実害が出なかったからこそ、危機感が薄れてしまう可能性もあります。だからこそ、自分自身の作業スタイルを見直す契機としました。
学んだこと
今回の出来事は、「ミスが発生しやすい環境を自ら作っていないか」を見直す良い機会になりました。
複数環境を同時に開く、時間に追われながら確認する、慣れで作業する――これらはすべて、ミスの温床になり得ます。
人の目だけで完璧にチェックするのは限界があります。だからこそ、システムで防げる部分は手間であっても活用すべきだと感じました。
環境ごとに接続色を変える、更新系は必ずトランザクション必須にする、同時接続を制限するなど、技術的に制御できる仕組みは数多くあります。
「気をつける」ではなく、「間違えにくい仕組みにする」。
この視点を持つことが、安定運用への第一歩だと改めて実感した出来事でした。
