【 Ads by Google 】
新しい記事を書く事で広告が消せます。
【 東証システムトラブルの原因 】
東証システム障害の真相、富士通の指示ミスでプログラムが呼び出し不能に
東証システムトラブルの原因ですが、詳しい情報が出てきました。
ちょっと難しいですが、簡単に引用含めまとめてみます。(11/7時点の情報)
・主因は売買システムの開発・保守を担当する富士通が10月13日に作成した、作業指示書に記載漏れがあったこと
・10月8日から10日の3連休に実施したシステム増強作業自体には問題がなく、その時点で取引所に参加している証券会社と、その端末のコードを登録した「参加者データ・ファイル」を読み込むプログラム中のバグ(5月に混入したバグ)を発見した。
・このバグを修正したプログラムを売買システムに再登録するため、10/13「作業指示書」を富士通が作成し、運用担当ベンダーである東証コンピュータシステム(TCS)に送付した。
・ところがこの作業指示書には、サブモジュール間の呼び出し関係を指定し直す手順が抜けていた。このため、プログラムの中の古い呼び出し関係が、書き換えられることなく残った。(13日以降、システムは古い呼び出し関係のまま動き続けていた。)
・10/31に「コンデンス処理」(ファイルの読み書きを繰り返して使用しなくなったディスク領域を解放して再利用できるようにするための処理)があった。これで、呼び出し関係を指定しなおしていなかったために、古い呼び出し関係も切断された。
・翌11月1日朝、参加者データ・ファイルを読み込むプログラムが起動したものの、正しいサブモジュールを呼び出せず、読み込みに失敗したため、売買システムは起動しなかった。
それにしても、旧システムで動いていた10月13日からの半月間、誰もバグが残った状態だったことに気がつかなかったんでしょうか。
いろいろな要因が積み重なっていますが、バグがもっと大きな障害を呼んだという意味で、デグレードといえます。
そうすると、富士通側だけでなく、東証側のチェック体制も問題ありといえそうです。
記者会見した東証の天野富夫常務は、作業指示書自体の点検が不十分でなかったかに関して、「そこまで想定していなかった。今後はあらゆることに想定を広げ、事前にテストしたい」と述べた。
仕事を出す側がこんな認識では、また繰り返されると思います。
今システムの開発現場は、多くの場合外注頼みです。このシステムを請け負った富士通ですが、開発を実際にしたのは別の下請けじゃなかろうかと推測します。
東証→富士通→別の下請け
指示書を作成したのは下請けなのか富士通なのかはわかりませんが、仕事を依頼する側は依頼した仕事がちゃんとできているかチェックをするはずです。
それが「専門性が高くてチェックできない」のでは、東証はこのシステムに責任を負えません。富士通がやればいいことになってしまいます。
自分の見聞きする話でも、外注頼みのシステム開発は、一部のスーパーマンに支えられてどうにかなっているというのは常々感じています。
仕事を頼む側も、仕事を頼まれる方と同じだけのスキルがないと、依頼してはいけないのではないでしょうか。
いろいろと示唆に富む事件でした。
東証システムトラブルの原因ですが、詳しい情報が出てきました。
ちょっと難しいですが、簡単に引用含めまとめてみます。(11/7時点の情報)
・主因は売買システムの開発・保守を担当する富士通が10月13日に作成した、作業指示書に記載漏れがあったこと
・10月8日から10日の3連休に実施したシステム増強作業自体には問題がなく、その時点で取引所に参加している証券会社と、その端末のコードを登録した「参加者データ・ファイル」を読み込むプログラム中のバグ(5月に混入したバグ)を発見した。
・このバグを修正したプログラムを売買システムに再登録するため、10/13「作業指示書」を富士通が作成し、運用担当ベンダーである東証コンピュータシステム(TCS)に送付した。
・ところがこの作業指示書には、サブモジュール間の呼び出し関係を指定し直す手順が抜けていた。このため、プログラムの中の古い呼び出し関係が、書き換えられることなく残った。(13日以降、システムは古い呼び出し関係のまま動き続けていた。)
・10/31に「コンデンス処理」(ファイルの読み書きを繰り返して使用しなくなったディスク領域を解放して再利用できるようにするための処理)があった。これで、呼び出し関係を指定しなおしていなかったために、古い呼び出し関係も切断された。
・翌11月1日朝、参加者データ・ファイルを読み込むプログラムが起動したものの、正しいサブモジュールを呼び出せず、読み込みに失敗したため、売買システムは起動しなかった。
それにしても、旧システムで動いていた10月13日からの半月間、誰もバグが残った状態だったことに気がつかなかったんでしょうか。
いろいろな要因が積み重なっていますが、バグがもっと大きな障害を呼んだという意味で、デグレードといえます。
そうすると、富士通側だけでなく、東証側のチェック体制も問題ありといえそうです。
記者会見した東証の天野富夫常務は、作業指示書自体の点検が不十分でなかったかに関して、「そこまで想定していなかった。今後はあらゆることに想定を広げ、事前にテストしたい」と述べた。
仕事を出す側がこんな認識では、また繰り返されると思います。
今システムの開発現場は、多くの場合外注頼みです。このシステムを請け負った富士通ですが、開発を実際にしたのは別の下請けじゃなかろうかと推測します。
東証→富士通→別の下請け
指示書を作成したのは下請けなのか富士通なのかはわかりませんが、仕事を依頼する側は依頼した仕事がちゃんとできているかチェックをするはずです。
それが「専門性が高くてチェックできない」のでは、東証はこのシステムに責任を負えません。富士通がやればいいことになってしまいます。
自分の見聞きする話でも、外注頼みのシステム開発は、一部のスーパーマンに支えられてどうにかなっているというのは常々感じています。
仕事を頼む側も、仕事を頼まれる方と同じだけのスキルがないと、依頼してはいけないのではないでしょうか。
いろいろと示唆に富む事件でした。
- | HOME |



