▼10/1の東証売買停止のNewsより
いろいろ調べてみた。
日々のできごとから
・思うこと
・参考になること
・調べた結果
などなど、記載していく予定です。
▼10/1の東証売買停止のNewsより
いろいろ調べてみた。
10/6の報告によれば、
「障害は、ストレージ内でメモリ故障が起き、サブ機にも切り替わらなかったことが原因。
メモリ故障による障害が起きた際、自動切り替えできない設定値になっていたという。
arrowheadのユーザー情報などを格納するストレージ「共有ディスク装置」の1号機に搭載されたメモリが故障したことに起因。
1号機が障害を検知すると、切り替え用設定値に従って自動で2号機に切り替わるはずが、切り替わらなかった。
調査したところ、メモリ故障が原因の障害パターンが発生した際、自動切り替えできない設定値になっていたという。
設定値を変更すれば、自動切り替えできることが判明。4日にシステムに適用し、自動切り替えが動作することを確認したという。」
結局、テスト時において何が足りなかったのか。。。
昨今の障害テストは、必要最低限しか実施しないで満足している傾向がある。
アプリケーションの個別テスト、結合テスト、システムテストだけでもかなりの工数を食うだけでなく、
インフラ(ハードウェア)の様々なテストも考えると、
かなり莫大な工数を食うものである。
そこにあらゆる障害のケースを検討するわけだが、
今回も「自動切換えの障害テスト」は実施したということで安心し、
どういう事象の場合に「自動切換え」が必要なのかは、
考慮が漏れていたと言わざるを得ない。
以前にも増して、
サーバーの構造は複雑であり、
それはハード面、
ソフト面含めて、
どこにどういう事象で障害が起きた場合、
そういうリカバリーを検討するべきなのか、
あらゆるケースを想定して、
確認する必要がある。
それは、机上の確認だけでなく、
実際の障害ケースを起こして確認しておけば、
安心材料は多いわけだが、
今回のように、メモリの故障を実際に起こすことは難しい。
とはいえ、その代替ケースは検討しておくべきであり、
必要なケースはつぶしておくべきだが、
ある程度障害ケースをこなすと
「もうこれで大丈夫」という身勝手な安心感が生まれたりするのである。
慢心を抑え、今一度起きうるだろう問題に向き合うための
心の余裕と、スケジュールの余裕、
評価やチェックの機能と体制を設けておくべきである。
もし検討が不足しているのであれば、
リリース後であっても放っておかず、
引き続き検討する等の正義があってほしいものだ。