テストで想定外の事象を見つけるのは困難

　ITジャーナリストの山口健太氏はいう。

「全銀ネットはシステムの詳細を明かしていないため推測になりますが、データベースへの問い合わせを多用するシステムでは、データを使いやすい形でディスクに書き出し、あらかじめメモリ上に展開しておくことで高速化を図る場合があります。今回の障害は、そのディスクに書き出したテーブル自体が破損していたと説明されています。今回『謎が深まった』のは2点あり、1つはなぜテーブルが破損していたのか、もう1つはなぜそれを事前に検出できなかったのかという点です。テーブルを書き出すプログラムの問題であれば比較的容易に見つかったと思われるため、まだ発見されていないOSやミドルウェアの障害を引き当てた可能性もあります。

　原因の特定が難しい事例としては、想定を上回る高い負荷が発生した場合があります。しかし問題となったテーブルの書き出しは3連休中の事前準備で実施しており、そうした不確実性があったとは考えにくい状況です。事前に準備したデータをしっかり確認していれば避けられた可能性はあるものの、一般にシステムのテストにおいては何をテストするかを事前に決め、それが通ればOKとするため、想定外の事象を見つけるのは困難です。なぜ破損に気付くのが遅れたのかという点についても、原因究明が待たれるところです」

　大手ベンダSEはいう。

「参照・読み込み先のDBやテーブルなどのファイルが壊れていることによる障害というのは、ありがちな障害といえ、珍しくはない。今回の件で不可解なのは、前日までのテストでは問題がなかったという点だ。RC内部では主記憶に生成プログラムをロード・実行し、ディスク内にテーブルを生成し、それを主記憶にコピーしてRCに読み込ませているということだが、ハードの入れ替えで環境が変わったことで何らかのプログラム不具合が生じるというケースは普通にあるが、テストで拾えていたはず。テストケースから漏れていた可能性もあるが、さすがにインデックステーブルがテスト項目から漏れていたとは考えにくい。環境が変わればそれに乗っかるプログラムやテーブルのつくりも変えなければならず、それによって予想外の動作が生じることは避けられないが、テストで不具合を拾えなかったというのが一番の問題。いずれにしても、事象の性格上、原因の特定には時間がかかるだろう」