【航空】ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン

海江田三郎 ★

http://itpro.nikkeibp.co.jp/atcl/news/16/033000936/
　全日本空輸（ANA）は2016年3月30日、3月22日に発生した国内線システムの不具合について、原因や再発防止策などを公表した。国内線システムの4台のデータベー
ス（DB）サーバーをつなぐ米シスコシステムズ製イーサネットスイッチの故障が原因だった。

4時間40分かけて4台が次々停止

　ANAによれば、3月22日午前3時44分にDBサーバーの1台が停止した。その後2台が停止し、約4時間40分後の午前8時22分に最後の1台も停止。
DBサーバーが停止した理由は「正常に機能が働いた」（ANA広報）ため。4台のDBサーバーはデータを同期しており、同期処理が異常終了した場合に自動停止する機能を備えていた。
同期処理が失敗した原因は、4台をつなぐスイッチの不具合。具体的には、スイッチが故障状態であるにもかからず、故障を知らせる
「故障シグナル」を発信しなかった。国内線システムは故障シグナルを検知するとスイッチを予備機に切り替えるが、今回はその機能そのものを作動できなかった。
　スイッチは完全に停止したわけではなく、「不安定ながらも動作していたようだ」（同）。そのため、DBサーバー間の同期は順次失敗し、停止していったと見られる。
　ANA広報によると、スイッチは米シスコシステムズ製「Catalyst 4948E」という。「2010年6月の発売開始以降、世界で4万3000台、
うち日本で8700台を販売しているが、今回の不具合は初めての事象と聞いている」（ANA広報）。なぜ「故障シグナル」が発信できなかったかは分かっていない。

1台での縮退運転を決断
　4台の完全停止から37分後、ANAは1台のDBサーバーを再起動。だが「2台起動すると2台とも停止する」（同）といった不安定な状況が続いた。
DBサーバーは1台構成でもシステムで全機能を使えるという。ANAは午前9時27分に1台での運用を決めた。ただし既に空港などでの混乱は始まっており、
詳細な原因も定かではなかったため、「お客様対応を最優先するために搭乗手続きの機能だけを稼働させた」（同）。予約や販売などの機能は稼働させず、縮退運転とした格好だ。

　午前11時30分、全ての空港で搭乗手続きの機能を使えるようになった。自動チェックイン機や係員が使う端末が少ない空港での機能回復は早かったが、
羽田空港など大規模空港では端末の再起動を順次進めたため時間がかかったという。
　予約やWebサービスを復旧させつつ、ANAは障害原因を探った。DBサーバー、アプリケーションサーバーを順次調べ、異常がないと判断。スイッチの不具合を疑った。
「本番環境と同等の作りにしてあるテスト環境にスイッチを持ち込んでテストしたところ、不具合が再現した」（ANA広報）。
　ANAはすぐにシスコに不具合を連絡して代替機を取り寄せた。代替機に交換したのが翌23日午前1時14分。午前3時5分にはDBサーバーを4台構成に戻し、午前4時14分には全サービスを復旧した

トップの報酬減額
　ANAは再発防止策も公表。まず同様の不具合でもシステムが正常稼働するようにトラブル発生2日後の3月24日にシステム改修を終えた。
スイッチが「故障シグナル」を出さなくても、DBサーバーからスイッチの故障を検知できるようにした。
（中略）

国内線システムはアプリケーションとシステム基盤を含め、日本ユニシスが構築を担当。
同社広報は「システム障害でご迷惑をお掛けした皆様へお詫びするとともに、システム開発会社として責任を認識している。
お客様（ANA）と改善策を検討していきたい」と話す。シスコシステムズ日本法人の広報は「今回の不具合はこれまで世界で報告が上がっていなかったもの。全力で原因究明と再発防止に取り組む」とした。

「止まらないシステム」構築の難しさ浮き彫りに

　ANAでは2013年2月に国内線旅客システムをメインフレームからオープンシステムに再構築して以来、初めての大きなトラブルとなる。
実は旧システム時代の2007年5月に発生した大規模なシステム障害時もシスコのスイッチ不具合が原因だった（関連記事：【会見詳報】ANA障害の原因判明、「世界4例のスイッチ故障がきっかけ、対応も遅れた」）。

　社会インフラを支える大規模システムになればなるほど、構成要素が増え、アプリケーションは複雑になる。関わる人も大量だ。
信頼性を高める努力を続ける一方で、システムは必ず止まるという前提で事業継続性をどうデザインするかが新たな課題になりそうだ。