|
|
特定非営利活動法人失敗学会 |
広告掲載について | 広告掲載について | 広告掲載について | 広告掲載について |
|
東証システム障害
サイドローズエルピー、ゼネラルパートナー
飯野謙次
【シナリオ】
【概要】 2005年11月1日、世界第2位の取引高を誇る東京証券取引所(以下、東証)の株式・CB売買システムがダウン、 売買開始の午前9時から午後1時29分までの間、東証一部、二部の株券、転換社債型新新株予約権付社債券、 交換社債券の合わせて2,520銘柄の売買が停止した。 インターネットを介して株の売買を行う投資家などから復旧のめどを問い合わせる電話が証券会社に殺到した。 また、大阪証券取引所(以下、大証)と重複上場している銘柄の注文が大証に殺到し、 売買情報の配信が遅れるトラブルも発生した。 インターネットを利用した株売買の普及とともに売買数が急激に増えていたのに対応して、 同年10月に、システムの処理能力をおよそ20％強化した際、その変更とは直接関係のない部分もついでにバグ修正したのだが、 その修正を本機に搭載した際に手順の指示漏れがあった。およそ2週間、問題を抱えたまま、 表面的には不具合を起こさず稼働していたのが、月の変わり目でシステムがファイルの自動整理を行った際に問題が顕在化し、 システムが正常に立ち上がれなくなった。証券取引に関する東証の社会的信用は大きく損なわれ、役員の減俸があり、 同年12月のみずほ証券誤発注を取り消せなかった不具合の後、トップ人事の更新が行われた。 【発生日時】 2005年11月1日 【発生場所】 東京証券取引所 【登場団体と背景情報】 東証(東京証券取引所)：創業は、1878年に前身の東京株式取引所。従業員は 361名。 2006年度売上高は約 628億円、営業利益は約 271億円。東京において、金融商品の取引を行う取引高世界第2位を誇る証券取引所。 1999年4月30日に株券売買立会場が閉場され、現在では、ほとんどの取引がオンラインで不具合を起こしたシステムを通して行われる。 東証コンピュータシステム(以下TCS)：その前身、株式会社東京証券計算センターは、1961年に東証機械計算部門から分離。 従業員数200名。2007年度売上高は約51億円。東証のシステムの管理運用を主な業務としており、その他にも汎用金融系ソフトウェアも販売、 サポートしている。 2004年、株式会社プライムシステム(現株式会社サンライズ・テクノロジー)は、当時保有していたTCS株(64.5%)を全株、 富士ソフトABC株式会社（現、富士ソフト株式会社）へ譲渡した。TCS株の残り35%は東証が保有している。 富士通：1935年、富士電機製造株式会社(現・富士電機ホールディングス株式会社)の電話部所管業務が富士通信機製造株式会社として分離して設立された。 従業員 27,310名、2007年度売上高は 2兆9791億円、営業利益は 2050億円。 官公庁や大企業向け大規模システムの開発、保守をはじめ、各種コンピュータ、ソフトウェア、電子デバイスなど、 コンピュータに関する製品の開発、販売、保守をしている。 TCSの筆頭株主、富士ソフトは富士通と資本関係はない。 このような大規模システムでは、ハードウェア、ソフトウェアともに納入したきりということはなく、 不具合の修正や機能の増強を含めた保守契約がなされる。通常の保守は図1に示した手順でなされる。 すなわち、富士通がモジュールを修正し、それを東証に納入。東証では、システムの保守管理を委託しているTCSが修正を本機に搭載する。 この際、新しく修正されたモジュールは移行ライブラリと呼ばれる仮置場に置かれる。 修正されるモジュールの機能がサーバーにより呼び出された場合、移行用ライブラリにあるものが優先的に呼び出されるため、 その機能の本番組み込みテストを行っていることになる。つまり、モジュールを修正した結果、問題が発生した場合、 移行用ライブラリに搭載した修正モジュールを削除することによって、 正本ライブラリに保存されている修正前のモジュールが提供している機能が起動し、少なくとも修正を試みる前の状態に戻るわけである。
モジュール：コンピュータプログラムは、複数の関数定義とデータ構造定義からなっており、
それら定義を機能や、操作対象によって複数を1つのグループとしてまとめると設計や保守がやりやすい。
そのまとまりをモジュールと呼ぶ。1つの関数で1つのモジュールとしても良いし、
複数のモジュールをまとめて上位のモジュールとしても良い。
 図1 通常の保守手順 【経過】 本事件について、後から判明した事実も含めて、時系列にその経過を示す。 2005年10月8日(土)～10日(月) [連休] 株式売買に使う業務サーバーの処理能力を1日620万件から750万件へと増強するため、業務サーバーを更新。 作業2日目の10月9日に、少なくとも2004年9月からあったバグに気づく。 このバグが、東証の説明によると、注文受付処理にかかわるもので注文増加の状況によっては不具合が発生する可能性があったため、 9日のうちに修正することを決定した。このとき修正を施したモジュールには、本名とエイリアス があるが、 富士通はこの作業で、修正モジュール格納領領域の定義を、本名とエイリアスの両方について正しく行った。 ただし、図1の通常手順を踏まず、図2にあるようにコード修正を行う富士通が直接、本番機の移行用ライブラリにあるモジュールを修正した。
