年末に起こったJR東日本のシステムトラブルの原因と対策を考えてみた

　先日JR東日本のシステムトラブルでの利用者への情報提供が甘いんじゃないかと書きましたが、そのシステムトラブルについて原因と対策についても考えてみました。


■情報を整理する
　報道された情報を次のようにまとめられます。

［速報］JR東の新幹線がシステム障害で始発から全面停止、復旧は午前8時に延期：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20081229/322115/

［続報］JR東の新幹線がシステム障害から復旧、前日データの反映に問題か：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20081229/322116/

JR東が新幹線システム障害の原因発表、前日のダイヤ乱れで修正が限界超え：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20090105/322199/

　リンク先の情報をまとめるとこのような感じでしょうか。

図 JR東日本 COSMOSのシステムフローと今回の事象でのフロー（予想）

通常運用時（画像上部1）は、
　1-1.運行データを5時までに何らかの方法で準備。
　1-2.5時を過ぎた時点で新幹線総合システムCOSMOSが出力された運行データを取得。
　1-3.運行データを処理し6時以降の運行に向けて備える。
という流れで行われている。

今回の事象発生例（画像下部2）では、
　2-1.前日の車両故障と強風・雪害の影響で全運行が終了したのが29日の1時33分にまで及んだ。
　　　　そのため翌日の389本の列車の運行データを最適化するため変更、結果5時45分までかかった。
　　　　5時を越えて切り替えたため、運行データが翌営業日のものになってしまった。
　2-2.COSMOSが運行データを取得しようとするも、データが存在しないため取得できない。
　2-3.運行データが無いため運行の割り当てがされずトラブルが発生。


■問題があったのはシステム運用
上述の情報から明らかな運用ミスのように思います。その理由を挙げる前に、上に書いた流れでのポイントを整理しておきましょう。
ポイントはこの2点に絞られます。
　・運行データの作成に時間がかかりすぎた
　・5時以降に作成されたデータを読み込むことが出来なかった

(1)運行データの作成所要時間について

前日28日の長野新幹線の車両故障や山形・秋田新幹線の強風や雪害。その影響ですべての列車の運行が終了したのが29日の午前1時33分だった。その後 29日の臨時を含めて389本の列車が運行できるよう、車両を留置する場所などのデータを変更。作業は午前5時45分まで長引いた。

JR東が新幹線システム障害の原因発表、前日のダイヤ乱れで修正が限界超え：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20090105/322199/

　結果的に4時間12分処理に時間がかかったことになります。単純計算で1本分計算するのにかかった時間が1分半でしょうか。実際にはマッチングや最適化等の処理が入るでしょうからもう少し短いと思いますが、以外と短くてびっくりです。
　このような計算系の処理システムだと、普通は「●●本の計算で●●分かる」ような想定所要時間を挙げておくのが普通でしょう。
　今回のトラブルでは、前日のうちから389本を計算する想定になっていたようですが、その想定所要時間と計算にかけれる時間（午前5時までの時間）はちゃんと天秤にかけて判断したのでしょうか？また想定所要時間がわかっていながらなぜ最終運行車両が戻るのを待ってから処理を始めたのでしょうか？前以て処理を開始できなかったのでしょうか？いろいろと疑問が涌いてきます。

(2)5時以降のデータの読込について
　JR東日本が運行している新幹線で、一番早い時間に運行するのが東北新幹線盛岡行です。そしてこの車両の運行開始が6時4分なのです。この5時から6時の1時間に、運行データの読込処理と何らかのシステム障害があった場合のリスク対応として設けているのは当然想定できます。
　さて、今回の場合は、そのシステム障害だったんじゃないのかという話ですが、想定される仕様である「午前5時までに運行データを作成する」というベースルールにすら則っていないため想定外だったのではないでしょうか。
　ましてや今回の場合「午前5時まで」というリミットについて、開発者側から運用側に当然伝わっている内容でしょうし、そのルールを守れなかった運用に問題があるのではないでしょうか？


■考え得る対応策
もう既にJR東日本が対応策を発表しているようですが。
12月29日に発生した新幹線輸送障害について[PDF]
残念ながら全く対策になってない気がします。今までもわかっていたであろう「5時までに日付切替作業を行う」ことを徹底するって言っているだけで、対策でもなんでもないです。そこで、上述の原因から考えられる対策を検討します。

今回の事象に対しての対応として想定されるアプローチは2つ、
　・運行データ作成にかかる時間を短縮する
　・5時以降に作成されたデータへの対応

(1)運行データ作成に係る所要時間短縮に関して
・マンパワーで解決
　　処理が終わらなかったのは処理能力が足らなかったからだ　→　ならば処理能力を高くすればいい
　　今回の運行データ作成がシステムによるものではなく手入力によるものだった場合の想定。
　　まさかそんなはずは無いと思いますが。

・運行データ予測調整システムの導入
　　各車両の翌日の始発駅が決定的になった車輌から次の日の運行データに当て嵌めていく方法。
　　全車両の運行が終了していなくても、確定している車両がある程度決まっていれば翌日の運行データ
　　作成は始められるはず。
　　少なくとも今回のように遅れることはなくなるのではないでしょうか？

(2)5時以降に作成されたデータへの対応に関して
・そもそも日付付加に関するルールを改変する
　　これについては達成するにあたって想定されるコストやリスクが大きすぎるため良くない対策でしょう。

・イレギュラーに関しては運用でカバー
　　これも一つの手です。
　　基本的にシステムでカバーできない点は運用でカバーするしかないでしょう。
　　今回のように5時45分に運用データが作成されて始発まで19分しかない状況だと厳しい気もします。


■所感
　少々偉そうなことを書きましたが、対策とはあくまで状況に対応するための方法・手段です。

たい‐さく【対策】
１ 相手の態度や事件の状況に対応するための方法・手段。「人手不足の―を立てる」「―を練る」「税金―」
２ 律令制で、官吏登用試験の一。文章(もんじょう)博士が問題を出して文章得業生(とくごうしょう)に答えさせるもの。また、その答案。

Yahoo!辞書 - たい‐さく【対策】

少なくとも今回提示した対策レベルのものを対策として示してはいけないのではないでしょうか？