企業のIT活用/システム導入事例

全日空システム障害の原因は伝達ミス

【2016年3月22日現在、ANAの国内線システムに障害が発生していますが、過去にも同様の事例がありました】2008年9月14日、連休中日に全日空の63便が欠航、358便に遅れが出るシステム障害が発生しました。原因は伝達ミス。再発防止に向けてどうすればよいのかみていきましょう。

水谷 哲也

執筆者:水谷 哲也

企業のIT活用ガイド

全日空のシステム障害
全日空のシステム障害
【2016年3月22日現在、ANAの国内線システムに障害が発生していますが、過去にも同様の事例がありました】

全日空から2008年9月14日(日)に発生したシステム障害の原因が発表されました。

原因は端末認証管理サーバーに設定されていた暗号化認証の有効期限切れ。発端は2005年9月に端末認証管理サーバーを導入した時に設定した有効期限でした。

 

発端は2005年9月に設定した有効期限

・2005年9月 端末認証管理サーバーを導入(暗号化認証機能は使わず)
暗号化認証機能の有効期限を初期設定の3年後のままに
「2008年9月14日午前1時44分」で設定される

・2007年9月 「スキップサービス」(予約客がカウンターに立ち寄らず、搭乗口でカードをかざすだけで搭乗手続きが完了)導入にあわせ、更新搭乗者の個人情報保護のため端末で暗号化認証機能を使用し始める

【システム障害発生日 2008年9月14日(日)】
・午前1時44分 暗号化認証機能の有効期限が切れる
全国51空港にある全日空と提携4社の1,556台の端末を起動しようとすると暗号化処理の認証がクリアできずエラーで起動できない状態になる

・午前3時45分 北九州空港で端末が起動しないと報告がある

・午前3時50分 センター側と北九州空港のネットワークに異常がないか確認

・午前4時28分 現地の保守要員に修理を依頼

・午前5時31分 羽田空港からも同様の報告があり、全国の空港で障害が発生していることが判明

全日空では端末と端末管理を行っているサーバーとの間で行っている日付処理に問題があると類推し、日付を確認する機能を停止する暫定手順を考える。

・午前11時12分 暫定手順を実施
全日空のシステム障害 7万人に影響
全日空のシステム障害 7万人に影響

各空港の端末が順次回復しますが、羽田空港発の路線をはじめ63便が欠航、358便に遅れが出ました。
欠航などで航空機のやりくりがつかずに終日、空港は大混乱することに。社員が手作業で手続きをとるなどして対応しましたが連休ということもあり、全日空のカウンター付近は搭乗手続きを待つ人たちであふれ返ります。7万人に影響を与えました。

・2008年9月16日 国土交通省が全日空に早急な原因究明と再発防止を求めるよう指導

・2008年9月18日 全日空から国土交通省に原因と再発防止策を報告

2時間の初動ミス

では今回のシステム障害は防げたのでしょうか。おしかったのが初動です。

北九州空港で端末が起動しないと連絡があった時、まず東京のセンターと北九州空港との間のネットワークに異常がないか確認しました。ここまでは順当でした。異常がなかったため、北九州空港の端末に原因があると判断し、現地の保守要員に修理を依頼してしまいます。

この時に、他の空港に連絡し、端末を立ち上げて同様の事象が発生しないかチェックさえすれば局所的トラブルなのか全体的トラブルなのか判断できたことになります。

真の原因を追究する貴重な2時間をかせげたことになります。結局、羽田空港から報告があるまでトラブルの大きさを把握できませんでした。

根本原因は伝達ミス

担当者の伝達ミスが根本原因
担当者の伝達ミスが根本原因
端末認証管理サーバーを導入した時に、初期設定の3年後のまま有効期限を放置しましたが、当初は暗号化認証機能を使わないとのことでしたので、これは仕方がありません。

問題は暗号化認証機能を使うと判断した2007年9月の対応です。全日空によると端末認証管理サーバーの担当者と端末設計の担当者は2007年9月時点で有効期限が1年しかないと認識していました。両者の打ち合わせ書類に、この有効期限の話題が出ているようです。

問題はここからで、端末設計の担当者は端末認証管理サーバーの担当者が更新するだろうと思い込んでいました。ちゃんと伝わっていなかったのですね。

「伝えた」つもり、「確認した」つもりになっていないか要チェックです。伝達という言葉がありますが、「伝える」ことと「達する」こととは違います。仕事の報告をするのに、上司の机の上に報告書を置いて「伝えた」と思っていませんか。

部下に仕事の指示を出す時も同じです。メールで送るだけでなく、面と向かって伝わったかどうか質問し確認することが必要です。これで「達した」ことになります。

今回のケースでは、お互いに認識はしていましたが、確認はせず、結果として伝達できませんでした。全日空からも「きわめて初歩的なミス」と発表されています。

再発を防止するには

全日空から再発防止とシステム開発のプロセス改善の対策が発表されています。
・他に、端末管理システムの暗号化認証機能を利用したシステムが無いことを確認(実施済み)
・端末管理システムの暗号化認証機能の有効期限延長(実施済み)
・システムにおける機能の有効期限について点検
・システム開発プロセスにおける標準化の推進
・社外第三者によるシステム開発プロセスの審査体制を確立

今回のシステム障害はシステムのバグではありませんでした。有効期限切れのチェックさえ行っていれば防げたシステム障害でした。ただウイルス対策ソフトのように期限切れが近づくと警告してくれるような代物ではないので、しっかり管理しないと、なかなか気がつきません。

対策に「システム開発プロセスにおける標準化の推進」がありますが、「機能の有効期限切れの確認」が新しくチェックシートに加わっているはずです。製造業だけでなくシステム開発でも開発プロセスの「見える化」を行い、品質を工程で作りこんでいく仕組みが必要です。

全日空では2007年5月27日にシステム障害を起こしました。この時は130便が欠航、306便に1時間以上の遅れが出て、約7万9300人に影響を与えました。
→ 全日空 予約・発券システムでトラブル発生

この時の再発防止策で、今回と同じ「システム開発プロセスにおける標準化の推進」があり取り組んでいましたが、2007年9月の「スキップサービス」導入ではいかされませんでした。

欠航などによるお客さんへの費用負担は約2億円になり、有効期限切れという伝達ミスが高くついてしまいました。



【編集部おすすめの購入サイト】
楽天市場で企業経営関連の書籍を見るAmazon で企業経営関連の書籍を見る
※記事内容は執筆時点のものです。最新の内容をご確認ください。

あわせて読みたい

あなたにオススメ

    表示について

    カテゴリー一覧

    All Aboutサービス・メディア

    All About公式SNS
    日々の生活や仕事を楽しむための情報を毎日お届けします。
    公式SNS一覧
    © All About, Inc. All rights reserved. 掲載の記事・写真・イラストなど、すべてのコンテンツの無断複写・転載・公衆送信等を禁じます