東証システムトラブルの原因

 今月初めに発生した、東京証券取引所のシステムトラブルの原因は、バックアップシステムに切り替える設定で、今回の様なメモリー故障が原因の場合は「切り替えない」設定にして居たことと言う、なんとも不可思議な理由。「メモリー故障」の定義には、それこそハードウェアの故障から、ソフト的なECCエラーとか、一緒くたにしていたのだろうか。それで、リカバリー方法は、リトライとかやって動作確認して、それでも解決しない場合にはホットスタンバイで切り替えるというようなデザインなのかな。その場合、ソフトエラーでリカバブルなら良いけれど、今回の様に一発で死んでしまうようなケースでは駄目ですよね。

稼働前のテストでは、1号機・2号機の死活監視を途絶えさせても切替は成功したと書かれているんですが、どう言う方法で途絶えさせたのか、それも分からないと何とも言えないけれど、テストケースの不備のような気がする。「死活監視を途絶えさせる」というのが、相互にモニターする要素を全て遮断する事とすれば、当然バックアップ側は異常事態と判断して切り替わるでしょう。今回の場合は、メモリー故障でマスター側のシステムが動作異常を発生させたと思われますが、その時にバックアップ側でモニターしている要素のうち、例えば10箇所のうち数カ所に不一致が発生したと判断されたなら、そのまま切り替えずにもっと致命的な状態になるまで待機するのはあると思う。でも、待機しているうちにマスター側がダウンしてしまい、切り替える暇無くバックアップ側も運営によって止められた、と言う話なんだろうな。

昔｢診断プログラム(Diagnostic Program)」を作っていたことがあるので、多少はこのあたりの知識は持っているつもりですが、メモリーテストが一番難しいテストの一つなんですよね。当時は、まぁメモリーもピンキリあったからわざと不良率の高いメモリーとか使ってテストするとか出来たんですが、最近のものは品質が良いから多少のストレスを掛けた位じゃ、なかなか目的とするエラーは再現できない。テスト用に細工するツールも作ったりしましたが、そうすると本来の状態とハードウェア的に状況が異なってくるので、その状態でOKでも実際の環境ではNGだったこともありました。また、メモリーテストを実行するためには、CPUとメモリーは最低限動作していないとテストプログラムも動かないわけで、そうなると鶏と卵の話にもなってきます。だから、メモリー上で実行させるのでは無く、CPUのキャッシュに取り込ませて、CPU単体で動かしたりするようにしましたね。これは、処理速度の面でも有利になるんだけれど、当時のCPUキャッシュは精々数KBとかいう単位だったから、コードサイズにも注意していたし。色々思い出すなぁ...

今のシステム、特にこう言うミッションクリティカルな場所で使われるシステムは、多分殆どカスタムモデル位手が加わっていて、そう単純では無いと思うけれど、システム系が複雑化すればするほど、またバックアップとかそれに関連した処理も複雑になるし、それに伴ってテストケースも複雑化していくのが普通。そんな中で、カバーしきれない部分に運悪くはまってしまったのか、あるいはそれこそ単純な設定ミスだったのか分からないけれど、そう言う経験値を次にどう繋げていくかが、一番重要。より堅牢性の高いシステム作りにどう繋げていくかが、富士通の試練でしょうね(偉そうなこと言うけれど-笑)。