はじめに
数年前にシステム開発をしており、そのときに客先NASのデータをすべてrmした話です。
このシステムは複数のサブシステムとNASで構成されていました。
１つのサブシステムの開発を担当しており、不具合改修のためにアップデートを行った時の今回の事件を引き起こしました。
事の発端
いつも通り不具合改修のためのアップデートをすることになりましたが、私は忙しくてシステムがある現地へ赴くことができませんでした。そのため、今回のアップデートを別サブシステムの開発担当であるA君に現地作業ついでにお願いをしました。アップデート作業自体はアプリケーションを停止させて、アップデート用shellscriptを動かすだけの簡単な作業でした。
この日の夕方、現地にいる課長から電話がかかってきました。
「A君にアップデートをしてもらってるんだけど、今現地でNASデータがすべて消えたって大騒ぎなんだ。タイミング的にうちの作業中なんだけど、うち関係ないよね？」
全然心当たりが無かったですが、一応調べておくことにしました。
shellscriptを調べてみる
このサブシステムは、以下のようなディレクトリ構成になっています。
root/
├app/
│└ EXE
├lib/
│└ LIB
└data/
└ MOUNT
アップデート用shellscriptの中身を見てみると
rm -rf /app
rm -rf /lib
rm -rf /data
となっている行がありました。アプリケーションを入れ替えるために一度すべてのファイルを消していたのです。
犯人を確信しました。私ですね。
今までも何回もアップデートを行ってきました。しかし、なぜ今回発生したのか。
なぜ今回発生したのか
事件発生時の経緯はこのようになります。
- バグの再現実験を実施
- バグの影響でアプリケーションが落ちる
- アップデートを実施
アプリケーション停止時は必ずマウントを解除するようになっています。
しかし、バグによりアプリケーションが落ちたため、マウントを解除する処理が走りませんでした。
その結果、上記shellscriptにより、マウントディレクトリごと、つまりNASごとrmされてしまいました。
事件発生の原因は以下の3つになります。
サブシステムを全く知らない人による作業
事件の引き金を直接引いたA君は別サブシステムの担当で、こちらのサブシステムは一切触ったことがありませんでした。そのため、どこでマウントされている、など知りませんでした。
もし、サブシステムを知っている人であるなら、まだマウントが解除されていないことに気づけたかもしれません。
システム設計がまずかった
マウントしたままrmするだけだと、自サブシステムのNASデータ領域しか削除されないように見えますね。
しかし、このサブシステムはNASのrootにマウントをしていました。
本システムは別のサブシステムのデータを使う必要がありました。そのサブシステムとデータを共有するための領域を作成するでもなく、そのサブシステムの領域をマウントするでもなく、NASのrootをマウントするという愚行を犯しました。
その甲斐あり、NASデータをrootごとすべてrmすることができました。
（システムの特性上、権限がすべて付与されていたのもシナジーを生み出しました。）
アップデート用shellscriptの中身を全然知らなかった
システムの担当者である私は、この事件が発生するまでshellscriptの中身を見たことがありませんでした。つまり、何が行われているか把握していないshellscriptでアプリケーションの本番環境アップデートをかけ続けていました。
開発体制がかなりやばかったこともあり、全然手が回っておらず、まったく中身を見たことがないソースコードなどが大量にありました。それでも、リリースをしなければならないため、テストを一応通過したものがリリースされ続けていました。このshellscriptも外注さんがテスト環境用に作成したものをそのまま使いまわしたものでした。
対応を策定
事件発生後に、これらの原因をもってメンバー全員と共有し、対応策を決めました。
- 手順書を作成し、確認しておくべき結果も記載すること
- NASの使用しない領域をマウントしないこと
後日談
後日、現地から帰ってきた課長に聞いた事の顛末です。
NASデータは直前にフルバックアップをかけていたこともあり、重要なデータは失われずに済んだそうです。
A君も現地でshellscriptの中身を見て、原因に気づき、かなり顔が蒼白していたみたいです。
原因がその場で発覚したため、顧客に謝罪を行い、他サブシステムでも同様の事件が発生しえないか調査するようにと大号令が出されたみたいです。
データ復元が問題なく行えたため、大問題に発展せず、身内では笑い話になりました。
なお、開発体制のやばさは解消されることなく走りきることとなりました。
開発体制はプロジェクト開始前にしっかり検討しましょう。大事件になりえます。