自動ニュース作成G
東証、障害の原因を特定 設定値に不備、切り替え失敗
https://www.itmedia.co.jp/business/articles/2010/05/news124.html
2020-10-06 08:08:24
>東京証券取引所は10月5日、1日に発生した株式売買システム「arrowhead」の障害の原因を発表した。共有ディスク装置1号機に搭載されたメモリが故障した場合、バックアップ(2号機)へと自動的に切り替わるはずだったが、設定値に不備があり、機能しなかったという。
>東証は「障害を引き起こした直接的な原因を特定できたため、システム面での対応を実施した」としている。
理論上はできるように設計していても、ハード故障のテストは難しいんだろうな
・システム障害の原因はハード故障ではなくて設定ミスという運用がって事になるのかね
・リンク先の絵を見ると、死活監視をping(的な疎通)で行ってて、事前テストで疎通ができなくなった時点でフェイルオーバーすることは確認済だったけど、今回のようなメモリ障害の場合はpingなどは正常に返すことがあるから、相手側の故障を検知できずフェイルオーバーしなかったのかな?と、エスパー。
・(続き)これを解決するためにはメモリ障害などの部材の障害の場合はOSごと自殺させる必要があったけど、そういう設定が漏れてたのかも?(あくまで想像だけど)
・#2 そんな感じだと思う。完全に死ぬと切り替えられても、中途半端に生きてる場合は難しいよな。常に自己診断して、不具合があったら自殺する(回線から切り離す)みたいな事が可能になったら運用者は楽だな
・Daisy... Daisy... give me your answer do...
・#4 本体CPUで自己診断を行うのは制約がある(自分が狂ってるかも知れない)から、各社本体系とは独立して動作するサポートプロセッサチップでそれをやってると思う。NECならEXPRESSSCOPEエンジン、intelならvpro、富士通はリモートマネジメントコントローラかな?そのあたりのチップとの連携設定がまずかったのかも知れんね。
・とりあえずhttps://gnews.jp/20201005_172122
・部品の保護が働くとシステムがぶっ壊れるは、よく見かける。誰の何を何の為にどの様に保護するのか目的と優先順位が部品とシステムで一致してない。
・今回の場合、設定は富士通の責任(東証の運用には責任なし)ということかな。
・設定ミスって事はテストしてないんだから、同罪だろう。
・#9 記者会見で東証が自分達の責任って言っていたよ。
・外向けはそうだろうけど、中の役割分担でどっちがミスってたかはあるだろう。この話だと、東証は完全かはともかく仕様は決めていて、富士通側がその通りに実現できてなかったということかな。もっとも、検収して合格出してれば、やっぱり責任は発注側で、東証もそういう検証をできてなかったということよな。
・プログラミングの外注って一般的にはテストは元請けの仕事なん?
・プログラミング関係ないと思うよ・・