【東証システムトラブル】障害が起きた機器からバックアップへの切り替えが正常に行われず [記憶たどり。★]

1 ：記憶たどり。 ★：2020/10/01(木) 14:59:44.13 ID:sXjXRHtC9.net

https://this.kiji.is/684278170947372129?c=39550187727945729

東京証券取引所は、障害が起きた機器からバックアップへの切り替えが正常に行われなかったため、
相場情報の配信ができなくなったと発表した。

461 ：不要不急の名無しさん：2020/10/05(月) 21:00:52.63 ID:+U3YF6b70.net

https://www.itmedia.co.jp/business/articles/2010/05/news124.html
この図の1号機、2号機は２つのコントローラでは無く別々の装置と読み取れる。
その場合故障装置の切り替えはサーバの管理かと思ったがそうでもないのか。
ストレージ自体がクラスタか何かを組んでいて
ストレージ側で切り離しも管理していたのかな。
ともあれ、これが富士通の納入なら責任は富士通だろ。

462 ：不要不急の名無しさん：2020/10/06(火) 02:16:05.44 ID:E/CBKAwu0.net

え！
設定ミスって
仏像作って魂入れずってことか
バックアップシステム造ったが怖くて試験をしなかった
おいおい、最初から作っていなかったんではないのこれ

記者会見した東証の田村康彦トレーディングシステム部長は「メモリーの故障を
想定したテストは難しかった」として、テストを実施していなかったことを認めた。
https://www.yomiuri.co.jp/economy/20201005-OYT1T50186/

463 ：不要不急の名無しさん：2020/10/06(火) 02:19:07.41 ID:FVpFKpdj0.net

そりゃ障害が起きた機器は正常に働かないだろ。当たり前だ

464 ：不要不急の名無しさん：2020/10/06(火) 02:38:06.47 ID:/DdGx35r0.net

想定していなかったか
アホがプログラムしたか

465 ：不要不急の名無しさん：2020/10/06(火) 03:54:35.30 ID:+5KM0i2c0.net

たぶんね
相互監視している装置の受信・送信ICが
常に自分や相手が生きている夢をみるような壊れかたの時の試験もしていないと思うよ
あとね
相手の故障を検知したときに
切り替え開始信号を送る部分がコミュ症になった時の試験もしていないと思うよ
それにね
切り替えている最中に
もう一方の方もほぼ同時に(同じ原因で)故障するような悪夢は想定していないと思うよ

466 ：不要不急の名無しさん：2020/10/06(火) 04:47:40.93 ID:60TtfrEt0.net

「テストが難しかった」( ﾟдﾟ)( ﾟдﾟ)( ﾟдﾟ)( ﾟдﾟ)( ﾟдﾟ)
富士通よくそれで納品したな。
JPXよくそれで検収したな。
十人単位で解職されるし、
中には懲戒解雇扱いの人も出て来るケース。
レベルが3階層ほど低かった。

467 ：不要不急の名無しさん：2020/10/06(火) 04:58:17.89 ID:J+0DZLQ10.net

>>466
まぁ難しいのは確かではある
だから今回のような障害を想定できたとしても
メンドクサイと思ってやらないやつもいる
本格的に頭がどうかしてる

468 ：不要不急の名無しさん：2020/10/06(火) 05:05:57.93 ID:60TtfrEt0.net

>>467
もちろんわかる、めっちゃ面倒くさい。
でも構築直後に待機系への切り替えのテストは
「必ず」やるよ。
少なくとも俺が居た組織は何パターンか切り替えテストはやって来た。
だからこそ腹立たしい。

469 ：不要不急の名無しさん：2020/10/06(火) 05:16:01.04 ID:Ohsw2Pmm0.net

「テストが難しかった」( ﾟдﾟ)( ﾟдﾟ)( ﾟдﾟ)( ﾟдﾟ)( ﾟдﾟ)

三菱重工「富士通はそんな仕事してるのか？」

470 ：不要不急の名無しさん：2020/10/06(火) 05:48:25.73 ID:BAATIzss0.net

設定ミスってことにして過去の構築メンバーのせいにするってよくある話
専門家がみたら通常あり得ないってすぐわかる
多分富士通のファームのバグだよ

471 ：不要不急の名無しさん：2020/10/06(火) 05:50:34.90 ID:SganZkzd0.net

