東京証券取引所のシステムトラブルの原因について、製品(NAS)のデフォルト設定が変わっていたのに、それを富士通側が把握せずに、バックアップ機能「オフ」のまま納品して稼働していたからという、なんともな理由。まぁ、大きなトラブルの原因って、往々にして結構こう言う初歩的で簡単な物なんですよね。それでも東京証券取引所側は、システムトラブルの責任は自らにあるとして、富士通側に賠償責任は要求しないと明言していますが立派。先日のトラブル説明の会見でも、技術的に明瞭に説明していたようで、結構この手の仕事をしている人達からは高評価だったらしい。ただ、取材しているメディア側でちゃんと理解している人は少なかったようで、こちらは不満を言っていたらしいけれど、そこは自らの勉強不足だよなぁ。
記事に添付されている発表資料に、歴代システムの設定値が掲載されていますが、これも一寸変な感じ。バックアップが「OFF」なのに、なんで15秒後に切り替わるんだろうか。それって、バックアップ切替動作のスイッチ設定ではなく、「即時着替えるか、遅延して切り替えるか」の設定スイッチじゃないのか? システムのための設定ではなく、NASの切替のための設定なので、何か初代システムで使用していた機器に、制限とか有ったのかもしれないけれど、コンピューターの「15秒」、ましてや大量のトランザクションをリアルタイでどんどん処理しなきゃいけないこのシステムだと、かなり長い遅延だと思うんですが。それが、二台目からは「即時切替、ON/OFF」の意味に変わったということで、これを機材を調達していた富士通側が認識していなかったのは、その開発部門としては拙いですよね。初代と二代目の間では、この切替設定のデフォルトが、OFFからONに変わっているわけで、当然仕様確認の時にその意図と他に波及する設定などの確認を普通はするはずなんですが。NASの製造元との認識不足なのか、代替わりするときの摺り合わせが足りなかったのか、理由は不明ですが基幹機能の一つだけに仕様確認で漏れたのは痛かった。もう一つは、稼働前のテストケースでこの機能を検証しなかった点ですよね。システム(arrowhead)側の設定内容が変わらないから問題なしと判断したのかもしれないけれど、NAS側のデフォルトが変わっているんだから、そこはシステムの変更点なんだから、その部分に関しては二代目の時にテストケースを流さないと。勿論全てのテストケースを準備して検証することは物理的に無理なことが多いから、多くの場合はテストケースを厳選して、最小労力で最大効果が得られるようにするのが、ある意味テストの醍醐味でありテスト担当者のスキルなんですが、まぁマニュアル(システム仕様書かな)に「前回と同じ」となれば、スキップしちゃうかなぁ... 実際は、初代は「OFF-OFF」の組合せだけれど、二台目以降は「OFF-ON」の組合せなのだから、二台目の時に確認しなきゃいけない項目の一つなんですよね。
トラブル直後の会見で、「即時切替スイッチはOFFだが、自動的に切り替わる設定だった」みたいな説明があって、「???」と思ったんですが、この「15秒後に切り替わる」という前提の話だったのだと、やっと理解出来ました。でも、それならそれで、なんで東京証券取引所側は、システムがトラブったときに15秒もの遅延を良しとしたのだろうか。普通は、ホットスタンバイさせているわけだから、即時切り替えするのが当たり前で、もし何らの理由で15秒遅延を前提にしていたら、それはそれで何かシステムデザインの問題のような気もするし。私が実蔡に自分で管理したことのあるサーバーシステムは、精々ブレードサーバーとNASの組合せ位なので、これだけ巨大なシステムとなると、何か色々理由が有るのかもしれない。でも、サーバー管理者としては、突発的トラブルが発生したときに、いかに透過的にバックアップに切り替えて作業を止めないことを最大目標に日々苦労しているので、何か釈然としないというか、そんなもやもやした印象です。
0 件のコメント:
コメントを投稿