アカウント名:
パスワード:
東証によると、1号機が何らかの理由でダウンした場合に2号機に自動で切り替わることは システム稼働前のテストで設計・開発した富士通とともに確認していた。 しかし今回、障害の原因を調べたところ、メモリー故障を理由として1号機が機能不全となった場合に、 2号機に自動で切り替わらないことが分かったという テストは富士通が主体となって実施しており、メモリーそのものを物理的に破壊するような実験はせず、 「疑似的に1号機の機能を喪失させるテストを実施し、2号機に切り替わることは確認していた」 なぜメモリー故障の際に2号機に切り替わらなかったのか、今後検証を進める。 (日経新聞より [nikkei.com])
とのことです。 異常処理のテストをどこまでやるかというのはなかなか難問で、 実際に機器を故障させてテストをするというケースは少ないのではないでしょうか。
そう言や、昔、担当した仕事で、テスト中にデータバックアップ用の磁気テープに不良品が混ってる事が発覚。その時、関係者の1人が一言、 「返品するな。データバックアップ失敗のケースの運用テストに使う」
富士通に責任はない、と話してたけど、ちょっと風向きが変わるのかな?重過失ではないにしても、テストが充分ではなかった、となるのもやむなしなような。
OSは生きていて、ハートビートは返ってくるので生きていると思ったら、肝心のディスク周りがハングアップっていうことかな?と思っていたら、故障した1号機は自分が故障していて切り替えが必要ってことは自覚(?)していたらしい。ただ説明図を見ても「切り替え用設定値」ってなんの値だろう?とか「設定された値では切り替えができず」ってどういうことだろう、故障は検知したのに、その設定値によっては故障と見なさないのか?と疑問が湧いてしまい、かえってモヤモヤ…
その設定値のオン・オフで実際にバックアップに切り替えるかを判断するような印象を受けます。
デフォルトはどっちだ!?意図的に無効にしたのか、有効にするのを忘れたのか。デフォルトでメモリ障害だけ切り替わらない設定は変な気がする。そんな単純な話ではなくて、様々な設定の組み合わせで、結果的にメモリ障害だけ切り替わらなくなってしまっていたとかかな?
メモリのSEUによる好ましくないフェイルオーバーを嫌った可能性は?
オン・オフだけじゃなくて、0:オフ、1:本番用、2:テストA、3:テストB、…、みたいな
故障発見時の動作設定1.自動2.担当者の判断が必要(誰でもいいので切り替えOKボタンを押す)3.責任者の判断が必要(加えて、パスワード入力が必要)4.社長判断が必要(加えて、稟議書番号入力が必要:決済済みかの判断はネットワークで行う)
デフォルトは4番
いや、メモリ故障のアラームパターンを登録してなかったって話だろうエラーレベルだけで切り替える訳じゃないのは判らんでもない
何でもかんでも登録してたら今度は誤検知のリスクが上がるしな
異常処理のテストをどこまでやるかというのはなかなか難問で、
実際に機器を故障させてテストをするというケースは少ないのではないでしょうか。
1日に3兆円の取引をするシステムなんだからいろんなテストをやっても全然ペイできると思うんだけどなしかも24時間運用ってわけでもないし
テスト自体はやることに超したことはないですが、小規模なシステムならともかく大規模なシステムで網羅的にやるのは不可能に近いような。特に今回みたくハードウェアに起因するようなものの場合、そもそもそれって再現させられるの……?って話もありますしね。
なので、障害の早期検知と対応の迅速化とか影響範囲の最小化が方向性としてはとるべき道なのかなとも思いますね。
ただ、今回の件の場合どの時間までに復旧していれば全日取引不能にならなかったのかわかりませんが……。
実機に余裕があればできるけど客先のだけだったらシミュレーションで済ますのかも。設定値を変更してテストして元に戻すのを忘れたとか…ナンテ
そうそう、異常処理(特に原発や自衛隊の演習)のテスト・訓練をやると騒ぎ捲る連中がこの国には多いですから。
原発に関しては「原発は安全です。事故は起きません」って言って建てたヤツが悪いよね「きわめて低い確率で事故が起きますが、その事故の規模を小さくするために訓練をします」って言えなくなったのは建てたヤツの責任で会って騒ぎまくる連中は悪くないよ
実際に騒ぐ人がいなければそれはそれで対策立てるのスルーするに決まってるじゃん。
良く騒ぐ奴がいるから事故ケースの想定を立てられなかったって賢しらに宣うやつがいるけど、事故ケースを想定して対応するより「起きない」って権力使って押し切った方が遥かに楽で安上がりだからそういう選択をしただけであって、決して逆じゃねえよな。
だってシステムに異常はありえないのが前提ですから。可能とか不可能とかじゃなくて「絶対に異常はおきない。100%完全である」のが前提じゃないと認められない。
「異常処理の手順があるということは、異常がある可能性がわかっているということだから、納品前に治せ」ってのがまかり通るんですぜ。だから嘘でも「異常はおきません」って言うしかない。言わなきゃ永遠に終わらない。
富士通はどちらかというと、Xステップのコードだったらx件のバグがあるはずだ。テストでy件しかバグが見つかっていないということはテストが不十分だということだ。再テストせよ! という会社ですが。
だから故意に発見しやすいバグを入れておくそうだ。故意に総合テストでしか見つからない設定値の入れ替えの混在ってのはやったことがある。テストは外注だったので正常に行われているか確認する為だったのだが、納品前には忘れていたとか知られちゃいけない事実だ。
件数水増しで入れるのはあかんけど、意図的にバグを入れてテストでの検出率から潜在バグ数を推定するってーのは教科書的には定番よ?どっちの話かによって扱いはまるっと変わる。# けど忘れてたってことは駄目な方の二乗っぽいな……
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
原因 (スコア:4, 興味深い)
とのことです。
異常処理のテストをどこまでやるかというのはなかなか難問で、
実際に機器を故障させてテストをするというケースは少ないのではないでしょうか。
Re:原因 (スコア:5, 興味深い)
そう言や、昔、担当した仕事で、テスト中にデータバックアップ用の磁気テープに不良品が混ってる事が発覚。その時、関係者の1人が一言、
「返品するな。データバックアップ失敗のケースの運用テストに使う」
Re:原因 (スコア:2)
富士通に責任はない、と話してたけど、ちょっと風向きが変わるのかな?
重過失ではないにしても、テストが充分ではなかった、となるのもやむなしなような。
Re:原因 (スコア:1)
OSは生きていて、ハートビートは返ってくるので生きていると思ったら、肝心のディスク周りがハングアップっていうことかな?と思っていたら、故障した1号機は自分が故障していて切り替えが必要ってことは自覚(?)していたらしい。
ただ説明図を見ても「切り替え用設定値」ってなんの値だろう?とか「設定された値では切り替えができず」ってどういうことだろう、故障は検知したのに、その設定値によっては故障と見なさないのか?と疑問が湧いてしまい、かえってモヤモヤ…
Re: (スコア:0)
その設定値のオン・オフで実際にバックアップに切り替えるかを
判断するような印象を受けます。
Re: (スコア:0)
デフォルトはどっちだ!?意図的に無効にしたのか、有効にするのを忘れたのか。
デフォルトでメモリ障害だけ切り替わらない設定は変な気がする。
そんな単純な話ではなくて、様々な設定の組み合わせで、結果的にメモリ障害だけ切り替わらなくなってしまっていたとかかな?
Re: (スコア:0)
メモリのSEUによる好ましくないフェイルオーバーを嫌った可能性は?
Re: (スコア:0)
オン・オフだけじゃなくて、0:オフ、1:本番用、2:テストA、3:テストB、…、みたいな
Re: (スコア:0)
故障発見時の動作設定
1.自動
2.担当者の判断が必要(誰でもいいので切り替えOKボタンを押す)
3.責任者の判断が必要(加えて、パスワード入力が必要)
4.社長判断が必要(加えて、稟議書番号入力が必要:決済済みかの判断はネットワークで行う)
デフォルトは4番
Re: (スコア:0)
いや、メモリ故障のアラームパターンを登録してなかったって話だろう
エラーレベルだけで切り替える訳じゃないのは判らんでもない
Re: (スコア:0)
何でもかんでも登録してたら今度は誤検知のリスクが上がるしな
それはそれでわかるんだが (スコア:0)
異常処理のテストをどこまでやるかというのはなかなか難問で、
実際に機器を故障させてテストをするというケースは少ないのではないでしょうか。
1日に3兆円の取引をするシステムなんだからいろんなテストをやっても全然ペイできると思うんだけどな
しかも24時間運用ってわけでもないし
Re:それはそれでわかるんだが (スコア:1)
テスト自体はやることに超したことはないですが、小規模なシステムならともかく
大規模なシステムで網羅的にやるのは不可能に近いような。
特に今回みたくハードウェアに起因するようなものの場合、そもそもそれって
再現させられるの……?って話もありますしね。
なので、障害の早期検知と対応の迅速化とか影響範囲の最小化が方向性としては
とるべき道なのかなとも思いますね。
ただ、今回の件の場合どの時間までに復旧していれば全日取引不能にならなかった
のかわかりませんが……。
Re: (スコア:0)
実機に余裕があればできるけど客先のだけだったらシミュレーションで済ますのかも。
設定値を変更してテストして元に戻すのを忘れたとか…ナンテ
Re:原因 (スコア:3)
異常処理のテストをどこまでやるかというのはなかなか難問で、
そうそう、異常処理(特に原発や自衛隊の演習)のテスト・訓練をやると騒ぎ捲る連中がこの国には多いですから。
原発に関しては「原発は安全です。事故は起きません」って言って建てたヤツが悪いよね
「きわめて低い確率で事故が起きますが、その事故の規模を小さくするために訓練をします」って言えなくなったのは建てたヤツの責任で会って騒ぎまくる連中は悪くないよ
Re: (スコア:0)
実際に騒ぐ人がいなければそれはそれで対策立てるのスルーするに決まってるじゃん。
良く騒ぐ奴がいるから事故ケースの想定を立てられなかったって賢しらに宣うやつがいるけど、
事故ケースを想定して対応するより「起きない」って権力使って押し切った方が遥かに楽で安上がりだから
そういう選択をしただけであって、決して逆じゃねえよな。
Re: (スコア:0, オフトピック)
だってシステムに異常はありえないのが前提ですから。
可能とか不可能とかじゃなくて「絶対に異常はおきない。100%完全である」のが前提じゃないと認められない。
「異常処理の手順があるということは、異常がある可能性がわかっているということだから、納品前に治せ」ってのがまかり通るんですぜ。
だから嘘でも「異常はおきません」って言うしかない。言わなきゃ永遠に終わらない。
Re: (スコア:0)
富士通はどちらかというと、Xステップのコードだったらx件のバグがあるはずだ。
テストでy件しかバグが見つかっていないということはテストが不十分だということだ。再テストせよ! という会社ですが。
Re: (スコア:0)
だから故意に発見しやすいバグを入れておくそうだ。
故意に総合テストでしか見つからない設定値の入れ替えの混在ってのはやったことがある。
テストは外注だったので正常に行われているか確認する為だったのだが、納品前には忘れていたとか知られちゃいけない事実だ。
Re: (スコア:0)
件数水増しで入れるのはあかんけど、意図的にバグを入れてテストでの検出率から潜在バグ数を推定するってーのは教科書的には定番よ?
どっちの話かによって扱いはまるっと変わる。
# けど忘れてたってことは駄目な方の二乗っぽいな……