この記事は 赤ちゃんは25日でアプリの設計から開発まで遂行できるのかの11日目の記事です。
（本番環境でやらかしちゃってますが、本番環境でやらかしちゃった人カレンダーとは関係ありません）
今日は作業お休みDayなので箸休めがてら、3年前、私が前職でプログラマ新生児だった頃にやらかして永遠に心の傷となっていた事件を供養しようと思います。
何をやらかしたのか
###やらかしの土台
- 自分が新卒で入社して半年（OJT明け）かつ案件に参画した直後
- 入った案件は5年以上自社で請け負っており、チームメンバーもほぼ固定で半ば属人化していた
- 自分に指示を出していた上司はこの案件のメインメンバーではなく、尚且つ複数案件を掛け持ちしていたため案件に対して特別詳しいわけではなかった
自分に与えられたタスク
具体名は伏せますが、案件はよくある販売者側の販売物管理と購入者側の事後サポートを行うWEBサイトでした。
サイトはフロントが販売者側と購入者側で2種類あるのに対し、管理画面は共通という仕組みです。
自分はその中で、
最初に、購入者側サイトでユーザーの登録地域ごとに提携銀行などのバナーが変わるデザイン改修作業を、
次に、販売者側の明細がPDF出力のみだったのをスマホ向けにとしてPDFを介さずサイト画面からで直接見れるようにするための改修作業を振られていました。
1つ目のタスクでレビューが無事通り、自分の変更をステージングに上げてもらい、単体テストとして「購入者側のDBサーバー接続情報が書かれたExcelファイルとパスワード」を教えてもらい、ダミーユーザーの登録地域を書き換えて各地域ごとに正しいデザインが表示できたのでこちらのタスクは無事完了しました。
(こちらも名前は伏せますが、MySQLではなくWEBサイト上でDB操作するツールを使用していました)
そして起こったやらかし
2つ目のタスクがある程度終わり、「じゃあ赤ちゃんさん、テストをお願いします」と言われた時に事件は起こりました。
1つ目のタスクで私がDB接続のために確認したファイル名は「buyer_bd_stg.exe」(仮名)でした。
エクセルファイルの中に他のシートも無く、私は同じ階層にあった「seller_bd.exe」(仮名)を迷いなく開き、buyerと同じパスワードでファイルを開いてそこに記載されていたDBに接続しました。
まずユーザーの登録情報を変更したかったのでダミーユーザーでUPDATEを叩きますが、該当データがないということでエラーが出ます。
誰も登録していなかったのかと思いながらINSERTを叩きますが、ここでも再びエラーが。
おかしいなと思いながらも既存でデータが入っていたようなので、それを覗き見た瞬間血の気が引きました。
私が叩きまくっていたのは、本番サーバーの顧客DBでした。
二度と惨劇を起こさないためにどうしたか
自分が本番にアクセスしてしまった原因
- 「buyer_db_stg.exe」が販売者、購入者共通のSTGサーバーと伝えられていなかった
- ファイルやサーバーを見ただけでは共通とわからず、ファイル名も紛らわしい物になっていた
- 本番環境にアクセスするファイルとステージング環境のファイルで同じパスワードを使い回していた
- 1回目、2回目のタスク共に新人が1人でDBを操作する環境にあった
行った対策
- STGサーバーも販売者、購入者で分けた。ファイル名も「stg_seller_db.exe」「stg_buyer._db.exe」に変更。
- 本番のアクセス情報が入ったエクセルの配置階層をパスワード付きのフォルダへ移動させて2重パスワードにした。ファイル名も「honban_seller_db.exe」「honban_buyer.exe」に変更。
- 本番のエクセルのパスワードを変更し、マネージャー以上の人間だけが知る情報とした
- 本番、STGでExcelに注釈を入れ、DBサーバー側のサイトヘッダーを変更した
- 初めてDBを触る場合、案件に一定の見識がある人間とペアで作業するルールを設けた
さいごに
INSERTが出来なかった理由は、ダミーユーザーのユーザーIDがマイナス値(実際の運用では存在しない値)で弾かれていたためでした。
追記：当時の記憶を知る人から、DBから直登録したデータの削除対応をしたような記憶がある、という情報をもらいました。
どちらにせよ実際の顧客データには紐付かなかったそうで、影響が出てなくて本当に良かったです。
振り返ってみれば仮に自分が回避できたとしてもいずれ誰かが踏みかねない地雷だったので、入社半年で会議室に呼び出され案件の偉い人全員VS自分の構図で半泣きで必死に弁明し、後釜を根絶やしにできたことは本当に良かったです。