2016年3月22日に全日本空輸(以下、ANA)で発生した国内旅客システムの障害により、大きな影響がありました。報道によると、全国49の空港で搭乗手続きができなくなり、ホームページや旅行会社を通じた搭乗予約も受け付けられなくなりました。その結果、国内線146便が欠航し、391便に遅れが生じ、7万人以上の旅客に影響があったそうです。また、ANAと提携している航空会社にも欠航や遅延が発生しました。
3月30日に会見が行われ、システム障害の原因が複数のデータベースサーバーを接続するネットワーク中継機の故障であったことが発表されました。今回障害が発生したANAの国内旅客システムのように、大きな業務を支援するシステムでは様々な機器やソフトウェアが連携して稼働しているため、たった一つの機器の故障であってもシステム全体に影響し、業務継続が困難になる事態は十分起こり得ることです。
今回はこうした大規模なシステム障害が発生した場合の対応について、システムと業務の両面で確認します。

ANAでのシステム障害の経過

報道内容等から、ANAのシステム障害について、時系列でまとめた内容は以下の通りです。情報が限られているので想像も含みますが、当日の様子がどのような状況だったか確認します。
ANAシステム障害時系列
午前4時少し前に4台あるデータベースサーバーが停止した後、午前8時半前にはすべてのデータベースサーバーが停止したようです。時刻表を見たところ、羽田空港では午前6時頃から航空機の発着が行われることから、この日は始発からシステムトラブルを抱えたまま業務を行っていたと考えられます。また、この時間帯だと一般レベルのシステム運用者が障害対応に当たっており、システムに詳しく、トラブル対応能力のある担当者が対応していたかどうかは未知数です。恐らくは2台、3台とサーバー停止するところで緊急連絡を入れ、早めの出社を要請したのでは、と想像できます。
データベースサーバーが全台停止後、復旧を試みるも稼働が不安定なため、停止から約1時間で搭乗手続き機能に限定した縮退運転を行うという判断がされました。その後約2時間でシステムを利用した搭乗手続き業務が復旧しましたが、この時点でもうお昼前であり、午前中の便で登場する予定だった旅客で混乱していたことが想像できます。結局、その日は終日混乱が続く状態であったことは報道等で伝えられた通りです。
空港での混乱と並行して情報システムでは原因究明とシステム復旧に努め、ネットワーク中継機が原因であることを突き止めて機器交換を行ったのが翌23日になってからであり、全面復旧は障害発生からおよそ1日経過した23日の午前4時を過ぎたところでした。

ANAでのシステム側の対応について

今回のANAでのシステム障害の原因は、データベースサーバーを接続するネットワーク中継機の故障ということでした。その詳細は、以下の通りです。

1.ネットワーク中継機能の故障に伴うデータベースサーバーの自動停止
データベースサーバー間の同期処理が正常に完了しないことから、データの整合性が保たれなくなるため、データベースサーバーは自動停止する仕組みとなっていた。

2.「故障シグナル」発信機能の故障に伴う予備機自動切り替えの未実施
ネットワーク中継機が故障すると「故障シグナル」を発信して予備のネットワーク中継機に自動的に切り替わることになっていたが、今回は「故障シグナル」が発信されなかったため、予備機に自動的に切り替わらなかった。

つまり、1.のデータベースサーバーの自動停止は正常動作だと言えます。その間に2.の自動切り替え機能が働くことで正常稼働に戻る、という仕組みだったのでしょう。よって、2.の自動切り替え機能が働かなかったため、データベースサーバーは停止したままとなってしまい、システム全体がストップしてしまったと考えられます。
この場合、データベースサーバーが1台しか稼働しないとネットワーク中継機能を介したデータ同期処理が行われないため(ワーニングは出るとは思いますが)、システムが通常通りの動きをすることから、データベースサーバー1台での縮退運転で切り抜けようと考えたのでしょう。もちろん、稼働させたデータベースサーバーに何らかの問題があれば再びシステム全停止というリスクはありましたが、あとは実際に対応した現場の感触で「いけそうだ」、という判断に至ったと思われます。結果的に、この判断は正しかったと考えられます。

しかしながら、ネットワーク中継機の故障という原因究明までは、どこまで時間がかかったかは不明確です。実際に故障した機器を交換したのが翌23日の午前1時過ぎとなっていますが、これは業務中の機器交換は二次被害を引き起こす可能性があるので、当日の業務処理を終えた段階でバックアップデータを取得した後、作業に入ったからでしょう。

すぐに原因究明できなかった理由として、不安を抱えたシステムの安定稼働が当面の優先すべき作業であったため、原因究明にそれほど注力できなかった、という事情はあったと思います。もう一つの理由としては、

「ネットワーク中継機が故障したら「故障シグナル」を発信して予備機に自動で切り替わる」

という仕様が絶対的なものだというバイアスが掛かってしまい、当初はネットワーク中継機に誰も注意が向かなかったのでは、と想像されます。

バックアップシステムはどうなのか?

こうした大規模障害が発生した場合、

「バックアップシステムはないのか」
「バックアップシステムを動かさないのか」

という疑問を投げかける識者(と呼ばれている)の方々の発言が見られます。しかしながら今回のケースの場合、バックアップシステムへの切換えは得策でないと考えられます。

