全日空の予約・発券手続きが出来なくなる
全日空の予約・発券手続きが出来なくなる
【2016年3月22日現在、ANAの国内線システムに障害が発生していますが、過去にも同様の事例がありました】


【2007年5月27日(日)】
全日空の予約・発券システムでトラブルが発生。

130便が欠航、306便に1時間以上の遅れが出て、約7万9300人に影響を与えました。

どんなシステムトラブルだったのか、どう対策を考えればよいのか見ていきましょう。

背景には汎用機からオープン系への移行があった

全日空には国内線の予約-発券-登場手続きを行うシステム「able-D」があります。各空港のカウンターや支店、旅行会社に約1万台のabel端末が設置され、1日最大650万トランザクション処理を行っています。

「able-D」は1988年に稼働し、既に18年が経過しています。長年使い続けた汎用機システムですので、改修につぐ改修でシステムはつぎはぎだらけになっています。システム変更は容易ではありません。

また競争の激しい航空業界ですので新しいサービスを追加し他社と差別化をしなければなりません。そこで全日空では汎用機からオープンシステムに移行することを決定しました。

選んだのは米ユニシスが開発したエアライン・パッケージソフトウェア「AirCore(Airline Core Systems Solutions)」です。「AirCore」はJavaで開発されています。

メガキャリアでオープン系予約システムを構築するのは全日空が世界初になります。新しい「able-D」は2007年から順次稼働し、2012年までに全面稼働の予定です。長期に渡るプロジェクトとなり全日空では「新旅客サービスプロジェクト」と呼んでいます。

ハード面の移行は既に始まっており、abel端末のリプレースが実施され、これから汎用機からサーバーへの移行、自動チェックイン機、自動発券機等の刷新が行われます。今回のトラブルはこの流れの中で発生したようです。

全日空の予約・発券手続きが出来なくなる

まだ詳しい原因は分かっていませんが、時系列でシステムトラブルをおってみましょう。
5月27日 トラブルでカウンターは大混乱に
5月27日 トラブルでカウンターは大混乱に

【5月上旬~5月24日(木)】 「abel-D」のホスト接続に使っているシステムで6台のサーバーうち3台を2週間かけて更新

【5月26日(土)】 ネットワークの調子がおかしい兆候が出始める

【5月27日(日)システムトラブル当日】
【未明】 処理能力が低下し、修復作業を行うが解決せず

【9:30】 処理能力が大幅低下し、予約や発券の手続きが滞り始める。羽田、大阪空港の発着便を中心に欠航、遅延があいつぐ。ネットワークを本番系からバックアップ系に切替

【12:30】 ホスト接続システムのサーバー3台を以前のサーバーとソフトウェアに戻し、汎用機に滞留していたデータを削除

【14:30】 ネットワークをバックアップ系から本番系に切替 

【15:30】 全面復旧

【18:00】 運行を再開

ホスト接続システムは多重化対策を行っており、6台のサーバーの何台かがダウンしても残りのサーバーで対応できる設計になっていました。ところが新たに更新した3台のサーバーが誤った判断をしながら汎用機にデータを送り続けました。

3台のサーバーが稼動を続けたことで多重化対策がいかされませんでした。また3台のサーバーから汎用機に出された情報がたまり過ぎたことが原因で処理速度が低下、トラブルになったようです。

誤った判断という報道ですのでソフトウェアのバグか、ネットワーク機器などの設定ミスの可能性が高そうです。

おそらくサーバーを更新した時から不具合は発生しており汎用機にデータがたまり始め、週末に向けて利用が増えたこともあり5月27日(日)未明に限界を超えてしまったのでしょう。

では全日空の対応はどうだったんでしょうか?