G's のつぶやき

日々のできごとから

・思うこと

・参考になること

・調べた結果

などなど、記載していく予定です。

東証売買停止の障害について②

▼10/1の東証売買停止のNewsより

 いろいろ調べてみた。

10/6の報告によれば、

 「障害は、ストレージ内でメモリ故障が起き、サブ機にも切り替わらなかったことが原因。

  メモリ故障による障害が起きた際、自動切り替えできない設定値になっていたという。

  arrowheadのユーザー情報などを格納するストレージ「共有ディスク装置」の1号機に搭載されたメモリが故障したことに起因。

  1号機が障害を検知すると、切り替え用設定値に従って自動で2号機に切り替わるはずが、切り替わらなかった。

  調査したところ、メモリ故障が原因の障害パターンが発生した際、自動切り替えできない設定値になっていたという。

  設定値を変更すれば、自動切り替えできることが判明。4日にシステムに適用し、自動切り替えが動作することを確認したという。」

 

結局、テスト時において何が足りなかったのか。。。

 

昨今の障害テストは、必要最低限しか実施しないで満足している傾向がある。

アプリケーションの個別テスト、結合テスト、システムテストだけでもかなりの工数を食うだけでなく、

インフラ(ハードウェア)の様々なテストも考えると、

かなり莫大な工数を食うものである。

そこにあらゆる障害のケースを検討するわけだが、

今回も「自動切換えの障害テスト」は実施したということで安心し、

どういう事象の場合に「自動切換え」が必要なのかは、

考慮が漏れていたと言わざるを得ない。

 

以前にも増して、

サーバーの構造は複雑であり、

それはハード面、

ソフト面含めて、

どこにどういう事象で障害が起きた場合、

そういうリカバリーを検討するべきなのか、

あらゆるケースを想定して、

確認する必要がある。

それは、机上の確認だけでなく、

実際の障害ケースを起こして確認しておけば、

安心材料は多いわけだが、

今回のように、メモリの故障を実際に起こすことは難しい。

とはいえ、その代替ケースは検討しておくべきであり、

必要なケースはつぶしておくべきだが、

ある程度障害ケースをこなすと

「もうこれで大丈夫」という身勝手な安心感が生まれたりするのである。

 

慢心を抑え、今一度起きうるだろう問題に向き合うための

心の余裕と、スケジュールの余裕、

評価やチェックの機能と体制を設けておくべきである。

もし検討が不足しているのであれば、

リリース後であっても放っておかず、

引き続き検討する等の正義があってほしいものだ。

コメントを送る

※ メールは公開されません
 
Loading...
 画像の文字を入力してください