東証大規模障害の原因と対策
東証が10/1に発生した全面取引停止に陥った取引システムの超大規模障害原因を発表した。
納入ベンダの富士通も発表。
簡単にいうとデフォルトの設定値を使っていたままだったのだが、ソフトウェアのバーションが変わったらデフォルトの設定値の動きが変わって、障害が起きた時に自動的に予備系に切り替わらなくなってしまっていたという事。
これIT業界では割とよくある話でサーバの設定値なんてゴマンとあるので、よく分からないところはデフォルト値のままで使うとかあって、勝手にその動きが変わってしまった事に気づかず、通常状態では影響ないのだが何か非正常な事が起きるとその設定値の動きが影響して、予期せぬ動作になって障害発生みたいな。今回の場合はデフォルト値を設定していた事は把握していたんだけど動きが変わった事は把握できてなかったと。
似たような件で自分も何回報告書作って、改善策考えて、謝って、怒られた事か。。
ITシステムは人間が作ったものとは言え人間が掌握出来るレベルをはるかに超えている。収めたベンダーがすべて把握出来る訳でもなく、受け入れる会社も全障害パターン試験出来る訳でもなく。一人ひとりが影響度を考えてリスクとしてあげて、それをいかに拾うかを考えるしかない。これ変えたストレージベンダのエンジニアは今回の事件に気づいているんだろうか。たぶんほんの出来心で動き変えたんだろうなぁ。。
NASのベンダは富士通ではなくOEMだったという事で、
1.OEMベンダの担当者がなにかの理由で動作仕様を変えると思いつく
2.OEMのSW変更される
3.OEMから顧客むけに通知を出す
4.使用しているベンダ担当者がそれを把握。影響を調査。
5.影響ありそうなのでベンダのマニュアルを更新部署に連絡
6.マニュアル部署が更新終わったら該当NASを使用している納入先に通知
7.納入先が影響をみてリグレッション試験を実施
8.検証機で設定を変更しても他に影響ない事を確認
9.本番環境の設定を変更
とかめっちゃ工程があり、各部門が連携して滞りなく実施する必要がある。誰かがまぁいいだろうとか、気づかなかったとか、知らね、とか思ったらこのフローは成立しない。実際東証も７のリグレッションで今回のメモリエラートリガーの系切り替えの試験はしてない。
問題が露呈して、調査していた中の人とても大変だったでしょうね。。大変お疲れ様でしたとしか言い様がない。その後の事後処理に追われるマネジメント陣も大変でしょうが。。こういう事があるとITエンジニア業がどんどん過酷になっていく。。
この記事が気に入ったらサポートをしてみませんか？