以下は、朝日新聞と読売新聞のWebからの引用です。
全日空障害、ダウン対策不発 サーバー切り替わらず
2007年05月28日15時56分
27日の全日空の国内線予約・発券システム障害は、システムの多重化策がとられていながら起きていたことが、わかった。システムの根幹部分であるホストコンピューター周辺機器の更新時の設定に問題があった可能性もあるとみられ、全日空が原因を調べている。
予約・発券システムはホストコンピューターと、全国の空港の窓口や旅行会社の端末が専用のネットワークを通じて結ばれている。
全日空によると、ホストコンピューターとやりとりされる情報は、ホストコンピューターの手前にある6台のサーバーでどの経路を通って処理するかを整理している。6台のうち何台かがダウンしても、残りで同じ対応ができる設計だった。
ところが今回は、今月24日までに順次更新されたサーバー3台が、ホスト側から出た情報をネットワーク側に送り出しても反応しないという誤った判断を下し、ホスト側に返していた可能性があるという。しかも3台が対応を続けたため、残りの3台に切り替わらなかった恐れがあると全日空はみている。
この結果、ホストコンピューターには発信できない情報が大量にたまり、処理速度が大幅に低下。27日の修復作業で3台を更新前のサーバーに戻し、たまっていたデータをはき出すと、処理能力は回復した。
全日空とメーカーによる原因調査には時間がかかる見込みで、当面は予約・発券システムは元のサーバーで運用する。
◇
全日空のシステム障害から一夜明けた28日、同社は航空機の機材繰りの関係などから鹿児島発大阪(伊丹)行きの初便が欠航した。午後にかけて9便が遅れる予定。システム自体は安定して動いているという。
全日空の国内便のコンピューターシステムに27日未明、障害が発生、各空港で搭乗手続きなどが出来なくなり、羽田空港発着便を中心に全国で欠航や遅れが相次いだ。
システムは午後3時半に復旧したが、ダイヤの乱れは終日続き、計130便が欠航。到着が1時間以上遅れた便も306便に上り、6万9300人に影響が出た。
障害が起きたのは、予約と搭乗手続き、手荷物預かりを管理しているシステム。各空港では、27日の始発前から、窓口などにある端末の反応が極端に鈍くなった。全日空では、手作業で搭乗手続きなどを受け付けるとともに、午後1時半から午後6時までの羽田発便を全便欠航させ、間引き運航で対応した。
最大の遅れは鹿児島―羽田便の4時間45分。全日空のシステムを利用しているスカイネットアジア航空、北海道国際航空(エア・ドゥ)、アイベックスエアラインズにも、多数の便で遅れが出た。全日空では28日も、午前8時発の鹿児島―大阪(伊丹)便が欠航するほか、午前7時台の岡山―羽田、高松―羽田便がともに2時間35分遅れで運航するなど計9便に遅れが出る見通し。
(朝日新聞)
-----------------------------------------------------------------
全日空では、今月15日から24日にかけ、羽田空港近くにあるホストコンピューターと各空港の端末とを結ぶ接続システムの更新作業を実施していた。この日のトラブルで、システムを更新前の状態に戻したところ復旧したといい、詳しい原因を調べている。
全日空では、2003年3月にも150便が欠航する大規模なコンピュータートラブルが起きている。
��2007年5月28日1時20分 読売新聞)
他の新聞、報道メディアの報道によると、ハードウェア/ソフトウェアの交換をしたところ、障害が発生したようです。事前のシステムテストは十分な時間をかけて実施したとのことですが、結果としてこのような障害が発生したのですから、抜け洩れがあった、十分でなかったということになります。
変更管理上の問題
①システムテスト(受入テスト)のシナリオ、精度が適切であったか
②テスト環境は適切であったか
③切替の手順は適切であったか
など、考えられますね。
問題管理上の課題
①原因の追求体制は適切か
②障害対応が適切であったか
③過去の障害対応の教訓は生かされたか
etc
システム管理上、そして再発防止のためにも、当該企業や関係ベンダーなどから、原因の発表など、機体したいものです。