エイリアス：英語の Alias、別名のこと。情報産業で、要素にエイリアスを設定することで、
実体は1箇所にしかないものを共有したり、複数要素の集合体のグループ名を、エイリアスとして1つだけ指定し、
実際は同時に複数要素を対象にしたりすることで、操作や保守の簡素化などに有効に使用することができる。
ちなみに前から用意していたと思われる業務サーバー処理能力増強のための修正は、図1の手順を通って正しく行われた。
 図2 10月9日に行われたバグの修正 2005年10月11日(火)～12日(水) 移行ライブラリに、業務サーバー処理能力増強とバク修正をした新モジュールを搭載した状態でシステムは正常に立ち上がり、 これら新モジュールに起因する問題は発生しなかった。 2005年10月13日(木) 10月11日より、システムが正常稼働したことを受け、TCSは業務サーバー処理能力増強の修正モジュールと、 9日に行ったバクを修正したモジュールを移行用ライブラリから本番機ライブラリに移動した。 この際、業務サーバー処理能力増強の修正モジュールは、移行ライブラリへの搭載を自分たちで手順通り行ったため、 その搭載手順と本番機ライブラリへの移動手順が自動的に比較され、問題なく進んだ。 一方のバグを修正したモジュールは、富士通が直接移行ライブラリに対して修正を加えたため、搭載手順の自動記録がなく、 富士通が用意した手順書に従ってTCSが移動作業を行った。 この手順書には、修正モジュール格納領域の定義を本名については正しく指定してあったものの、 エイリアスについても行うことの指示が抜けていた。 2005年10月14日(金)～31日(月) システムは、構成が間違ったまま、表面上は問題なく稼働し続けた。その理由は、修正前のモジュールが残っており、 11月1日にシステムの立上げができない原因となった取引参加者情報の取得処理で、 旧モジュールが定義していた本名とエイリアスの関係により、システムが正しい情報領域を参照できた。 10月31日(月) 夜間、ディスクのデフラグメンテーション を行う目的で自動月次バッチ処理 を行った。 このとき、残っていて修正されたモジュールの本名とエイリアスの関係を正しく定義していた旧モジュールの名前が自動的に変更された。
