首都圏自動改札障害で改めて「日本の鉄道事業者はスゴイ」と感じた

常時開放状態にできる自動改札機が少なくて、混雑してしまった駅はあったそうですが、ほとんどの駅で大きな混乱は無かったようですね。
私は障害時に重要となる「切り分け」というのがどのように行われたか気になっています。障害を起こした自動改札機は特定のメーカーのものだったとの事ですが、各駅で起きた不具合がどのような形式で報告されたか、そしてその報告を見て誰がいつ頃不具合の全容＝特定のメーカーの改札機がおかしい、という事に気付いたのでしょうか。小規模なシステムならともかく、大規模システムとなるとこのあたりが非常に難しいように思います。ぜひとも参考にさせていただきたいところです。

イベントにも通じるのですが、一番怖いのが情報が錯綜するなかで人が滞留してしまうことで、その中でパニックが起きて取り返しのつかない事態を招いた事例・事件がいくつもあります。
良いかどうかは別にして、鉄道については故障や事故など何らかの障害で運行が一時的に停止して駅施設に人が滞留する状況になり、改札への流入制限を実施すると同時に駅舎外に出る人を中途半端に制限せずにとにかく出すケースというのはいくつも想定できますから、障害の原因はどうであれ人が滞留しているという事態に対する対応はシステマチックにできる体制にあるということなんでしょうね。

障害の発生した翌日分からは、ネガデータを配布する前に、テスト環境で問題が発生しないことを確認しているそうです。
問題発生時の影響を考えれば、テストしてからネガデータを配布するのが当然と思いますが、なぜデータのテストをしていなかったのでしょうか？システム設計時の漏れでしょうか。

　yoheiさん、コメントありがとうございます。
　一時対応を迅速に進めるためには初期の障害識別が何より重要になりますが、自動改札機器を統括して管理している中央センターが、想定事例ケースに従って代替オペレーションをうまく誘導できた賜物なのでしょう。
　一般企業では、早朝6時前という段階では意思決定者が適切な判断を下すことは難しいケースもありますが、さすがに鉄道は中央センターも朝から万全の体制だったのだと思います。

　いわながさん、コメントありがとうございます。
　なるほど、人を滞留させないことも重要なポイントですね。鉄道のように1秒単位で影響範囲が激増していくサービスでは、サービス利用者の滞留を招くことが最も避けねばならないことなのでしょうね。参考になります。

　Canさん、コメントありがとうございます。
　おそらくデータの長さによる異常終了もテスト項目に入っていたのではないかと思いますが、そのようなテストは大抵正常値と異常値と閾値に関するものになるため、今回のような異常終了はつゆほども考えなかったのでしょう。
　今回、障害が発生してしまったことについては大変残念だったと思いますが、むしろ私はシステム障害自体を問題と考えるのではなく、せっかく別の会社が製造した3種類の自動改札があるのだから、ひとつの駅に複数の製造元の自動改札を置くべきであった点について反省してもらいたいと思います。

　Canさん、コメントありがとうございます。
　おそらくデータの長さによる異常終了もテスト項目に入っていたのではないかと思いますが、そのようなテストは大抵正常値と異常値と閾値に関するものになるため、今回のような異常終了はつゆほども考えなかったのでしょう。
　今回、障害が発生してしまったことについては大変残念だったと思いますが、むしろ私はシステム障害自体を問題と考えるのではなく、せっかく別の会社が製造した3種類の自動改札があるのだから、ひとつの駅に複数の製造元の自動改札を置くべきであった点について反省してもらいたいと思います。

中さん、お答えいただいてありがとうございます。
私がテストという表現をしたため、誤解させてしまったようです。
言いたかったのは、「テスト用の配信サーバーと改札機を用意して、ネガデータを改札機に配信してテスト稼動させれば、問題がわかったのではないか？」ということです。
配信サーバ・改札機とも予備機があるでしょうから、これをテスト用に使うことはできるでしょう。