図1●東証のシステム障害は、手順書の記載ミスによるロード・モジュールの登録ミスが原因で発生した
図1●東証のシステム障害は、手順書の記載ミスによるロード・モジュールの登録ミスが原因で発生した
[画像のクリックで拡大表示]
図2●東証とシステム関連ベンダーの関係<BR>東証は2002年2月、東証コンピュータシステムの株式65%を譲渡。これを2004年9月に、富士ソフトABCが取得している
図2●東証とシステム関連ベンダーの関係<BR>東証は2002年2月、東証コンピュータシステムの株式65%を譲渡。これを2004年9月に、富士ソフトABCが取得している
[画像のクリックで拡大表示]

東京証券取引所で11月1日に発生したシステムダウンの根本的な原因は、運用体制の不備にあった。本来はシステムの本番機に触れない開発ベンダーである富士通が、東証が許可したとはいえ本番機上でバグを修整するなど、「あってはならない」運用がまかり通っていた。

 東証におけるシステム障害の直接原因は、富士通が作成した手順書の記載ミスによるロード・モジュールの登録漏れ、つまり人的ミスである。だが、問題の本質は「手順書の記載ミス」で片付けられるものではなかった。本誌がトラブルに至る経緯を洗い出した結果、基幹システム運用の基本ルールを守っておらず、人的ミスが起きやすい状態で運用していたことが明らかになった(図1[拡大表示])。

 東証は株取引の増加に対応するため、10月11日にシステムの容量を拡大する予定だった。10月8日からの3連休に、本番機を使ったシステム全体の動作確認テストを計画。開発機で更新済みのロード・モジュールを、テスト前に本番機の移行用ライブラリに登録していた。この作業は、東証のシステム運用子会社である東証コンピュータシステム(TCS)の担当である(図2[拡大表示])。

 移行用ライブラリとは、開発機で修整・テストを終えたロード・モジュールを、切り替え直後の2~3日間だけ格納する領域。正本ライブラリに影響を与えずに、更新したロード・モジュールを本番機で動かすためのものだ。移行用ライブラリにあるロード・モジュールは、正本ライブラリのものよりも優先して動く設定になっている。

開発ベンダーが本番機でバグ修整

 東証は10月8日から動作確認テストを開始。そこで、先に登録したロード・モジュールとは別のロード・モジュールにバグが見つかった。東証の要請を受けて調べた富士通が、バグの原因を究明。本番機でCOBOLプログラムの修正とコンパイルを直接実施して数本のロード・モジュールを更新した。富士通はそのまま、更新したロード・モジュールを移行用ライブラリに登録した。この作業が決まった手順から逸脱していたのだ。

 本来、システムを修整する際は、開発ベンダーの富士通が開発機でプログラムの修正やロード・モジュールの更新、テストをこなしてから、運用ベンダーのTCSに引き継ぐ。運用ベンダーが手順書に従って本番機のライブラリにロード・モジュールを登録するのが、ミッション・クリティカルなシステムの運用では常識だ。だがこの時は、移行時のバグ修整が急を要するため、東証が本番機での作業を認めた。

手順書に漏れ、エイリアス設定抜ける

 TCSは移行用ライブラリでの動作確認後、13日にバグ対応で更新した数本のロード・モジュールを、正本ライブラリに登録した。この登録作業は、富士通が作成した手順書に従い、TCSが担当した。この際、手順書にミスがあり、ロード・モジュールの「エイリアス再設定」という手順が抜け落ちた。メインフレームではシステムを安全に切り替える目的で、同一名称で二つのロード・モジュールをライブラリに共存させることができるようになっている。二つのうち、どちらを起動するかを指定するのがエイリアスの役割だ。

 バグ対応で更新したロード・モジュールを正本ライブラリに登録した時点で、正本ライブラリには新旧のロード・モジュールが格納された。ここで、エイリアスの設定を忘れたため、バグ対応が済んでいない、古いロード・モジュールを呼び出す設定が残った。

 10月31日までは、古いロード・モジュールが呼び出されており、ミスは表面化しなかった。ところが10月31日に実施したディスクの圧縮処理により、古いロード・モジュールとエイリアスのつながりが切れてしまう。新ロード・モジュールは、相変わらず有効にならないまま。新旧どちらのロード・モジュールも呼び出せなくなり、システムが起動しなくなった。

「緊急時の作業手順書はない」

 バグを発見した際、富士通が開発機で本来の手続きを踏み、テスト作業を経た後、TCSが決められた手順で移行ライブラリに登録していれば、エイリアス設定手順の漏れに気づき、障害を未然に防げた可能性が高い。しかし、富士通が本番機で作業してしまったため、気づく機会を失ったのである。

 東証の佐藤博 売買システム部長は「緊急の場合には開発ベンダーが本番機で直接修整するのはやむを得ない」との判断で、「今後も緊急度に応じて同様の手順を採ることもあり得る」と説明する。富士通によると、東証のシステムで本番機で修整するのはごくまれなケースだが、これまでも1、2件あったという。高い技術力を持つ開発ベンダーを運用まで踏み込ませるかどうかは、ユーザーの判断ではある。しかし、「緊急時の作業に関する手順書はない」(佐藤部長)という現状は問題だと言わざるを得ない。大手ITベンダーの運用担当者は「普通は緊急対応の手順も明文化してある。緊急事態のたびに手順書を作っていたら、人的ミスのリスクが高まるだけ」と指摘する。

安定稼働へシステム投資を倍増

 東証は10日、鶴島琢夫社長が月額報酬の50%を6カ月減額するなど役員の処分を決定。15日に金融庁へ報告するとともに再発防止策を発表した。(1)運用手順や役割分担の見直し、(2)プログラム移行時のミス防止を狙ったシステム・チェック機能の強化、(3)システム立ち上げの2時間前倒し、(4)臨時のシステム外部監査の実施——が大きな柱である。ITガバナンス全般の強化を狙い、外部有識者による「システム諮問委員会」の設置や、外部専門家によるシステム運用手順の再検証、情報セキュリティ・マネジメント・システム(ISMS)の取得、バックアップ・サイトの構築、システムにかかわる人員・体制の見直しにも取り組む。

 中期経営計画で決めていたシステム投資も上積みする。2007年度までの3年で予定していた投資額は234億円だったが、これをほぼ倍増する計画だ。システム投資に必要な資金調達も含め、2006年度以降に予定している東証自身の上場は計画通り進める。

出典:15ページより 日経コンピュータ11月28日号
記事は執筆時の情報に基づいており、現在では異なる場合があります。