全日空のシステム障害

5月27日に全日空のシステムの大規模な障害が発生、予約・発券システムがダウン、定期便の運行が大混乱でした。

以下は、朝日新聞と読売新聞のWebからの引用です。

全日空障害、ダウン対策不発　サーバー切り替わらず
2007年05月28日15時56分
　２７日の全日空の国内線予約・発券システム障害は、システムの多重化策がとられていながら起きていたことが、わかった。システムの根幹部分であるホストコンピューター周辺機器の更新時の設定に問題があった可能性もあるとみられ、全日空が原因を調べている。
　予約・発券システムはホストコンピューターと、全国の空港の窓口や旅行会社の端末が専用のネットワークを通じて結ばれている。
　全日空によると、ホストコンピューターとやりとりされる情報は、ホストコンピューターの手前にある６台のサーバーでどの経路を通って処理するかを整理している。６台のうち何台かがダウンしても、残りで同じ対応ができる設計だった。
　ところが今回は、今月２４日までに順次更新されたサーバー３台が、ホスト側から出た情報をネットワーク側に送り出しても反応しないという誤った判断を下し、ホスト側に返していた可能性があるという。しかも３台が対応を続けたため、残りの３台に切り替わらなかった恐れがあると全日空はみている。
　この結果、ホストコンピューターには発信できない情報が大量にたまり、処理速度が大幅に低下。２７日の修復作業で３台を更新前のサーバーに戻し、たまっていたデータをはき出すと、処理能力は回復した。
　全日空とメーカーによる原因調査には時間がかかる見込みで、当面は予約・発券システムは元のサーバーで運用する。
　　　　　◇
　全日空のシステム障害から一夜明けた２８日、同社は航空機の機材繰りの関係などから鹿児島発大阪（伊丹）行きの初便が欠航した。午後にかけて９便が遅れる予定。システム自体は安定して動いているという。
全日空の国内便のコンピューターシステムに２７日未明、障害が発生、各空港で搭乗手続きなどが出来なくなり、羽田空港発着便を中心に全国で欠航や遅れが相次いだ。
　システムは午後３時半に復旧したが、ダイヤの乱れは終日続き、計１３０便が欠航。到着が１時間以上遅れた便も３０６便に上り、６万９３００人に影響が出た。
　障害が起きたのは、予約と搭乗手続き、手荷物預かりを管理しているシステム。各空港では、２７日の始発前から、窓口などにある端末の反応が極端に鈍くなった。全日空では、手作業で搭乗手続きなどを受け付けるとともに、午後１時半から午後６時までの羽田発便を全便欠航させ、間引き運航で対応した。
　最大の遅れは鹿児島―羽田便の４時間４５分。全日空のシステムを利用しているスカイネットアジア航空、北海道国際航空（エア・ドゥ）、アイベックスエアラインズにも、多数の便で遅れが出た。全日空では２８日も、午前８時発の鹿児島―大阪（伊丹）便が欠航するほか、午前７時台の岡山―羽田、高松―羽田便がともに２時間３５分遅れで運航するなど計９便に遅れが出る見通し。
(朝日新聞)
-----------------------------------------------------------------
　全日空では、今月１５日から２４日にかけ、羽田空港近くにあるホストコンピューターと各空港の端末とを結ぶ接続システムの更新作業を実施していた。この日のトラブルで、システムを更新前の状態に戻したところ復旧したといい、詳しい原因を調べている。
　全日空では、２００３年３月にも１５０便が欠航する大規模なコンピュータートラブルが起きている。
��2007年5月28日1時20分 読売新聞）

他の新聞、報道メディアの報道によると、ハードウェア/ソフトウェアの交換をしたところ、障害が発生したようです。事前のシステムテストは十分な時間をかけて実施したとのことですが、結果としてこのような障害が発生したのですから、抜け洩れがあった、十分でなかったということになります。
変更管理上の問題
①システムテスト(受入テスト)のシナリオ、精度が適切であったか
②テスト環境は適切であったか
③切替の手順は適切であったか
など、考えられますね。
問題管理上の課題
①原因の追求体制は適切か
②障害対応が適切であったか
③過去の障害対応の教訓は生かされたか
etc
システム管理上、そして再発防止のためにも、当該企業や関係ベンダーなどから、原因の発表など、機体したいものです。