東証FLEXシステムのダウンは単純なテスト不足

東証のFLEX(株式やCBなどの取引システムの名称)システムが落ちたのは月次バッチ処理での領域圧縮?
どういうつくりをしてるのか分かりませんが、ずいぶんトリッキーなつくりをしてますね。

私が見てるシステムは東証や大証を相手にする注文約定システムです。要するに証券会社側のシステムです。
そのシステムでも、今回の現象と似たような「コードから顧客情報を引き当てるために読ませるマスタ台帳のDB」を読ませることをしますが、毎朝起動時に、OracleのAPIを使ったアプリで読み込ませて、オンメモリにしてます。だから、同じことは無いんですがね・・・

うちらのシステムにも年に一回だけ走るバッチ処理がありますが、
休日に年変わりを想定した試験をしました。

私が行っている会社は、社内規定でシステムを作り変えたり、新しいプログラムを入れたりする場合、第三者による徹底的なテスト仕様のレビューという粗探しが行われます。想定外の試験は? こうなった場合の試験は?とかなり手厳しいレビューを通り抜けてやっと、テストが出来るようになります。。その後、そのテストに合格してやっと納品という手段を通っているので、当然、「もし東証が落ちた場合どうなるの?」という試験はやっています。ですので対応策は取れました。
ただ、その対応策がまさか本当に起きるとは思っても無かったので、ファイルサーバの奥深く、バインダーの奥深く、そして各人の記憶の奥深くに沈んでいたので、それぞれを引っ張り出すのにちと時間がかかりましたけどね(^^;

対策はしておいたおかげで、「これから復旧した後どうしようか?」という行動を決める会議でも、お客さんとコーヒーを飲みながら「なーにやってんだろうねぇ〜東証は・・・」と話している余裕が出来ました。
後々楽に過ごすためにも、ちゃんとテストはやっとかなきゃといういい教訓にもなりましたよ。

もし、道連れでウチのシステムまで落ちたら、この会議は突き上げの場になったでしょうしね・・(笑)

新しいことをやるときは、面倒がらずにちゃんとテストをしましょう。

Posted by thomas at 2005年11月03日 03:14 | トラックバック / アフィリエイトはエーハチネット