207Picks
Pick に失敗しました

人気 Picker
製品不具合かもしれないと思っていましたが、設定値問題でした。このレベルの機器設定は、システム毎に人が機器の設定をする以上避けられないだろう、というのが個人的な感想です。クラウドのマネージドサービスなら、インフラ側は一律同じ設定、ユーザ側はGUI等を使って分かりやすく構成を組めますから、このような基幹系システムも人手の設定を減らせる構成にしていくべきだと思います。

短期間に重厚長大なドキュメントをプロジェクト毎に大人数で作成し、信頼性要件に従って個別カスタマイズした構成を深く理解した少数の人間が机上でレビューするしかないわけです。
ほんとにこんなミスが?という気がするかもしれませんが、350ものサーバとそれに付随する機器、その中に入るミドルウェアの全設定がデフォルト値を含めると一体どれほどの数になるか、それが数人の少数の人間に委ねられていると思うと、想像を絶します。(もちろんミスはミスなのでしっかりと振り返り、横展開や再発防止が必要でしょうが。)

特にハード障害時のみに効力を発する設定値はテストすることが事実上不可能ですから、このような開発スタイルを続ける限りはヒューマンエラーが一つ二つは埋もれていることを前提とし、柔軟に対応できる業務設計も望まれます。
富士通さんはいろんな部品を購入してディスク装置を作っていらっしゃるのでしょうし、東証さん側が責任を負うべき使用環境もあるでしょうから、詳細に調査して原因究明しないと本当のところ誰の責任が一番重いか微妙なところがあるようにも感じていたのだけれど・・・ 「相場情報を伝えるシステムを支える一部装置のメモリーが故障した際に、予備のディスクに自動で切り替える設定になっていなかった」、「制御機構に設定されていた数値(パラメーター)では、ディスク内のメモリーが故障した際に、予備のディスクに自動で切り替わらないようになっていた」というのは本当か (@_@;エーッ 
「売買をなぜ終日停止したのかという点も問題になっている」とありますが、システムのテストに加え、このシステムが停止したときのBCPはどう定められていたものか。そこに停止と書いてあったなら、それはそれで正しい判断かと思います。もし想定外ということであったなら、管理が甘いと言われて仕方ないのかも。どこかの企業が社内で使うシステムならいざ知らず、壊れたら世界の取引が止まるシステムでいくらなんでもそれはないだろうと素人ながら思います。記事にはそのように書いてあるけれど、未だ半信半疑です (^^;
恐らくですが。
ストレージ装置の書込みキャッシュメモリ不良かと思われます。

キャッシュメモリが正常なら、キャッシュメモリへの書込み処理完了で完了応答(ライトバック)するのでパフォーマンスが高い。

キャッシュメモリがエラーだとライトスルー、SSD又はHDDへ書込み処理完了してから完了応答するので、パフォーマンスが著しく低下する。

ただ、通常ならライトスルーではストレージそのものの故障とは見なさないことが多い。パフォーマンスが落ちてもストレージとして機能している為。

むしろ故障と判断してストレージが頻繁に切替る事によるパフォーマンス低下を恐れることの方が多い。(切替は単純ではありませんから)

なもんで、一般的な認識としては悪い設定と言うこともない。

今回は既に結構なトランザクションがあり、パフォーマンスが足りない状況となったのでしょう。

東証のシステムとしてその運用が適切だったのかどうかはなんとも言えませんが、シビれます。
トラブルが起こった後、終日取引を遮断したのは英断だと思います。1日なくても実はそこまで困りません。むしろ保身のために動かして大混乱に陥るよりはよほどマシだと思います。
ただ、個人的にふに落ちないのは擁護論が強いこと。説明資料を見る限りもっと事前にやれることはあったんじゃないかと思います。全て◎、ではないと思います。
むしろ記者会見でトップマネジメントが役割を「一部」果たしただけです。保身に走らなかったことは元証券マンとして嬉しいのですが。
まぁしかし世界の証券取引所が結構な割合で止まってることを考えると日本は相当頑張ってきたんじゃないですかね
そのクオリティを落とすまいと邁進する姿は誇らしい
5日に行われた東証の発表で今回の問題となった「共有ディスク装置」の内部について、正常に動作しているかメインと予備機がお互いに監視する装置が、メモリー故障に反応しない設定値になっていたことが発表されました。事前にテストはしていたそうですが、メモリー単体の故障についてのテストは物理的に困難とのことで行っていた無かったそうです。設定ミスだったのかは「調査中」のためはっきりしていません。以下、東証のリリースです。https://www.jpx.co.jp/corporate/news/news-releases/0060/20201005-01.html

今回の障害の発生の仕方について、レアケースなためBCPプランとして、証券社に通知していた中の想定にはなかった様子。当日中の復旧はこうした点からも証券会社ごとに対応できるかどうかが分かれ、不平等や混乱を生むことから無理だったとのこと。今回の件を回避するためにはこうしたアローヘッド側の再起動で、既にマッチングしてしまった注文がリセットになるというプランの想定を証券会社に伝えて、その際の対応に対応してもらう必要があります。東証に問題があったとしたならこうしたプランがなく、半日稼働に持ち込めなかったこと。


金曜日の記者会見の内容についてのオリジナル記事はこちらです。(記者のITリテラシーの不足について批判の声も上がっていますので、コメント欄含めてお読み下さい)
https://newspicks.com/news/5267902/
「相場情報を伝えるシステムを支える一部装置のメモリーが故障した際に、予備のディスクに自動で切り替える設定になっていなかった」
はじめてこの情報が出た。
たぶん東証は初めから問題を掴んでいた。
なんで公表しなかったのか。
記者配布資料には、ディスク装置は両現用と書いてあったから、バックアップではなく故障を検知したらシステムから切り離す仕組みだと思うんだけど、未だにバックアップと記事に書くのはなぜだろう?
もしも自分がインタビューされたなら。
「テスト内容に不足があるとは感じられない。いわゆる想定外というものだろう。そして考えられる原因はスプリットブレインではないか。」みたいなことを言う。コロナのクルーズ船の時も「レッドゾーン」というまあ素人でも分かるけどそれまで知らなかった言葉を知って知識が増した気がして安心感が出た。人はこういう場合に何かにすがりたくなる。この件は一般的なニュースではないけどもしそういう話題だったとしたらワイドショーあたりがフリップ仕立てて「スプリットブレインとは?」みたいなことを言うのだろう。ちなみにスプリットブレインとは1号機2号機のように障害発生時に切り替わるよう構築したシステムにおいて1号機に障害が起きて切り替わりかけるも復活してきてしまい両機が生きている状態になること。本当に両機が生きてるとどっちの方を稼働系と見ていいか分からなくなり深刻な障害となる。(例えば一続きのデータを両機にバラバラに書き込んでしまいそれによってAというサーバが処理を終えたという書き込みをしているのにBというサーバ側まだ書かれてない側のディスクを読んでまだだと思って再実行してしまうとか)
技術的には東証が富士通にどこまでの仕様を求めていたのか(あと、管理運営者として妥当だったのか)、もしくは富士通側の設計ミスなのかがきになるところ。