デフラグメンテーション：逐次処理などで、大小様々なファイルがディスク上にばらばらに、
また空きエリアも散在している状態になる。ばらばらになったファイルをひところに集め、
ファイルの内容をアクセスする時間効率を高め、
同時に散在している空きエリアを詰めて使えるディスクの空き容量を増やす作業のこと。 バッチ処理：命令が発行されるたびに次々にこなしていく逐次処理と違い、計算機の処理能力を一定時間、 独占して行うまとまった処理のこと。このため、逐次処理要求が少ない、あるいはない夜間や休日に行うことが多い。 11月1日(火) この日の経過を表1に示す。
ToST NeT：Tokyo Stock exchange Trading Network system の略。1998年に導入された電子取引ネットワークシステムで、立会外取引を対象としている。
また、この東証の売買システムを使用している札幌証券取引所、福岡証券取引所も同様、売買が停止した。 東証ではこの不具合に対応している間、取引参加者宛てに、7:48の最初のFAXを皮切りに、5分から40分間隔で立会開始のめどなどについて計16回FAX送信をした。 また、9:45、13:00、翌11月2日19:00の計3回記者会見を行った。 【対処】 取引参加者・メディアに対する対処 東証ではこの不具合に対応している間、取引参加者宛てに、7:48の最初のFAXを皮切りに、 5分から40分間隔で立会開始のめどなどについて計16回FAX送信をした。 ただし、16回のうち、2回はToST NeTが通常通り動作していることの通知。 また、9:45、13:00、翌11月2日19:00の計3回記者会見を行った。 不具合修正の対処 6:30に開始された最初の立ち上げに失敗したのち、以下のリトライを試したがすべて失敗。 1．(7:09)単純にリトライ 2．(8:14)クリア処理後リトライ 3．(8:36)エラー箇所をSKIPしてリトライ 4．(9:10-10:25)一旦システムを停止、ファイル初期化後リトライ 一方、6:47 の内部連絡を受けた富士通では、その時点で原因調査を開始している。 しかし、上述のように計4回のリトライを行っており、その時はシステムが立ち上がるのを待つわけだから、実質的に原因調査は中断していたと思われる。 最後に行ったシステム停止、ファイル初期化後のリトライは、実に1時間15分を要した。 富士通が原因を特定したのが11:25だから、通知を受けてから4時間38分後になる。 しかし4度のリトライ時間を考慮に入れると、原因調査にかかった時間は実質3時間もなかったのかもしれない。 【対策】 本事件の不具合を受け、東証は同月15日に、対応策を発表した。再発防止措置をまとめると以下のようになる。 システム運用手順の東証内部の変更 1．システム修正とプログラムの移行に関し、その手順とチェック機能を見直す 2．システムの立ち上げ時間を当時の 6:30 から2時間程度早める 3．システム開発を中心に、組織体制の見直し 外部からの支援 4．外部有識者や専門家によるシステム監査、手順検証、基本構成の見直し 5．セキュリティに関して外部認証資格の取得を目指す システムそのものの見直し 6．システムのバックアップ体制を見直す また、本事件を受け、東証では懲罰的処分として、当時の社長の月額報酬を6ヶ月間50%カットしたのをはじめ、 ほか6名の役員の報酬カット、役員1名、売買システム部長の2名に厳重注意を行うことを11月10日に発表した。 その後、同年12月21日に社長兼務となった当時の取締役会長は自ら申し出て月額報酬を6ヶ月間50%カットされている。 一方の富士通では、東証の処分に呼応するかのように、11月25日、代表取締役社長の月額報酬を6ヶ月間50%カット、他役員も減俸の処分を受け、 取締役会長は自主的に月額報酬を6ヶ月間50%カットした。 ただし、富士通の処分は同年11月4日に起きた名古屋証券取引所の立会開始延期のトラブルも含めた対応である。 【考察】 本事件では、当事者の東証、そのシステム管理を任されていたTCS、システム開発・保守業者の富士通の3者に亘って、 大規模システムの管理において体制に不備があったと言えよう。 バックアップ 11月1日朝、システム障害が発生して立ち上がらなくなった。7時頃に単純リトライするのは、通常の対応だろう。 しかし、最初のリトライという対処が失敗した後、このような大規模システムを運用している者がまず考えるのは、10月30日は問題なく稼働していたのだから、 その状態にシステムを戻そうということである。それを検討した様子もないのは、システムのバックアップがなかったからであろう。 また、東証のシステムは銀行等のオンラインシステムと違い、24時間稼働ではなく、午前9時から午後3時までのたった6時間の連続稼働をすればいいものである。 その日の売買取引が終了したなら、残った時間の中で、システムのバックアップを行うことは日常作業の1つとするべきだろう。 この作業をやっていなかったのは、大規模システムの運用では考えられないことだが、それを、たとえばシステムの変更を行う前のみ、 などとしてしまうと、今回のように月末の自動ファイル整理などが見落とされてしまう。やはり、取引のあった日は売買取引終了後、 システムをバックアップすることを日常業務とするべきである。 たとえば曜日別のバックアップエリアを確保しておいて、 1週間が過ぎたら古いシステムバックアップファイルは削除してそのエリアに新しいものを書き込めばいいのである。 おそらくは、データベースのデータだけを毎日バックアップしてそれでよしとしていたのであろう。 これもやっていないということであれば、それこそ大問題である。 システム修正の手順 東証によると、モジュールの修正は富士通により修正されたものを受け取ると、それを移行ライブラリに搭載し、 そこで2、3日実際の売買に使用して問題がなければ本番機に移動して修正が終了する(図3(a))。 何気なく読めば、お試しをしたのち、実機に搭載するのだから注意深くことを進めているように見えるが、大規模システムでこのようにずさんな運営はあまりない。 図3(a) に示した東証のやり方だと、実動前の重要な運用テストをなんと実機で行っていることになる。 さらにテスト項目は、2、3日の間にユーザが発生した注文等をうまくこなしたことでよしとしている。  図3 プログラム修正(東証式と通常の大規模システムの比較) 当該システムほどの大規模の基幹システムでは、図3(b)に示したように、 試験やバックアップ等を行う目的で本番機と全く同じ構成と搭載ソフトを持ったミラー機を持つのが普通である。 そして修正されたモジュールに問題がないかを確認するのに、期間内にユーザが発生した注文への応答を確認することでは全く足りない。 そうではなくて、入力ミスも含めて想定できるあらゆるタイプの注文をシステムに対して発信し、システムの挙動を確認しなければならない。 一般に大規模システムのテストでは、あらゆる入力に対する挙動を確認することは不可能であるとされている。 全くその通りで、たとえば1円から100万円の範囲を1円刻みで全ての銘柄に対して注文を出すテストというのは実際的ではない。 銘柄数を1,700、買いと売りの2種類の注文があり、各注文の処理に1秒かかると仮定すると、総テスト時間は 106 * 1,700 * 2 = 3.4 * 109、 すなわち34億秒かかることになり、テスト終了まで100年以上を費やすことになる。 しかし、あらゆるタイプの注文、例えば、売り注文価格を越える、ちょうど同じ、下回る、大きく下回る、大きく越える買い注文の5通りとすれば、 全銘柄の買いと売りの2種類について17,000秒、すなわち5時間足らずで終わってしまう。 これも、全銘柄に対してテストをする必要はなく、代表的な状態にあるものに対してのみでよいから、100通りもテストすれば十分であろう。 大規模システムでは、テストケースの管理が非常に重要なプロセスである。それは想定されるタイプの入力を網羅するものであり、 運営中に発生した入力が用意されたテストタイプにないとすると、その処理がうまく行った、行かなかったに拘わらず、 それをうまく捕えてテストケースに追加しなければならない。大規模基幹ソフトウェアの保守・運用には重要なプロセスである。 今回の不具合では、本番機への搭載手順を間違えたのが直接原因であったため、 ミラー機で本番機搭載前の導入テストをやっていたとしても防げなかったかも知れない。しかし、ミラー機があったならば、不具合の原因調査はもっと早く進み、 午前9時の売買開始に間に合わせることができた可能性は大きい。 2005年11月15日、東証により発表された『システム障害発生に関する報告書』によると、プログラムの修正は、図1、図2どちらのやり方もあるとしている。 ロボットコンテストで、機械の特性をチューニングして手ごわい相手を打ち負かそうというのではないのだから、 大規模基幹システムの本番機にいきなり修正を施すのはあり得ない考え方である。そして、そのやり方を正当化するのに、以前うまく行ったからとしている。 手抜きをやって問題が発生しなかったから、やがてその手抜きが常套化してしまう典型例である。 驚くべきは、その手抜きが当たり前のように報告書に書かれたことである。 当時、東証にはシステム系の有識者が不在、あるいは発言力がなかったことを露呈している。 パニック状態の対処 対処の項、不具合修正の対処に書いたように、不具合発生当日、東証では4度、やみくもにシステムの再立ち上げを試みている。 一度立ち上げに失敗して、その後のリトライで仮にうまく立ち上がったとして、そのまま売買取引にそのシステムを使用しようと考えたのだろうか。 このあたり、大規模システムとパソコンの違いを認識していると思えない。 特に3度目にやろうとしたエラーをSKIPしたリトライは、コンピュータをよく知らずにエクセルで経理計算だけを手掛けているレベルとほとんど変わらない。 実際、後から立ち上げ失敗の原因は取引参加者表のデータが読めないことが原因だったのだから、エラーを SKIP してシステムが立ち上がって売買に突入していたら、 入力された注文の発信者が特定できずに売買データがでたらめになっていたことだろう。 このあたり、富士通開発のシステムが、根本的問題発生時に停止されるようになっていたのは、自動不具合対処がうまくできていて助かったと言えよう。 【知識化】
【後日談】 本事件を追うように、12月8日に発生したみずほ証券誤発注事件で、問題の直接原因が東証システムのバグにあったことが判明したこともあって、 当時の代表取締役社長、代表取締役専務、売買システム担当常務取締役が12月20日に辞任した。 11月10日に自主的減俸処分を受けた当時の取締役会長は、12月20日さらに自主的減俸処分を受け、12月21日から代表取締役社長兼会長となった。 そして、翌2006年2月1日には、CIO(最高情報責任者)を新設し、公募からNTTデータの子会社から招聘した人物を据えた。 しかし、その後も東証システムは次々に不具合を起こし、最近では、2008年3月10日に特定2銘柄について売買ができない状態になった。 東証では、新規システムを 2009年後半立ち上げをめどに開発を進めているという。ちなみにベンダーはやはり富士通。 それが実現するまでは、取引件数の急増に伴い、現システムの処理能力を徐々に高めていくしかないようだ。 参考文献
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright©2002-2024 Association for the Study of Failure |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
