17日の午前8時半ごろ、JR東日本の新幹線運行管理システム「COSMOS」に障害が発生、東北、上越、秋田、山形、長野の各新幹線で運転を見合わせた。
システム障害は午前9時38分にいったん収束、運転再開したが、大幅な遅延や運休によりダイヤは終日混乱した。
18日、JR東日本は、「COSMOS」が処理容量の限界を超えたことが原因だったと発表した。
それによれば、17日午前7時過ぎに新白河駅と福島駅でポイント故障が発生。駅間で列車が止まるのを防ぐため、24本の列車を各駅に停止させるよう指示をCOSMOSに出した。COSMOSはダイヤ変更の計算や、後続列車についても変更が必要な箇所をチェックしたが、変更箇所が600件を超えたため、運行本部のパソコンに表示出来なかった。
本来なら、東京の運行本部のパソコン表示に基づき司令員がデータを変更。その変更指示を反映した形で、COSMOSがダイヤ変更を完了させる。
COSMOSは1分ごとにデータ変更が必要な箇所のチェック処理を起動しているが、変更が必要な箇所が600件を超えるとダイヤを表示できなくなる仕様になっていたという。
この日は短時間に修正指示が集中した結果、この限界を超え、東京の運行本部にあるパソコン22台すべてでダイヤ画面の表示が消えたため、8時23分、JR東日本は全新幹線を停止させた。
運行本部と各駅でデータが整合しているか確認を行い、8時52分にようやくダイヤ変更を完了、9時15分に各駅での列車制御が確実かを確認した上で、試運転。9時38分に全線で運転を再開した。
JR東日本は今後の再発防止策として「データ修正が必要な箇所が600件を超えても、予想ダイヤを表示できるようCOSMOSのプログラムを改修することを検討する」としている。
「検討」・・・えっと、、、言葉もありません。明らかに仕様上の「バグ」だと思うんですが(-.-)
これまでも、JRに限らず大規模なリアルタイムシステムでのシステム障害が何度も発生してますが、だいたいが
１．耐障害対策のための二重化などの部分にバグが残っていた。
２．普段あまり使われない機能部分にバグがあった。
３．端末とセンターとの通信障害（容量オーバーなど）。
４．システム容量計算が甘く、突発的な負荷増加に耐えられなかった。
と言うパターンが多いです。東証でのシステムダウンも４．にあたりますが、今回もこれですね。
2007年のJR東日本など関東一円の自動改札がダウンした事故も、基本的には ３．なのですが、通信障害と云うよりデータ量がオーバーしたためサーバ側は分割して送ったのを、改札機側でうまく読み取れなかったという、２．３．４．を複合したような「バグ」でした。
JRではありませんが、過去にはエラーログを記録するディスク容量が足りなくなってさらにエラーが、と言う冗談みたいな障害もありました（笑
JRと言えば、MARSと言う世界初のリアルタイム予約・発券システムを開発するなどリアルタイムシステムでの経験値も高いはずですし、COSMOSを含めてほとんどのシステムは日立製作所との共同開発ですから、経験不足が原因ではないはずです。
予測が甘すぎた、と言う面もあるでしょうが、何よりも「600件を超えるとダイヤを表示できなくする」仕様って・・・フェイルセーフに対する考え方が根本から間違ってるとしか思えません(-.-)
なお、COSMOS と言うのはJR東日本だけのシステムで、JR東海とJR西日本は COMTRAC と言うシステムを共同で運用してます。これも日立製ですが、歴史的経緯から云っても、COMTRAC を発展強化したのがCOSMOS のようです。
まさか、COMTRAC での「この程度で十分」という取りあえずな仕様を、ずっと引きずって・・・なんてことはないでしょうねぇ？:-)
