数年前に似た障害があったが、
ANAシステム障害 顧客DB同期処理失敗?
ANAシステム障害 顧客DB同期処理失敗? その2
今回は別の原因がらしい。
4月3日に発生した国内線システム不具合の原因及び再発防止策について
4月3日に発生したシステム不具合により、多数の国内線に欠航・遅延を生じさせる結果となりました。ご利用のお客様、関係の皆様に多大なご迷惑をお掛けいたしましたこと、深くお詫び申し上げます。この度の不具合につきまして調査を行った結果、原因が明らかになりましたので、再発防止策とあわせてご報告申し上げます。
発生原因
国内線旅客システムのデータベースにおける、ソフトウェア不具合であることが判明しました。具体的には、予約管理業務のために、特定のデータを抽出する日常の処理において、ソフトウェアのバグを起因とするエラーが発生し、データベースサーバー2台が一時的に高負荷状態となりました。その結果、データ処理が滞り、サーバー2台が同時停止しました。再発防止に向けた対応
（1）データ抽出方法の変更（2）データベースサーバーが2台同時に停止しないための制御プログラムの強化
上記を確実に実施した上で、万が一、今後システム障害が発生した場合に備え、バックアップシステムへの迅速な切りかえ、訓練の実施などの対策を講じるべく、引き続き対応を図ってまいります。
ANAシステム障害、原因のバグのパッチが未適用だった...判断の理由めぐり議論呼ぶ
3日、ANA（全日本空輸）で国内線全便の予約・販売・搭乗手続きができなくなるというシステム障害が起こった。この影響で同日の国内線55便が欠航、153便が30分以上の遅延となったが、データベース管理システム（DBMS）のエラーの原因となったバグ（プログラムの欠陥・不具合）のパッチ（修正プログラム）がリリースされていたにもかかわらず、ANAがそれを適用していなかったことが関心を集めている。ANAが7日に発表した障害の原因調査報告によれば、国内線旅客システム「エイブル」から社内で利用されている予約管理支援システムへデータを抽出する際にエラーが発生し、データベース（DB）がフリーズ。エイブルはシステムの冗長性の観点から同一構成の「A系」と「B系」の2系統からなり、さらに各系統内ではDB1とDB2が用意されデータの同期がとられている。今回、A系のDB1がエラーによりフリーズしたことで、DB2で処理待ちが発生し高負荷化状態となり、2つのDBが停止。B系へ切り替えて復旧に至った。
障害の直接の原因となったのは、「エイブル」から社内の予約管理支援システムへのデータ抽出時のエラーとみられる。ANAはデータ抽出方式について、これまでの複数のクエリ（実行命令）を同時に並列処理する方式から、1つずつ処理する「直列処理」に変更することで再発防止につなげるとしている。7日付「日経XTECH」記事によれば、当該DBMSではクエリの並列処理を行うとまれにエラーが発生するバグが過去に見つかっており、18年にパッチがリリース済みだったものの、ANAはそのパッチを適用していなかったという。
今回のANAの障害は、パッチが適用されていれば発生しなかった可能性はあるのか。
「原因として説明されているのは、DBに対して同時に複数の要求を送るとまれにエラーが発生するという重大な問題です。もしパッチを適用していれば、今回のシステム障害を避けられた可能性はあります。しかしDBの根幹部分の挙動が変わることで、安定して動いていた別の機能に不具合が出る恐れがあります。動作検証のためにはシステム全体を長時間止める必要がありますが、飛行機は年中無休で飛んでいるため困難を極めます。
当該エラーの発生確率が十分に低く、万が一発生した場合でも予備のシステムでカバーできるとの判断からパッチの適用を見送ったのでしょう。しかし昨今の旅行再開や新年度といった要因が重なり、想定を超える事態に陥った印象を受けます」
感想：
ネット記事のタイトルは、「バッチ適用怠慢」的な誘導的な書き方だったが、そんな単純なChange Managementの問題ではない。
バグが簡単に治せいのは、10年前のアーキテクチャーのせい。
全ての処理はこの二台のDBに集約されているから、依存関係が複雑すぎていて、変更管理の大変さが想像できる。
ANAの方で既に新しいシステムの設計に着手しているかもしれないので、今後を期待するしかない。
疎結合で、データ抽出専用のDBとアプリケーションがあればいいのにを思った。
Comments