EURO SELLERの悠遊通信

東証：システム障害で金融庁が改善命令検討
これだけシステム障害が頻繁に起こると，市場の東証に対する信頼は薄れてしますが，扱っているシステムベンダー(富士通？)のクォリティにも疑問符がつきますね。

今年に入って東証で起きたシステム障害は以下の３つです。

【2月8日】平成20年3月を限月とするTOPIX先物の前場の終値計算処理での不具合
特定された原因はメモリの初期化エラーだった。システムは通常，前場立会終了時刻が到来した時点で，立会終了間際に発注された注文のうち処理待ちとなっている注文を取引板に登録し終値を算出するが，この登録の際に行うシステムのメモリ上の特定の領域の初期化が実施されなかった。結果的にこの領域に残っていたデータが影響してしまい，板に登録するべき注文の値段が不正な値になってしまう不具合が発生。
※偶然，ゼロフィルされていたデータによって動いていたという恐ろしさ。なんとも言い訳ができない。

【3月10日】アルプス電気と名古屋鉄道の株式売買の一時停止を引き起こしたシステム障害
同時に多数の銘柄を売買する「バスケット取引」で，同じ証券会社から同一銘柄の注文が短時間に集中したため起きた。注文をデータベースに登録する際，ほかの注文が書き込まれないようロックをかけるが，ほかの注文がロックが解除されるまで繰り返す登録の再試行回数が100回に制限されていたため，上限回数を超えて2銘柄の注文が登録できない「デッドロック」が発生しシステムが停止。
※再試行回数を100回にした理由が不明確なだけでなく，エラー処理が甘すぎる。こういう場合は単位時間当たりの注文の回数にも何らかの制限や調歩メカニズムを入れないと，今度は無限の再試行が別のデッドロックを引き起こす可能性がある。

【7月22日】デリバティブ売買システムの障害
板情報を配信するプログラムは本来，1銘柄当たり1280バイトの作業用メモリー領域を2万8000銘柄分，合計3万5000Kバイト確保するよう記述しなければならないが，1銘柄当たりのメモリー領域を誤って4バイトとしてしまったため，プログラムは本来の320分の1の109.375Kバイトしか確保しなかった。結果として89銘柄以上の板情報の問い合わせが同時に発生すると，作業用メモリーが足りなくなり情報配信システムがダウンした。
※1銘柄当たりのメモリー領域を即値で作業メモリ領域のストラクチャと無関係に記述していたのが問題であり，これも言語道断である。

どれも初歩的なプログラムミスで，本来正しい設計がされていれば起きないはずのものです。この面では情報システムベンダーのＳＷエンジニアリングの品質の低下が真っ先に問われるべきです。しかし，初期化されていないメモリ領域を参照すればコンパイル時に警告が出るのが最近のプログラム言語での仕様でもありますので，相当古い言語で書かれたコードが現在も使用されているに違いありません。東証は大証を見習って別のベンダーでシステムをリニューアルしたらどうですか？