全日空のシステム障害を考える
全日空は、5/27（日）の未明から同日15時半まで、国内搭乗手続きに関するシステムで障害を起こしました。 これによって運行の遅延や一部欠航が生じ、6万人弱に影響が出たそうです。
同社の発表によれば、システム障害の発生箇所は「総合旅客システム（able-D）」と呼ばれる全日空グループの予約・ 発券システムのうち、国内旅客系に関するホスト端末間（全6系統中3系統）であったとのこと。
問題となった3系統（サーバ3台）は5月上旬から24日まで2週間かけてアプリケーションのアップデートを行っており、 26日になってから原因不明の処理速度低下が発現していたと述べられています。
暫定処置として、更新したサーバを旧サーバに戻して更新前の状態を復元したところ、 処理速度が回復して問題を回避することができたということも発表されました。
同社広報は「週末に顧客が増え、システムに負荷がかかった可能性もある」というコメントを出し、夜には 「ホスト端末間のネットワークに何らかの障害が起き、それが処理速度を低下させた」と追加コメントをしています。
このニュースを見て、目に付いた点を少々触れておきたいと思います。。
・変更前バックアップを準備し、RPOを明確に定義していたこと
・アプリケーションのアップデートを順次展開としたこと
システム運用に携わっていて非常に大切だと感じることは、万一の事態が発生した際に、
速やかに以前の状態に復帰できるよう準備をしておくことです。以前、マイクロソフトが運営する質問コミュニティ（答えてネット）が、
切り戻しデータを確保していなかったばかりに、システムのアップデート中にクラッシュして、
サービスの一時停止に追い込まれたという出来事があったのを覚えているでしょうか？
（参考）http://www.itmedia.co.jp/news/articles/0608/23/news067.html
世にリリースされているITサービスの一部は、予算的、スケジュール的に問題がある場合も含めて、 システム変更の切り戻しポイント目標（RPO）に対して実用的ではないバックアップを利用しているケースが多々あります。
例えば、日常頻繁に使われているシステムのフルバックアップが月次単位であるばかりに、 月末近くにシステムのフルリカバリが必要になっても、月初のフルバックアップから日次差分データを毎日分当てなければ復旧できず、 その時間が24時間以上かかった・・・などというケースは十分ありえる話です。
今回は、切替前のサーバをすぐに潰すのではなく、しばらく残していたことが迅速な環境切り戻しの成功要因でした。 もしバックアップデータからの復旧を余儀なくされた場合、復旧にもっと時間を掛けていたことでしょう。
それから、全6系統（6サーバ）のうち3系統のみでアップデートが行われていたことも重要なポイントです。
ITサービスのリリースでは、少しずつ変更を適用して影響範囲を最小限に抑える「順次展開アプローチ」と、一度に置き換えを実施する 「ビッグバンアプローチ」の2種類が存在しますが、旅客システムのように社会インフラとして機能しているシステムでは、 社会に与える影響まで考慮したビジネスインパクト分析が必要になります。
今回は、更新した3系統が全て死んでしまっても、残りの3系統＋手作業で業務の完全停止という自体だけは避けることができました。※ もちろん、多大な影響を周囲に与えてしまったことは反省しなければなりませんけど。
最後に、こういった障害が発生したときに、万一にそなえた復旧計画（コンティンジェンシープラン） を用意することの重要性は皆さん既にお分かりと思いますが、同じくらい大切で難しいのが、 障害が発生してからの状況報告をどのように行ったか、具体的に言うと、プレスリリースをどのタイミングでしたか、という点です。
今回のパフォーマンス低下障害は、既に前日からその傾向が見られていたわけですが、実際にプレスに向けて発表されたのは、 手作業による業務リカバリが難しくなった正午近く。何も知らない人が見ると、どうしてもっと早く発表してくれなかったのか、 という非難も聞こえてくると思いますが、逆に言うと、これはダメだという見通しが立ったのがそのタイミングだったということです。
ここで争点になるのは、広報側と業務側、そしてシステム運用側の意思疎通がリアルタイムで行われていたかどうかでしょう。 現場での状況認識は正しかったにも関わらず、広報への連絡が遅れたためにプレスリリースも遅れ、その結果、外部への影響を拡大してしまった、 そういう話も枚挙に暇がありません。
企業によっては、システム障害が発生した場合、インパクトが大きいと判断したものについては、 運用現場に広報担当者を一人置くこともあります。もしくはテレビ会議システムによって、 常時双方の状況を確認できるようにしたりすることもありますね。
今回の件は、20年近く稼動している全日空のable-Dについて、
日本ユニシスさんが昨年4月からオープン化を進めていた過程で生じた障害のようですが、
やはり大規模基幹システムの置き換えというのは何が起きるか分かりません。今週や来週のIT系記事で様々な議論がされると思いますので、
しばらくはそちらをウォッチしていようと思います。
参考）http://www.unisys.co.jp/news/NR_060420_AirCore.html
キーワード記事*