ANA　システム障害原因

2023/4/3 に発生したANA システム障害の原因が2023/4/7に公表されました。

4日後の公表が遅いとみるか、早いとみるか・・・。

きっと内部の人達は、寝ないで原因を調査したことでしょうね・・。

ANA　システム障害原因

able-D（エイブル）とは？

そもそも「able-D（エイブル）」と言われても知らない人がほとんどではないかと思います。

予約・販売・搭乗手続き・顧客を主たる機能として有している「予約管理支援システム」の名称になります。

簡単に言うと、ANAが使用しているチェックイン系のソフトウェアの名称です。
具体的には、ANAシステムズ（ANAのグループ企業）へのインタビュー記事を引用しました。

「予約」、「発券」、「搭乗」という3つのサブシステムから構成されており、
航空会社専用のパッケージソフト（AirCore）をベースに、搭乗手続きをせずに
直接保安検査場にお進みいただける「スキップサービス」や「コンビニ決済」といった、ANA独自のサービスや機能を追加しています。
システムの規模は公開していませんが、ANA国内線一日約800便、搭乗者10万人以上をハンドリングするシステムです。
引用 https://www.ricksoft.jp/case-studies/ana.html

ANA able-D　のベンダー会社はどこ？

able-D をANAに提供したベンダーは、BIPROGY社と言う会社です。

ANAの基幹の多くを手掛けている大手ベンダー会社。
国内・国際貨物システム、ロードコントロールシステムの保守開発を担っています。

able-D 開発ベンダー会社の歴史
1947年　日本レミントン・ユニバック（株）の前身となる吉澤機器（株）設立
1958年　日本レミントン・ユニバック（株）（現BIPROGY（株））設立
1968年　日本レミントン・ユニバック（株）が日本ユニバック（株）に社名変更
1971年　日本ユニバック（株）、東証一部上場に指定替え
1988年　日本ユニバック（株）とバロース（株）が統合、日本ユニシス（株）発足
2013年　世界初、オープンシステムによる国内線旅客システムの稼働開始（able-D）

ANAシステムズ株式会社（ANAグループのシステム開発・改修会社）

www.anasystems.co.jp

2023/4/3 able-D システム障害概要

発生日時
4/3 14:10頃、羽田空港第2ターミナル ANA国内線でチェックイン手続きが一時的に不可となり、出発ロビー内の大混雑が発生しました。
障害状況
able-D（エイブル）と呼ばれている航空券の予約や販売、搭乗手続きに関するシステム（able-D）に不具合が発生した。
このシステム障害で、一時的にANAおよびANAのチェックインシステムを使用している関連 5社（後述あり）の全便でチェックイン手続きができない状態となり、
チェックインカウンターで大混雑が発生した。
1時間後の15:10頃に、バックアップシステムが稼働してチェックイン手続きが再開された。
しかし、able-Dのシステム障害が発生してから3時間が経っても、チェックインカウンターや保安検査場の長い行列は解消せず、15:10以降も混雑は解消されず、当日の運航に大きな影響を与えた。
影響範囲
able-Dを使用している全国各地の空港でチェックイン手続きに影響を与えた。
- 関連5社（ANAのable-Dを使用している航空会社）で予約・販売、搭乗手続きに影響が及んだ。
  - airDo（エア・ドゥ ADO/HD）
  - ソラシドエア（SNJ/6J）
  - スターフライヤー（SFJ/7G）、
  - IBEX（アイベックスエアラインズ IBX/FW）
  - オリエンタルエアブリッジ（ORC、NGK）
    ※ 国際線は、他システム（Amadeus Altea）を使用しているため影響はないと思われます。
羽田空港の発着便
影響範囲のど真ん中に羽田空港がおり、18時以降のほぼすべてが欠航した。（55便）最終的に以下の影響が発生した。
　　
- 欠航　55便
- 遅延便　計 155便（約2万人に影響）
- 累計　約 2万6700人

システム障害に至る代表的な要因は何がある？

ハード（メモリ・HDD 等）
ソフト（バグ）
通信（中継機器等）
システム処理能力超過
設計要件定義不足
ヒューマンエラー（作業ミス）
ウイルス（サイバー攻撃等）

概ね、上記の7つほどかと思います。

able-D システム障害原因

ANAのオンラインでの説明会についての記事がとても分かりやすかったです。

↓　こちらの記事　引用　mobilitech

mobilitech.jp

過去記事で、A系（B系） DB1 / DB2 は、DB1 が死んでもDB2 1台で稼働継続可能だと仮に前提しました。
↓ 良かったら過去記事も読んでね。

crosscubja60.net

やはり、想定ではA系 DB1 or DB2 のいずれか片側のDBで空港の運用に耐えられる設計ではあったそうです。（現実はそう上手くはいきませんでしたが・・）

障害発生フロー（簡略）
バグにより、A系 DB1がエラーで停止。
↓
A系 DB1 フリーズ
↓
A系 DB1がフリーズしているため、A系 DB2 は A系 DB1との同期処理を待機した。
この間、処理すべきデータ（レコード）が続々とA系 DB2に溜まっていく。
↓
A系 DB2の保留データ処理量の増加により高負荷状態となりフリーズ。
↓
A系が全停止。

今回のシステム障害は、「ソフト（バグ）」によるDB1/2の同時停止が主たる要因に挙げられています。
DBは、恐らくOracleだと思いますが、今回の主要因であるソフトのバグのPatch（修正プログラム）は2018年にリリース済でした。
ANA（ANAシステムズ、BIPROGY社も？）は、このPatch（修正プログラム）がリリースされていることは把握しており、『Patchは適用しない』と判断しています。
バグの発生頻度と、Patchをあてた際のテスト作業類の作業負荷、Patchをあてたことによるバグ修正後のバグの発生を天秤にかけ、A系・B系の冗長化でも乗り切れると判断した模様です。
これは、至極妥当な判断だと思います。
ANAが、全国各地の空港で飛ばしている国内線に使用しているチェックインシステム（abl-D）のDBにPatchを当てる後、抱えるリスクがあまりに大きいからです。
able-Dには、接続・連携している多くのソフト群が存在しています。
これらのソフト群に影響が出ないか、一つも残さずに確認せねばなりません。
それも実践でいきなりテストするのではなく、可能な限り実践に近いテスト環境の構築、テスト内容の検討をしなければならないでしょう。
それだけで、膨大な労力とコストを必要とします。