東証システム障害(20年10月1日)について、シニアが少し考えてみた
こんにちは、そして、こんばんは、ただっしゃん(@tadashian1)です。 当ブログにお立ち寄り頂き、誠にありがとうございます。
先日の東証システム障害の詳細が発表されました。根本原因はメモリ障害ですが、No.2に切り替わらなかった原因の一つは驚きの設定不良とマニュアルの不備だそうです。(びっくり!)
東京証券取引所は2020年10月19日、株式売買システム「arrowhead(アローヘッド)」で2020年10月1日に発生したシステム障害について、詳しい発生原因を発表した。「共有ディスク装置」NAS(Network Attached Storage)のマニュアルに不備があり、設定値が本来意図した機能を果たさず、NASの故障時にバックアップ機に切り替わらなかった。
今回の障害ではNASの1号機でメモリーカードに対して読み書きできない部品故障が発生し、2号機に切り替わるはずが切り替わらなかった。東証が詳しい原因についてarrowheadを構築した富士通と調査した結果、マニュアルの不備が分かった。故障時の切り替えについて、マニュアルには設定値の「ON」が「即時切り替え」、「OFF」が「15秒後に切り替え」と記載してあったが、実際の「OFF」は「切り替えない」という動作だった。東証と富士通は「NAS故障時に30秒以内の切り替え」を要件にしていたためOFFに設定していた。マニュアルに不備があった理由は、NASの製品仕様が変わった際に、その変更をマニュアルに反映し漏れたからだ。2015年9月にarrowheadを2代目に刷新した際、反映し漏れた。富士通はNAS出荷時、初期値の「ON」の動作をテストしたものの、「OFF」の動作をテストしなかった。現在のarrowheadは2019年11月稼働の3代目だがマニュアルの不備が残ったまま稼働・運用していた。
私はメモリが故障して、系統が切り替わらなかったのは、ソフトなのかハードなのか、もっと不具合らしい(?)・・・原因を予想していたのですが、まさかのマニュアルの不備と動作チェック漏れだったとは・・・
これはもう、人災、ヒューマンエラーといってもいいかもしれませんね。
メモリやハードディスクは壊れるという前提で考えないといけません。ハードディスクやメモリーが壊れることは日常茶飯事みたいなもんだったからです(昔は特に)。そうすると、稼働系(現用系)を予備系(他系)にスムーズに切り替える事は必須な事項となります。
マニュアルの更新をしていなかったと言う事も驚きですが、「OFF」の動作をしなかったの事、つまり初期値の「ON」でのチェック動作OKで良しとしてしまった、チェック項目漏れかもしれません。約5年もの間、放置されていて稼働・運用し続けて・・・今回の障害発生で露呈、初歩的なミスにこれまた、驚かされます。
ただ、実際の障害を起こさせて、検証となると、大変だろうなとは、少しだけシステム運用をかじったものとしては分からないわけではありません。
本番環境に近づけてテスト環境で検証するという簡単なようで大変だろうなと想像できます。またテスト環境のままで、本番に移行しちゃうってのはよくやる失敗なんですよ。
だから、検証の後検証、これがとっても大事なのです。イレギュラーな事をしたときこそ慎重になる事がいかに大切か、骨身に染みています。
重大な障害の原因の裏には凡ミスが結構、潜んでいるもんなのです。
関係役員の処分を検討して、社長直轄の組織で再発防止に取り組むといっても、どうかなあ、社長自ら、陣頭指揮に立つって言ってるけど、こうでも言わないと恰好つきませんからね。
初期値の「ON」の動作でチェックができたとき「OFF」は「ま、いっか」的な気持ち、になってしまったのかなあ。まあ、私はわからなくはないです。ちょっとした気持ちのゆるみでスルーしたのかもしれません。
でも、今回はことの結果があまりに重大なので、かなり厳しい処分が下ると思います。SEや運用エンジニアは気が休まる時間がありませんね。
私は現場の人達に同情します。でも、酷な言い方かもしれませんが、障害を起こしてしまったことは隠しようのない事実なので仕方ありません。
だから、ダブルチェック、複数人のチェックが必要になります。
今回は設定ミスなのですが、オペレーションミスを防ぐために、指差し確認、声出し確認するようにしています。「右よし、左よし」ってやつですね。それも複数人のチェックで。基本的なことですが、これに結構助けられているんです。歳を取ってもこの癖は続けていきたいと思います。
ブログ読者の皆様が、健康でありますように!最後までお読みいただきありがとうございます。 ・・・心はいつもどまんなか。 by tadashian