マトモな技術者の賃金を下げ続けたり解雇したりで経営努力して来た結果技術力のないジャップランド完成有難う菅自民党

472 ：不要不急の名無しさん：2020/10/06(火) 05:54:26.10 ID:WLX9FgTV0.net

コレだからジャップランドは何時まで経っても韓国には勝てないんだよwwwwww

473 ：不要不急の名無しさん：2020/10/06(火) 05:56:04.43 ID:wn5XAX1KO.net

プログラムの中にあるエラーを全て出せって言われてたけどなあ。

474 ：不要不急の名無しさん：2020/10/06(火) 05:56:49.53 ID:fgtDJgoN0.net

>>1
ホットスタンバイがマトモに動作すると信じている人間は馬鹿

475 ：不要不急の名無しさん：2020/10/06(火) 06:00:08.93 ID:BAATIzss0.net

東証は富士通に損害賠償請求しない？
そりゃ当たり前だろテメエラ痛くもかゆくもねえんだから

476 ：不要不急の名無しさん：2020/10/06(火) 06:12:10.58 ID:7rR3CINo0.net

韓国にゴメンナサイしてプログラム作り直して貰いなよ

477 ：不要不急の名無しさん：2020/10/06(火) 06:12:20.43 ID:BFitnjoW0.net

>>432
電車やクルマは止まるのがセーフだけど
ドローンや東証はアウト

478 ：不要不急の名無しさん：2020/10/06(火) 06:14:05.41 ID:ROMCVd9T0.net

>>470
ファームウェアのバグなら
富士通の責任は限定的になる。
(共有ディスクコントローラーのハードバグは専業ベンダの範疇)
運用前テストの非実施は完全なベンダーの過失。
後者の方が数段悪質。

479 ：不要不急の名無しさん：2020/10/06(火) 06:16:34.11 ID:ROMCVd9T0.net

>>475
運用側の東証が「テストをしていないのに検収」したら
重大な過失。
裁判しても50：50ぐらいになる可能性すらある。

480 ：不要不急の名無しさん：2020/10/06(火) 06:21:48.35 ID:ROMCVd9T0.net

>>462
インフラの構築を富士通とニュータニックスで変に分業させたから、障害回復テストのシナリオと境界分岐点が複雑になって、結局3社が暗黙の了解でテストを未実施にした感じだな。

この手の奴って、発注元が相当なリーダーシップと網羅すべきテストシナリオのアイデア出しをやりきる覚悟が無いと、
他愛の無いはずの単発ハード障害が命取りになる。

481 ：不要不急の名無しさん：2020/10/06(火) 06:25:41.42 ID:T1JMMvl40.net

今回は正常性チェックでは正常動作しているけど実際には故障しているという中途半端な故障パターンだから
システム側で防ぐのは極めて困難

482 ：不要不急の名無しさん：2020/10/06(火) 06:32:12.02 ID:ROMCVd9T0.net

>>481
その場合は正常性チェックを無効化するギミックを入れておく。
今回はテスト時のシナリオ選定で判っても放置していたと取れる。
手抜きの一言。

483 ：不要不急の名無しさん：2020/10/06(火) 06:54:05.34 ID:BAATIzss0.net

まあ経験者なら自動切換え設定してませんでしたなんて言う公式発表うのみにする奴いないってこと

484 ：不要不急の名無しさん：2020/10/06(火) 08:26:47.17 ID:E/CBKAwu0.net

>>482
それもうっかりではなくうっかりを装った確信的な手抜きのようだね
実際フェールアウトを実施しようとしたら更なる悪化も懸念されたろうから
今回、設定したと言ってたがテストもせず心配だよね
まあ今回のように取引サービス開始前スタートの環境造りの時点でおかしくなる事は想定
してなかったのではと思うが

485 ：不要不急の名無しさん：2020/10/06(火) 08:54:36.20 ID:1Z9W1gVr0.net

機器からバッタが出たのかと思った

486 ：不要不急の名無しさん：2020/10/06(火) 08:54:37.71 ID:m6FzBbvS0.net

海外の証券取引所もシステム障害による停止は普通にあるけどな

487 ：不要不急の名無しさん：2020/10/06(火) 08:57:43.74 ID:QfZHz15h0.net

手順を間違えたんだろ
通信機器を扱えない老人にさせるな

