ANA システム障害 過去履歴
ANAのシステム障害は、今回で5回目でした。
過去のANA障害履歴が掲載されているサイトをたまたま見つけました。
↓ こちら。
5回目のシステム障害
＝これまでのシステム障害＝
1回目 2003年3月 欠航150便 約10万人に影響
2回目 2007年5月 欠航130便 約9.1万人に影響
3回目 2008年9月 欠航64便 約7万人に影響
4回目 2016年3月 欠航184便 約12.5万人に影響
5回目 2023年4月 欠航55便 約2万6700人に影響（うち遅延は計155便、約2万人）
＊影響者数は欠航と遅延を合わせた総数
2016年の不具合発生までは、稼働中のシステムとは別に構成が異なる予備のシステムを用意していたが、この時に同一システムを2系統持つ現在の構成に変更した。
また、2021年6月12日には、ANAのインターネットサービス「ANA SKY WEB（ASW）」で、航空券を予約できない不具合が発生し、国内線は翌13日、国際線は14日に復旧した。ANAのシステム構成で、ASWは今回不具合が起きた国内旅客システムの下位に位置するシステムとなる。
ANAでは過去にシステム障害が4回発生しており、今回で5回目。2003年3月に欠航150便で、欠航と遅延を合わせた影響者の総数は約10万人、2007年5月に欠航130便で約9.1万人、2008年9月に欠航64便で約7万人、2016年3月に欠航184便、約12.5万人だった。
※ サイトから引用
A系（本番系）、B系（待機系）をそれぞれRAID1（ミラーリング）で冗長化。
さらに同構成のB系（待機系）をコールドスタンバイさせることで冗長化を強化。
A系、B系ともDB1のみでシステム稼働可能と前提すれば、
- A系のDB1が障害発生 → A系のDB2 のみで稼働。
- A系のDB2も障害発生 → B系のDB1と2の稼働に切り替え。
- B系のDB1も障害発生 → B系のDB2に切り替え。
実は4重化による冗長化だった、と言うことになります。
普通に考えれば、RAIDを組んでいる中にはホットスタンバイのHDDを1台は設置しているでしょうから、冗長化はさらに強固になっているはず。
↓ RAIDについては、過去記事を良かったら読んでね。
今回は、それでも空港の運航に大きな影響が出るほどのシステム障害に至ってしまった。
・・・と言うことは、JALが破綻した後、政府専用機の運航を担っているANAは、今やナショナルフラッグとして存在している。
そんなANAが構築した相当に高額であろう4重化のシステムでも盲点（バグ？）があったと言うことになる。
公共性が高い交通手段である航空機の運航を止めないため、さらなる費用を投入して再発防止策を講じなければならないANAは本当に大変だなと率直にそう思いました。
もっと言うと、ANAがシステムを全て構築したとは思えないので、どこかのシステム会社に発注しているわけです。（たぶん）
実態は、そのシステム会社の不手際なんですけどANAが国土交通省からギューギューに締め付けれられると言う・・・。
交通手段で言えば、全国のJR、東京メトロや各都市の地下鉄、JAL、ANA、フェリー。
インフラなら、各電力会社、ガス、水道、銀行、通信（電話・ネット）。
システム障害が発生すると大きな障害に発展して、全国ネットで報道されてしまう。
使えて当たり前、使えなくなれば「何してんだ、コラーーー！！」とボッコボコにされる。
AWS（Amazonのクラウドシステム）は、結構な頻度で障害を発生させていると思うんですけど特に誰も何も言わないのは、直接的なインフラじゃないからですかね。
確か、auや行政はAWSを使っていたような気がするのですが・・・。（間違っていたらごめんなさい）
だったら、コロナ関連のクソアプリを何億も血税を投入して作っておいて、全くもって役に立ってなかった。
その点について日本国政府から国民に対して再発防止策が提示（報道も含め）されていないのは良いのですかね。。。
完全民間会社のANAの方が、よほど頑張ってると思いますよ。
なので、声援を送りたいと思います。
「がんばれ」と。
とはいっても、私は裕福ではないので航空機に乗るとしてもPeachなんですけどね。笑
PeachもANAグループなので許してね。笑
にほんブログ村
