ANA システム障害原因
2023/4/3 に発生したANA システム障害の原因が2023/4/7に公表されました。
4日後の公表が遅いとみるか、早いとみるか・・・。
きっと内部の人達は、寝ないで原因を調査したことでしょうね・・。
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グループのシステム開発・改修会社)
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)を使用しているため影響はないと思われます。
- 関連5社(ANAのable-Dを使用している航空会社)で予約・販売、搭乗手続きに影響が及んだ。
- 羽田空港の発着便
影響範囲のど真ん中に羽田空港がおり、18時以降のほぼすべてが欠航した。(55便)最終的に以下の影響が発生した。
- 欠航 55便
- 遅延便 計 155便(約2万人に影響)
- 累計 約 2万6700人
システム障害に至る代表的な要因は何がある?
- ハード(メモリ・HDD 等)
- ソフト(バグ)
- 通信(中継機器 等)
- システム処理能力超過
- 設計要件定義不足
- ヒューマンエラー(作業ミス)
- ウイルス(サイバー攻撃 等)
概ね、上記の7つほどかと思います。
able-D システム障害原因
ANAのオンラインでの説明会についての記事がとても分かりやすかったです。
↓ こちらの記事 引用 mobilitech
過去記事で、A系(B系) DB1 / DB2 は、DB1 が死んでもDB2 1台で稼働継続可能だと仮に前提しました。
↓ 良かったら過去記事も読んでね。
やはり、想定では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には、接続・連携している多くのソフト群が存在しています。
これらのソフト群に影響が出ないか、一つも残さずに確認せねばなりません。
それも実践でいきなりテストするのではなく、可能な限り実践に近いテスト環境の構築、テスト内容の検討をしなければならないでしょう。
それだけで、膨大な労力とコストを必要とします。
所感
重要インフラの一つである空港(航空機による移動)が社会に与える障害のインパクトは甚大ですね。
電力も電車も同じかと思いますが、使えて当たり前、使えないと怒り狂う。
怒る気持ちも十分に理解出来ます。
移動するだけではなくて、旅行先の計画、ビジネスチャンスを逸する、慶弔、皆さん飛行機に乗るのが目的ではなくて、目的を果たす交通手段として飛行機を選択したのですから。
もちろん、私もその場面に遭遇したら怒るだろうなと思います。笑
でも、機械は壊れますし、ソフトウェアは人間が作る以上はバグがどうしたって潜在する。
どうすればよいかと言えば、「どうしようもない」に行きつくかと思います。笑
では、また!