488 ：不要不急の名無しさん：2020/10/06(火) 09:02:57.79 ID:E/n2EpPe0.net

パラメタ設定ミスの詳細は不明だが
障害状態を正確に拾えなかったってことかな?

大規模システムだから当然障害テストも徹底的に計画して
やっていただろうと想像するが
ハード障害を想定した疑似テストは本番事象の通りには
できないものは多い（今回のメモリ障害のように）

問題の本質は 共有ディスク切替不可を認識した後
なぜ数時間後の再開ができなかったのか?

ここの原因究明と再開手順を確立しないと
また別の障害をトリガーに長時間停止が繰り返される

489 ：不要不急の名無しさん：2020/10/06(火) 09:05:23.96 ID:/AtjPWqg0.net

経験上フェールアウトの仕組みって作ってもあとあとのこと考えて動かさない場合のが多かったなー。
また正系に戻して他シスへのファイル送信とかの確認とかで手間かかるくらいなら1日ぐらい止めちゃえみたいな。

490 ：不要不急の名無しさん：2020/10/06(火) 09:11:24.15 ID:ROMCVd9T0.net

>>488
数時間後にでも再開出来なかったのは、
「注文受けキューサーバに溜まっていた未処理の売買注文を捌きつつ新規の売買注文を受け付けられないと判断した」との事。
また共有ディスクの復旧のためには機器再起動が必要だが、
その場合は注文受けキューサーバ上の未処理の売買注文のデータが消えるとも言っていた。
つまり「障害発生時に即時にフェールオーバーしない限り、また同じ事態が起こる」という事。
更に「ジャーナルデータ」を別の媒体に同時記録もしていなかったとも言える。

…色々な意味で「詰んでいるプロジェクト」
「データ保持」関係のロジック、総見直し必須だな、こりゃ。

491 ：不要不急の名無しさん：2020/10/06(火) 09:23:17.65 ID:mUZq41dj0.net

>>490
まぁそこに関しちゃ障害や再起動なんだしデータがロストするのは当然だし当たり前だからなぁ
つまりはアプリ側がそれを見越した作りにしないといけないんだわ
アプリ開発陣がわかってないのがいけない

492 ：不要不急の名無しさん：2020/10/06(火) 09:51:12.45 ID:izYKY9nL0.net

F1と一緒やな

493 ：不要不急の名無しさん：2020/10/06(火) 09:55:37.31 ID:RchLDHPn0.net

>>491
ここで問題なのが「今更アプリ仕様を変えられない」という事。やったとしてもジャーナルデータの垂れ流しが限界。
そうなると「アプリに渡す前の下位層」で全部カバーする必要がある。
滅茶苦茶ツギハギのあるシステムになるんだろうなぁ。
海外展開なんて夢の又夢だわ。

494 ：不要不急の名無しさん：2020/10/06(火) 09:56:09.50 ID:E/CBKAwu0.net

９時〜１５時間での取引データ処理については、ある程度
瞬断の切り替え前後でデータの確認は出来る設計にはしてあるとは思うが、
今回のようにバッチ処理系の途中らしき処理中での瞬断前後の
正常処理確認は不定形だし即時に判断し継続ＯＫとすることは難しいだろうね

495 ：不要不急の名無しさん：2020/10/06(火) 09:58:09.56 ID:RchLDHPn0.net

>>494
バッチ処理の各段階でリランポイントとその方法は
考えておくべきだと思うけどな。
運用担当になったときは真っ先にそれ作ったわ。
でないと怖くて仕方ない。

496 ：不要不急の名無しさん：2020/10/06(火) 09:59:48.21 ID:es0q/UaN0.net

ボロっ

497 ：不要不急の名無しさん：2020/10/06(火) 10:01:01.97 ID:qfGpFyCQ0.net

>>490
東証のシステムは即時にフェールオーバーすんのが前提だよ
異常系テストの不備であかんかったと言うのはお粗末だが

498 ：不要不急の名無しさん：2020/10/06(火) 10:01:26.83 ID:es0q/UaN0.net

まあそういうことにしておいてあげよう
ところでドコモのＴＯＢ買い付けはうまくいってるのか？

499 ：不要不急の名無しさん：2020/10/06(火) 10:12:05.21 ID:jYsS7oGu0.net

>>494
サーバもロードバランサでクラスタ化されてるし
バックエンドのDBもクラスタ化されてるのに？