今回のトラブルは複数サーバー間のデータ同期ができないことに由来するデータベースサーバーの停止です。バックアップシステムを稼働させようと考えた場合、ホットスタンバイ形式であれば、この時点でデータの同期が行われていないため、データが不整合な状態で稼働することになります。また、データを非同期で反映させている場合、データ反映までの時間はシステムを稼働させることができません。例えば当日のデータを翌日に反映させるような仕組みの場合、データの反映に数時間が狩ることが想定されます。いずれにしろ、再稼働は22日午後くらいになる可能性が高かったと考えられます。

また、原因が不明確なことも問題です。もしハードウェアの問題であれば、機器交換を行うことで正常稼働させることができます。ソフトウェア上の問題であれば、バックアップシステムを稼働させても同じトラブルが発生する可能性があります。

最後に、バックアップシステムを稼働させても、いつかは本番システムに戻す必要があります。タイミングとしては当日の旅客業務が終了し、翌日の旅客業務が開始するまで、つまり夜中から早朝5時くらいまで(始発は6時頃のため)の時間で再度切り替え作業を行わなければなりません。

以上のことから、バックアップシステムに切り替えての稼働はリスク含みであり、手間もかかるため、本番システムでの復旧の方がよさそうだ、という結論になります。

このことはあらゆる基幹系のシステム障害でも言えることです。バックアップシステムに切り替えることが有効であるケースは、本番システムのある施設に物理的な破壊が行われた場合や、ライフライン普通などの使用に耐えられない事象が発生した場合に有効ですが、それ以外のケースでは慎重に判断すべきであると考えます。なお、基幹系システムをサポートするサブシステムで、過去のデータとの連携を必要としないようなものであれば、バックアップシステムに切り替えても弊害が少ないかもしれません。

ANAでの業務側の対応について

システムの縮退運転が決まってから搭乗手続き機能が復旧するまで、およそ2時間が経過しております。端末再立ち上げ等で時間が掛かったと言われていますが、もしかしたら、データベースサーバー1台による稼働のため、処理がオーバーフローしない様に段階的な端末再起動を行ったためであったと考えられます。

その間、業務側ではどのような対応だったのでしょうか。

当日のTwitter等の投稿を見ると手書きのチケットを発行する等、手作業による業務対応が行われていたようです。当日の混乱状況は現地に行ってないので分からないのですが、搭乗予定者の問い合わせや苦情に対応しながら、搭乗チケットを発行し、可能な限り旅客業務に対応していたことは、お手本にすべき内容なのではと考えます。実際には、ANAは過去にも大きなシステム障害を数回起こしたことがあるので、その教訓として、従業員にシステム停止時の業務対応についてマニュアルが作成され、教育も行われていたと考えられます。また、手書きチケット等の備品も手に届く場所に常備されているのでしょう。そして最も重要な要素は、システム障害による旅客対応で実際にクレームを受け、様々な対応を行った現場担当者の存在です。実際に苦労された方々が身をもって学んだ教訓が生かされていたのだろうと考えます。

昨今、様々な業務に情報システムが導入され、その依存度が高くなっております。中には
「ここまではシステムがやってくれるから」
「この部分だけ覚えておけば大丈夫」
という教育を行っているのも散見されます。新入社員や配置転換されて不慣れな業務を行う担当者であれば、当初は業務を円滑に実施するという観点で、こうした教育もありだとは思います。しかし、少なくとも業務を理解し監督する立場であれば、システム処理の部分がブラックボックスのままでは問題です。それは、業務の本質を認識していない可能性が高いからです。当然、その様な従業員ではシステム障害が発生した場合、手作業で業務を実施することはできません。さらに重要なことは、システム復旧後に入力すべき業務記録を保存するという考えに至らないことが十分に発生しうることです。特に内部統制報告制度(J-SOX)の対象である上場企業などは、システム処理と同等レベルの業務記録を保存する手順を整備しておかないと、業務統制が十分でない、という判断をされる可能性もあります。

いわゆる業務継続計画(BCP)について、情報システム部門が対応することだと考えている方も多いようです。それは、ITベンダーがBCP対策として様々なサービスを提供することも一因だと思います。しかし、絶対に停止しない情報システムは存在せず、情報システムだけで解決する問題ではありません。その前提で、システムが長時間停止する場合に業務を継続するのであれば、以下の事項について検討し、整備し、社内に定着化させる必要があります。

  • 手作業でのマニュアル作成
  • 手作業で業務実施できるよう従業員の教育
  • 業務記録の保存手順
  • 手作業による業務実施のための備品等の常備

以上の様な対応ができなければ、「業務を中断する」という判断をすることも重要です。

参考:
全日本空輸ホームページ、「【お詫び】3月22日に発生した弊社の国内線システム不具合について

上記内容に関するご相談やお問い合わせについては、「お問い合せ」のページからご連絡ください。

デルタエッジコンサルタントでは、システム障害時の業務継続に関して、
・情報システム部門での対応計画策定
・手作業による代替業務手順の策定
・従業員に対する教育、訓練
を支援するコンサルティングサービスを提供しています。詳細はこちらをご覧ください。
==>「コンサルティングサービス-リスク管理」のページ
興味や関心がございましたら、ぜひご連絡ください。

コンサルティングサービス-リスク管理
お問い合わせ