パスワードを忘れた? アカウント作成
30781 story
ビジネス

東証の派生売買システムで障害、4時間取引停止 94

ストーリー by hylom
なぜ88になったのかが気になる 部門より

soara 曰く、

東京証券取引所の東証株価指数(TOPIX)先物や国債先物取引を行う派生売買システムで、7月22日取引開始直後から注文状況を表示できないトラブルが発生した。その影響で、9時21分から13時45分まで派生商品の取引を停止した。

東証は今回のトラブルの原因をつかみ対応を済ませたとして、7月23日は通常通り取引を行う

NIKKEI NETの記事によると原因は、連休中のシステム改修適用の際、売買注文状況を示す「板」のデータ容量の上限を 2万銘柄とすべきところ、88銘柄に設定していたためとのこと。

これにより、板に89銘柄を超えた問い合わせがあるとシステムが停止してしまうというトラブルが発生していたということだ。なお、今回のシステムを開発したのは富士通で、状況によっては損害賠償の請求も検討するとのこと。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ちょっと違う (スコア:4, 参考になる)

    by Anonymous Coward on 2008年07月23日 11時38分 (#1388897)
    >データ容量の上限を 2万銘柄とすべきところ、88銘柄に設定していた
    データ容量のサイズが28000銘柄分のはずが88銘柄分しか確保できてなかった。

    http://itpro.nikkeibp.co.jp/article/NEWS/20080722/311271/
    • Re:ちょっと違う (スコア:5, 参考になる)

      by hylom (27448) on 2008年07月23日 11時47分 (#1388907) ホームページ 日記
      なるほど。データのサイズを誤っていたのですね。しかし、1280バイトのはずのデータを、4バイトに間違えるってどんなミスだよ……。

      板情報を配信するプログラムは本来、1銘柄当たり1280バイトの作業用メモリー領域を2万8000銘柄分、合計3万5000Kバイト確保するよう記述しなければならない。だが、1銘柄当たりのメモリー領域を誤って4バイトとしてしまったため、プログラムは本来の320分の1の109.375Kバイトしか確保しなかった。結果として89銘柄以上の板情報の問い合わせが同時に発生すると、作業用メモリーが足りなくなり、情報配信システムがダウンした。
      東証のシステム障害、設定ミスをテストでも見抜けず:ITpro [nikkeibp.co.jp]より)
      親コメント
      • by x-rebuttal (33869) on 2008年07月23日 12時06分 (#1388925)
        sizeof(HogeHogeObj)を間違えてsizeof(HogeHogeObj*)にしたとかでは?
        親コメント
        • by Anonymous Coward on 2008年07月23日 12時34分 (#1388961)
          なんだかおなじような回答がわずかな時間差でいくつも投稿されてるてことは・・・
          皆さん現役の方ですよね。世の中にはこの手のバグを飼ってるソフトが多数出荷されてるってことになりますか。
          親コメント
          • by Anonymous Coward on 2008年07月23日 13時07分 (#1389028)
            ふつうに 4byte というサイズになる原因として、ポインタのサイズが連想しやすいからだと思います……思いたいです。
            同時に、東証のシステムが 64bit 化されていない事も推測できる、と w
            親コメント
      • > 1280バイトのはずのデータを、4バイトに間違える

        sizeof(DataType) のつもりが sizeof(DataType*) になってたとか?

        …っていうのは、やっちゃったことあります。マクロ化してて、引数の型を間違えたりとか…
        #define alloc(type,count) malloc(sizeof(type)*(count))
        DataType *p = alloc(p, count);
        ってな感じのコードだったかな。
        親コメント
        • Re:ちょっと違う (スコア:1, 参考になる)

          by Anonymous Coward on 2008年07月23日 17時33分 (#1389286)
          そのマクロ定義だと、たしかに起きがちですね。
          そういう間違いを防ぐため、以下のようなマクロを使うことにしてます。

          #define MALLOC1(p) ((p) = malloc(sizeof(*(p))))
          #define MALLOCN(p,n) ((p) = malloc_array((n), sizeof(*(p))))

          なお関数 malloc_array() 内では、整数オーバーフローのチェックが必要です。
          親記事の alloc() マクロは、その点でも問題がありますね。
          親コメント
      • Re:ちょっと違う (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2008年07月23日 12時11分 (#1388931)
        設定ミスってより、テストや品証のミスといいたくなるなあ。
        これって最大値のチェックが抜けていたって事でしょ?
        原因は確かに設定ミスだけど、この程度なら、ちゃんとテストすれば発見出来る障害だと思うんだけど。
        親コメント
      • by strict_ansi (2886) on 2008年07月23日 12時13分 (#1388936)
        > しかし、1280バイトのはずのデータを、4バイトに間違えるってどんなミスだよ……。

        構造体実体のサイズを使うべき所で、構造体へのポインタのサイズを使ってしまったのでは…。

        typedef struct _Hoge   Hoge;
        typedef struct _Hoge * HogeP;
        struct _Hoge {
          char something[1280];
        };
        上記のような定義があって、
        sizeof (Hoge) * 28000」とすべきところを、
        sizeof (HogeP) * 28000」としてしまった…、に1票。
        親コメント
  • by blackdrug (13208) on 2008年07月23日 11時40分 (#1388900) 日記
    別の設定項目の変数が88という数字が入る予定で、
    変更する変数を誤った、と考えるのが妥当でしょう

    変数名が適当だったんじゃないのかな?
    • by Anonymous Coward
      境界条件のテスト・デバック用の(設定ファイル?)がそのままリリースされちゃったんじゃない?
  • 上限数をわざと絞って、エラー処理の動作が所期の通りであるのを確認したのはいいけど、試験の後で本来の値に戻すのを忘れたとか。
    --
    --- Toshiboumi bugbird Ohta
    • Re:試験のために (スコア:3, すばらしい洞察)

      by Anonymous Coward on 2008年07月23日 12時15分 (#1388940)
      上限2万の最大値テストはしてなかったとしても、
      たった89銘柄で落ちるってことは全然テストしてなかったに等しいでしょ。
      東証は「丸投げしてて、うちにはテスト仕様書検査する人間すらいないんです、てへ」と公言した上で訴訟とかもうね。
      親コメント
    • Re:試験のために (スコア:1, 参考になる)

      by Anonymous Coward on 2008年07月23日 11時54分 (#1388914)
      「上限数の事前テストはやっていない(だから事前に発覚しなかった)」と既に発表されていますよ.

      「人為的ミスの可能性が高い」と言っているので,既に挙げられている「変数間違えちゃいました,てへへ」の可能性が高い気がしますね.
      親コメント
    • 上限を絞るのは上限の設定に引っかかるかどうかの試験にしかならないので、それじゃ試験としてダメな気がする。
      # 実際はどうなんだろ。
      親コメント
      • おっしゃる通り、いわゆる「ストレステスト」が目的ということならば、上限値を絞るというのはテストにはならんですね。

        で、納期的にゆとりがあれば、本当にシステムを壊しちゃう覚悟で(もちろん事前にバックアップを取っておいて復旧させる… リストアのテストを兼ねることになるし)ストレステストをやることもあるんだけど、今時はそう云う時間とコストをかけにくいよね<開発現場の事情
        --
        --- Toshiboumi bugbird Ohta
        親コメント
    • by s02222 (20350) on 2008年07月23日 14時08分 (#1389109)
      そして試験だけじゃなく実地でもエラー処理が正常に動作することが確かめられてよかったね、と。
      親コメント
  • by 127.0.0.1 (33105) on 2008年07月23日 13時50分 (#1389087) 日記
    >なぜ88になったのかが気になる部門より.

    Ω<プログラミング担当者がエリア88のファンだったんだよ!!
    ΩΩΩ<な、なんだってー

    #それはないだろ
  • by Anonymous Coward on 2008年07月23日 11時40分 (#1388899)
    お取り潰しも辞さないと思うが、どうか
  • by Anonymous Coward on 2008年07月23日 11時40分 (#1388902)
    東証なんかのコメント見てると緊張感ないなぁ。富士通も同じ感じかな。

    投資家、つか海外機関投資家に見捨てられると言うか見捨てられつつあるって分かってるのかなあ。

    富士通は取締役総退陣ぐらいのミスだと思うんだけど。

    • by SteppingWind (2654) on 2008年07月23日 15時36分 (#1389190)

      富士通の競合のSIerも, この機に乗じて食い込もうとする腹が無いんじゃないかな. 最近の大型システムでは, ハードの利益なんかシステム構築の失敗で簡単に吹っ飛ぶので, 顧客側の体制がダメだとWin-WinならぬLost-Lostの関係にしかならないんですよね.

      それを知った上での相互なれあい体制じゃあないかと思うんですけど. 東証が事実上, 国内では独占しているので成り立つ図式じゃないでしょうか. というか殿様商売?

      親コメント
    • by Anonymous Coward
      予の顔を見忘れたか?と言いたくなるような醜態
    • by Anonymous Coward
      アメリカなんかの方がもっとおおらかだって聞くけどねぇ。
      銀行のオンラインとかちょっとダウンしたぐらいじゃ気にしないとか。

      まぁ、証券市場じゃ洒落にならないかもしれないが…。

      ミスがあったら叩くだけじゃ、よりいっそう萎縮するだけで意味無いですよ。
      犯人捜しして袋だたきっていう日本人の悪癖は改めなきゃ。
      ちゃんと原因究明と、再発防止のための「システム」を作る方向に向かないと、建設的とは言えません。

      人間はミスをするって前提でシステム構築やテストを実施しないとね。
      今回のも、えらく単純なケアレスミスだったじゃないですか。

      ※とはいえ、富士通はなー、とは思う…。どーせ下請けに丸投げじゃねーの?
  • by SteppingWind (2654) on 2008年07月23日 11時48分 (#1388908)

    本来28000「レコード」の容量を確保するところを28000「バイト」にしちゃったとか. 1レコード318バイト(何かありそうな数字)とかだと計算が合いますから.

typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

読み込み中...