何をしてしまったのか

とある基幹システムの更改案件でした。私が担当していたシステムは、ネットワークを通じてHULFTで受けたファイルを他システムに中継する役割を行っているサーバーでした。
サーバーのOSインストールやHULFTなど業務アプリケーションが動作するところまでがベンダーSEである私の担当範囲であり、HULFTで受けたファイルを他システムに連携したりHULFTの定義を修正・更新する役割はエンドユーザーの担当範囲でした。

エンドユーザーとは協力しながらシステムを構築できていたと思います。担当者の方とはお互いに初めて参加するプロジェクトであり、システムの細かい動作については分からないことが多い状態でしたが構築を円滑に進められていましたね。

私「いい感じで構築できてますね！」

そして、エンドユーザーが該当システムで使用しているシェルの中にHULFTで受けたファイルが溜まり続けないようにファイルを削除するシェルがありました。私は気を利かせて、担当外の作業でありましたが、午前0時くらいに実行すればいいなと、あまり中身を確認せず判断してしまったのです。
エンドユーザーは私にほとんど任せていて、最終的にcronにより定期的に動作するように仕掛けました。

私「ちょちょいのちょいっす～」

そして、本番稼働後、事は起きました。
他システムで、私が担当したサーバーに対しHULFTの送信に失敗するアラームが発生したのです。

惨劇はなぜ起こってしまったのか

相手システムのHULFTがエラーを起こした原因は、私がcronで仕掛けたファイルを削除するシェルが原因でした。
他システムからのHULFT受信とファイルを削除するシェルが同じタイミングで動作し、受けたファイルを他のシステムへ転送している途中でシェルがファイルを削除してしまったのです。

幸いにしてファイルを再送してもらうことでリカバリはできました。
しかし、本番ファイルを削除してしまうという事態に、私は真っ青になりました。
社会インフラを担うエンドユーザーの業種ということもあり、この時はこっぴどく怒られたのでした。

偉い人「何がどうなってるんだー、この野郎！！」
私「ひぇええ」

二度と惨劇をおこさないためにどうしたのか

私はシェルの中身を見直し、そもそもシェルの使い方が間違っていることに気づきました。
シェルにはパラメーターとしてファイルの更新日からファイルを削除する日数までの指定ができたのでした。
そのため、以下の2つを改めました。

• シェルのパラメーターを設定し、ファイルが削除されるまでの日数を指定する。
• HULFTの転送が行われない時間帯にシェルを動作するようにする。

この処置により同様の障害が発生することはなくなりました。

真のやらかし

さて、私がやらかしてしまった真のやらかしはシェルの使い方を間違ったことではありません。
私の担当外であるユーザー資産を適用してしまった役割分担のあいまいさにあります。

ユーザーとの役割分担は、要件を決めるときなどにはっきりしておくべきでありますが、ユーザーからの「やってくれるんだよね？」というプレッシャーであるとか、好意で「やっときますよ～」は時として大事故を起こす原因となります。

かみ合わない役割分担

真のやらかしを二度と起こさないためにどうしたのか

では、二度と惨劇を起こさないためにどうしたか、というと、実はどうもしていません。今回の事はすぐに修正することができ、大事に至らなかったため、その当時、気に留める人は多くなかったと思います。
しかし、今回のような大事に至らなかったミスでも、ユーザー・ベンダー関係なく教訓として残したり、属人化せずに引き継ぐ文化があれば良かったと思います。残念ながら、このプロジェクトではそこまでの仕組みを築けませんでした。
そして、私は役割分担のあいまいさについて多くの事を学ぶことができたのでした。

私(もう二度と手伝わないぞ。。。)

おわりに

昨今、金融機関で発生したトラブルがよく目につきますが、私がやらかしたようなことにより世間を騒がしているのかもしれません。このような事故を起こさないためにも、ユーザーとベンダーが役割分担を明確にし、事故を未然に防ぐ文化を作り上げていくことが大事なのではないでしょうか。

きっちりした役割分担

事故を未然に防ぐ協力体制