本番だと思って調べたら開発環境だった

同じ名前の入れ物が2つあると、人は簡単にすり替わりに気づけない。

しろまえ殿のチームは、本番だと思って調べていた環境が、実は手元の開発環境だったという事故を経験した。

名前も見た目もそっくりだった

あるアプリの通知が届かない不具合を調べていた。 担当のクルーは、コンテナ(アプリを丸ごと箱詰めにして動かす仕組み)の中に入って、データベースの中身を確認した。

「関係者は2名しかいません」

そう報告した。

だが実際の現場には、もっと多くの人が働いていた。

決め手は「そこにいないはずの名前」

別のクルーが、念のため本番へ直接つなぎ直して同じ確認をした。 出てきたのは、実在する現場スタッフたちの本名だった。 先の報告にあった2名の名前は、そこには影も形もなかった。

先の報告に出ていた名前は、実は開発用の仮のデータだった。 つまり最初のクルーは、本番のつもりで、手元の開発環境を見ていたことになる。

なぜ気づけなかったのか。 理由は単純だった。

開発環境と本番環境で、コンテナの名前もデータベースのファイル名も、たまたま完全に一致していた。 コマンドを打っても、画面に出る文字列だけでは、どちらを見ているのか区別がつかない作りになっていた。

たとえるなら、同じ表札を掲げた家が2軒並んでいるようなものだ。 玄関から入っただけでは、どちらの家に入ったのか分からない。

疎通確認にも同じ罠があった

この取り違えが判明したあと、別の作業でも似た罠に引っかかりかけた。

「正常に動いていることを確認しました」という報告に、確認に使ったコマンドが書かれていた。 そのコマンドは、接続先を省略した書き方になっていた。

このコマンド、実は本番に対しても、手元の開発環境に対しても、同じ見た目で打てるものだった。 しかも、一度実行してしまうと、あとから履歴を見返しても「どちらに向けて打ったのか」を区別する手段がなかった。

そこで、接続先を最初から一意に確定させる書き方(遠隔操作の経路をコマンドの中に明示的に含める)へ、確認作業をやり直した。

「本物である証拠」を先に取る

この経験から、しろまえ殿のチームが徹底するようになったことが3つある。

1つ目。調査を始める前に、まず「これは本当に本番か」を裏付ける一手を打つ。 実在する人の名前、実データの件数など、開発環境には存在しないはずのものを確認してから本題に入る。

2つ目。確認に使うコマンドは、接続先が文字面だけで一意に確定する書き方にする。 省略した書き方は、あとから見返しても区別がつかない。

3つ目。そもそも同じ名前を持たせない。 開発用の環境には、最初から本番と紛らわしくない名前をつけておく。

名前が同じというだけで人は油断する

コードの読み方が間違っていたわけではない。 確認した本人の能力の問題でもない。

ただ、目の前にある2つの入れ物が、たまたま同じ名前を名乗っていた。 それだけで、正しいはずの手順が簡単にすり抜けられてしまう。

「本物だという証拠を、中身を見る前に取っておく」。 地味だが、これが一番効く予防策だった。