500 ：不要不急の名無しさん：2020/10/06(火) 11:17:36.70 ID:VSPDYK+J0.net

>>483
そんなことはない。

「自動切換え設定してませんでした」ではなくメモリ故障が
発生した際に他系に切り替わる設定になっていませんでした
という事では？

https://www.yomiuri.co.jp/economy/20201005-OYT1T50186/

メモリでアンコレクタブルエラーが発生した時の挙動と
クラスター切り替えの考え方を理解していたら、シングル構成時と
マルチクラスター構成の場合で挙動を変える設定変更が必要かも知れないと
想定はできる。

501 ：不要不急の名無しさん：2020/10/06(火) 11:18:20.28 ID:VSPDYK+J0.net

つづき

メモリのミラーリング機能があるかどうかにもよりますが、
一般的に訂正不可能なメモリエラーが予兆もなく発生すると
故障部位をすぐに切り離すのではなく次のような順序で切り離す。

エラー検知⇒パニックリブート⇒POST診断⇒故障部位の切り離し⇒OS(ファーム)の起動。
OSやファームウェアは故障部位が切り離された状態で正常に立ち上がる。

シングル構成の場合はこれでも問題はない。

訂正不可能なメモリエラーが発生した際は、OSやファームウェアは
正常に動作する事が困難になるので、タイミングによっては、他系に
通知する前にパニックが発生する。

つまり、他系や監視装置にエラーを通知するタイミングは再起動後。

502 ：不要不急の名無しさん：2020/10/06(火) 11:19:44.79 ID:VSPDYK+J0.net

つづき

両系で死活確認をしているのでは？と思うかもしれないが、
一般的に他系が高負荷状態などの影響で誤検知する可能性も
ある為、死活確認はリアルタイムで行っているのではなく、
数十秒から数分程度の間隔で行っている。

以下は推測ですが、

マルチクラスタ構成の場合、パニックリブートで自動で立ちあがて
しまうと、もう片方(監視側)で死活確認の異常を検知できなかったり、
再起動後の整合性が保証されない為、テイクオーバー(クラスター切り替え)が
抑止される可能性があります。

このようなことから、マルチクラスタ構成の場合、パニックリブートで
自動起動しないという設定があってもおかしくない。

メモリ故障で直接切り替えるのではなく、死活確認の異常検知で
テイクオーバー(クラスター切り替え)を実行するようにするという事。

503 ：不要不急の名無しさん：2020/10/06(火) 11:27:01.30 ID:ka5ZhufY0.net

ハード障害で正常に待機系へ切り替わらなかった、ってよくある話だよな

504 ：不要不急の名無しさん：2020/10/06(火) 11:31:35.28 ID:GjJkrAQt0.net

>>490
通販サイトの注文や銀行ATMの入出金じゃ無いんだから。
注文を数時間もちこして約定するなんてどんな嫌がらせだよw

505 ：不要不急の名無しさん：2020/10/06(火) 11:42:52.92 ID:aRNs80cP0.net

某メーカーの機器も動かなくなって原因何だ→わかりませんを半年やって結局配線間違いで
何で間違えたって聞いたら下請に投げてたからって言ってたから
これも同じようなものだろう
いい加減特殊な例を除いて下請システムやめろ

506 ：不要不急の名無しさん：2020/10/06(火) 11:56:36.15 ID:T1JMMvl40.net

ハード障害が起きたのに監視系にはアラームが出てなかったって時点でどうしようもない

507 ：不要不急の名無しさん：2020/10/06(火) 13:08:24.46 ID:mUZq41dj0.net

>>506
監視に必要な条件を盛り込んでなかったんだろ
「err」を拾えば全て網羅できるとか思っちゃってた

508 ：不要不急の名無しさん：2020/10/06(火) 13:36:37.16 ID:hw6U0pRW0.net

>>507
普通ストレージにはストレージ用の監視機能ツールがあって、それで検知する
それで検出できなかったのは叩かれる要素

509 ：不要不急の名無しさん：2020/10/06(火) 13:40:44.04 ID:MBPnS6520.net

>>508
制御装置の設定の部分だな
設定が富士通所管かどうかは分からん

510 ：不要不急の名無しさん：2020/10/06(火) 14:03:42.31 ID:E/CBKAwu0.net

>>509
４日に設定したという
という事は２日は設定しないままの従来の運転だった訳だ