ANAシステム障害の根本原因を考えてみた。
２０１６年３月２２日、全日本空輸（ANA）で世界初のバグが起こった。
ネットや知り合いからは非常に少ない情報ではあるが、技術者らしく再発防止のための根本原因を考えてみたいと思います。
時系列で不具合事象をたどると以下の様になる。
| 日時 | ||
|---|---|---|
そもそもANAの国内旅客システムは以下のようになっている。
参考：http://itpro.nikkeibp.co.jp/atcl/news/16/033000936/
今回復旧に要した時間は12時間弱。
たとえば、簡単なレンタルサーバーであるロリポップでも、サーバー稼働率は99.99%。これは１年間で停止していたのが53分弱にあたる。
Amazon Glacierであれば、99.999999999%の耐久性を確保している。
通常、常に動作して欲しいシステムや飛行機の様な1つの不具合で重大な事故（死亡事故など）に陥ると予想される場合は、パーツを２重または３重に用意しておき、１つが壊れたら、別のパーツがすぐに機能することによって、システムが停止したり、飛行機であれば墜落する事を避けることで信頼性を向上している。
（飛行機の場合、垂直尾翼など一個の不具合で飛行できなくなるパーツも存在する。滅多に起きないし、不具合にならない様に整備をしている）
今回の国内旅客システムでは、データベースは１つでも十分稼働できるサーバーが４重に組まれており、普通に考えるとシステム停止する確率はほぼ０に近い。
世界初のバグは、4重系を組んでいるシステムにも関わらず、12時間も停止していた。また、その原因を引き起こしたのが、シスコシステムズのCatalyst4948Eというネットワーク中継器のバグだそうです。
ANAサーバーダウンの不具合原因
ANA広報で以下の公式発表があった。
予約やWebサービスを復旧させつつ、ANAは障害原因を探った。DBサーバー、アプリケーションサーバーを順次調べ、異常がないと判断。スイッチの不具合を疑った。「本番環境と同等の作りにしてあるテスト環境にスイッチを持ち込んでテストしたところ、不具合が再現した」（ANA広報）。
問題は、「本番環境と同等の作りにしてあるテスト環境にスイッチを持ち込んでテストしたところ、不具合が発生した」ということから、テスト環境に、そのシスコ製のスイッチが入っていなかったということですね。
だから、検証不足でバグをあらかじめ見つけられなかった！
昔は、ANAも全てのシステムを自社でメインフレームとして所有していました。
だから、全ての環境に対して、信頼性テストや不具合復旧訓練などがし易い環境だったのだと思います。
しかし、最近では、アウトソーシングによって、メインフレームから、オープンシステムに変わって、システムの一部が外注先でのシステムとして稼働していることが多くなってきたのだと思います。
だから、自社システムとアウトソーシングした部分での結合テストが不足したり、アウトソーシング部分が勝手に変わっていたり。。。
そのような事により、バグが検証されずにそのまま残ってしまい、今回バグが発生したのではないかと思います。
これが根本原因ですね。
今後、これに近い不具合が他で発生する可能性が高いと思います。
気をつけたほうが良いですね。。
技術者であれば、検証してなくてヤバそうな所は、嫌な胸騒ぎがするものなのですけどね。。。
