研究開発者のブログ

最近、うちの会社辞める人が多いんだけど大丈夫なのか???

ANAシステム障害の根本原因を考えてみた。

2016年3月22日、全日本空輸ANA)で世界初のバグが起こった。

ネットや知り合いからは非常に少ない情報ではあるが、技術者らしく再発防止のための根本原因を考えてみたいと思います。

時系列で不具合事象をたどると以下の様になる。

日時
不具合事象および対処
3月22日
AM3:44
4台あるデータベースサーバーのうち、1台が停止(3台にて運用)
AM8:22
残り3台が停止(全4台停止)
AM8:59
1台を再起動。データベースサーバーを複数台起動すると不安定になる状態が継続
AM9:27
データベースサーバー1台で運用することを決定。空港の自動チェックイン機や係員が使う端末の再開に向けた準備と確認を実施、段階的に搭乗手続きを再開
AM11:30
搭乗手続き業務が通常状態に戻る
PM0:46
予約販売業務機能が復旧
PM8:10
国内線インターネットサービスが復旧
3月23日
AM1:14
ネットワーク中継機を交換
AM3:5
データベースサーバーを通常構成である4台に戻す
AM3:5
国内システムに接続する全端末および他システムとの接続を再開、全サービス復旧

 そもそもANAの国内旅客システムは以下のようになっている。

f:id:electricalengineer:20160406060227j:plain

参考:http://itpro.nikkeibp.co.jp/atcl/news/16/033000936/

 

今回復旧に要した時間は12時間弱。 

たとえば、簡単なレンタルサーバーであるロリポップでも、サーバー稼働率は99.99%。これは1年間で停止していたのが53分弱にあたる。

Amazon Glacierであれば、99.999999999%の耐久性を確保している。

通常、常に動作して欲しいシステムや飛行機の様な1つの不具合で重大な事故(死亡事故など)に陥ると予想される場合は、パーツを2重または3重に用意しておき、1つが壊れたら、別のパーツがすぐに機能することによって、システムが停止したり、飛行機であれば墜落する事を避けることで信頼性を向上している。

(飛行機の場合、垂直尾翼など一個の不具合で飛行できなくなるパーツも存在する。滅多に起きないし、不具合にならない様に整備をしている)

今回の国内旅客システムでは、データベースは1つでも十分稼働できるサーバーが4重に組まれており、普通に考えるとシステム停止する確率はほぼ0に近い。

世界初のバグは、4重系を組んでいるシステムにも関わらず、12時間も停止していた。また、その原因を引き起こしたのが、シスコシステムズのCatalyst4948Eというネットワーク中継器のバグだそうです。

f:id:electricalengineer:20160406214826j:plain

ANAサーバーダウンの不具合原因

ANA広報で以下の公式発表があった。

予約やWebサービスを復旧させつつ、ANAは障害原因を探った。DBサーバー、アプリケーションサーバーを順次調べ、異常がないと判断。スイッチの不具合を疑った。「本番環境と同等の作りにしてあるテスト環境にスイッチを持ち込んでテストしたところ、不具合が再現した」(ANA広報)。

 

 問題は、「本番環境と同等の作りにしてあるテスト環境にスイッチを持ち込んでテストしたところ、不具合が発生した」ということから、テスト環境に、そのシスコ製のスイッチが入っていなかったということですね。

だから、検証不足でバグをあらかじめ見つけられなかった!

 

昔は、ANAも全てのシステムを自社でメインフレームとして所有していました。

だから、全ての環境に対して、信頼性テストや不具合復旧訓練などがし易い環境だったのだと思います。

しかし、最近では、アウトソーシングによって、メインフレームから、オープンシステムに変わって、システムの一部が外注先でのシステムとして稼働していることが多くなってきたのだと思います。

だから、自社システムとアウトソーシングした部分での結合テストが不足したり、アウトソーシング部分が勝手に変わっていたり。。。

そのような事により、バグが検証されずにそのまま残ってしまい、今回バグが発生したのではないかと思います。

これが根本原因ですね。

今後、これに近い不具合が他で発生する可能性が高いと思います。

気をつけたほうが良いですね。。

技術者であれば、検証してなくてヤバそうな所は、嫌な胸騒ぎがするものなのですけどね。。。