パスワードを忘れた? アカウント作成
14946652 story
お金

1日の東京証券取引所の障害、バックアップへの切り替え失敗は設定値のミス 55

ストーリー by nagazou
人的ミスだった 部門より
東京証券取引所は5日、1日に発生した取引停止障害の原因が判明したと発表した(JPXからのお知らせNHKITmedia)。

1日に取引不能に陥った原因は、共有ディスク装置の1台が故障、そのバックアップシステムへの切り替えがうまくいかなかったことが主因であると発表されている。今回の発表では、その切り替えがうまくいかなかった原因について、自動的にバックアップに切り替わるための切替え用設定値に指定されていなかったことが明らかになったとしている。つまり設定上の問題であった模様。なぜそうなったかについてはさらに原因を究明するとしている。
  • 原因 (スコア:4, 興味深い)

    by NOBAX (21937) on 2020年10月07日 14時33分 (#3902212)

    東証によると、1号機が何らかの理由でダウンした場合に2号機に自動で切り替わることは
    システム稼働前のテストで設計・開発した富士通とともに確認していた。
    しかし今回、障害の原因を調べたところ、メモリー故障を理由として1号機が機能不全となった場合に、
    2号機に自動で切り替わらないことが分かったという
    テストは富士通が主体となって実施しており、メモリーそのものを物理的に破壊するような実験はせず、
    「疑似的に1号機の機能を喪失させるテストを実施し、2号機に切り替わることは確認していた」
    なぜメモリー故障の際に2号機に切り替わらなかったのか、今後検証を進める。
    (日経新聞より [nikkei.com])

    とのことです。
    異常処理のテストをどこまでやるかというのはなかなか難問で、
    実際に機器を故障させてテストをするというケースは少ないのではないでしょうか。

    ここに返信
    • Re:原因 (スコア:5, 興味深い)

      by Takahiro_Chou (21972) on 2020年10月07日 14時54分 (#3902230) 日記

      そう言や、昔、担当した仕事で、テスト中にデータバックアップ用の磁気テープに不良品が混ってる事が発覚。その時、関係者の1人が一言、
      「返品するな。データバックアップ失敗のケースの運用テストに使う」

    • by hjmhjm (39921) on 2020年10月08日 19時46分 (#3903267)

      富士通に責任はない、と話してたけど、ちょっと風向きが変わるのかな?
      重過失ではないにしても、テストが充分ではなかった、となるのもやむなしなような。

    • by Anonymous Coward on 2020年10月07日 14時44分 (#3902224)

      OSは生きていて、ハートビートは返ってくるので生きていると思ったら、肝心のディスク周りがハングアップっていうことかな?と思っていたら、故障した1号機は自分が故障していて切り替えが必要ってことは自覚(?)していたらしい。
      ただ説明図を見ても「切り替え用設定値」ってなんの値だろう?とか「設定された値では切り替えができず」ってどういうことだろう、故障は検知したのに、その設定値によっては故障と見なさないのか?と疑問が湧いてしまい、かえってモヤモヤ…

      • by Anonymous Coward

        その設定値のオン・オフで実際にバックアップに切り替えるかを
        判断するような印象を受けます。

        • by Anonymous Coward

          デフォルトはどっちだ!?意図的に無効にしたのか、有効にするのを忘れたのか。
          デフォルトでメモリ障害だけ切り替わらない設定は変な気がする。
          そんな単純な話ではなくて、様々な設定の組み合わせで、結果的にメモリ障害だけ切り替わらなくなってしまっていたとかかな?

          • by Anonymous Coward

            メモリのSEUによる好ましくないフェイルオーバーを嫌った可能性は?

        • by Anonymous Coward

          オン・オフだけじゃなくて、0:オフ、1:本番用、2:テストA、3:テストB、…、みたいな

      • by Anonymous Coward

        故障発見時の動作設定
        1.自動
        2.担当者の判断が必要(誰でもいいので切り替えOKボタンを押す)
        3.責任者の判断が必要(加えて、パスワード入力が必要)
        4.社長判断が必要(加えて、稟議書番号入力が必要:決済済みかの判断はネットワークで行う)

        デフォルトは4番

      • by Anonymous Coward

        いや、メモリ故障のアラームパターンを登録してなかったって話だろう
        エラーレベルだけで切り替える訳じゃないのは判らんでもない

        • by Anonymous Coward

          何でもかんでも登録してたら今度は誤検知のリスクが上がるしな

    • 異常処理のテストをどこまでやるかというのはなかなか難問で、

      実際に機器を故障させてテストをするというケースは少ないのではないでしょうか。

      1日に3兆円の取引をするシステムなんだからいろんなテストをやっても全然ペイできると思うんだけどな
      しかも24時間運用ってわけでもないし

      • by Anonymous Coward on 2020年10月07日 17時03分 (#3902353)

        テスト自体はやることに超したことはないですが、小規模なシステムならともかく
        大規模なシステムで網羅的にやるのは不可能に近いような。
        特に今回みたくハードウェアに起因するようなものの場合、そもそもそれって
        再現させられるの……?って話もありますしね。

        なので、障害の早期検知と対応の迅速化とか影響範囲の最小化が方向性としては
        とるべき道なのかなとも思いますね。

        ただ、今回の件の場合どの時間までに復旧していれば全日取引不能にならなかった
        のかわかりませんが……。

    • by Anonymous Coward

      実機に余裕があればできるけど客先のだけだったらシミュレーションで済ますのかも。
      設定値を変更してテストして元に戻すのを忘れたとか…ナンテ

  • by Anonymous Coward on 2020年10月07日 14時50分 (#3902226)

    RAID装置上のコントローラに搭載されているメモリとRAID装置コントローラのHA制御部分の問題?

    それとも、その上にあるRAID装置が接続されているサーバ OS上で動作させているHA制御部分の問題?

    どっち?
    (JPXの説明みると前者っぽいけど)

    ここに返信
  • by Anonymous Coward on 2020年10月07日 15時11分 (#3902247)

    Q:証券取引が不能に陥った原因はなんですか?
    A:共有ディスク装置の1台が故障してバックアップシステムへの切り替えがうまくいかなかったからです

    Q:なぜ切り替えがうまくいかなかったのですか?
    A:自動的にバックアップに切り替わるための切替え用設定値に指定されていなかったからです

    Q:なぜ指定されていなかったのですか ← 今ここ

    最終的には「うっかりミスです」とか「すべて私の不徳の致すところです」とか「むしゃくしゃしてやった」とかのレベルまで追及を続けるんだろうか。

    ここに返信
    • Re:原因追及 (スコア:3, 参考になる)

      by Anonymous Coward on 2020年10月07日 16時01分 (#3902290)

      「不徳」はバッドエンド。

      正規ルートは
      Q: なぜ指定されていなかったのですか
      A: この文書の規定に従い、不要と判断しました

      Q: なぜその文書の規定では不要だったのですか
      A: 業界の常識、ビジネスリスク、経営判断を勘案し職責で不要と決めました。しかし今回必要と分かりました。 ←新しい知見

      それで解放される真ルートが
      「常識的には不要そうですが、過去の東証の事例からメモリ故障の検討が必要と思われます」「やっておこう」 → インシデント回避 な

      なぜなぜは「常識的に想定すべき可能性と諸手続きは全て行ったつもりだったが発生した事案」に対して
      「諸手続きは正しく行われたか?」「手続きは全て行ったなら、どういう予見不可能な理由で発生したのか?」という問いに答えるもの
      「めんどくせえな、あいつのうっかりミスだよ」「ハイハイ気を付けまーす」「むしゃくしゃして普段ならやらないことをやったんだ」は責任追及じゃない
      そのバッドエンドに逃げると何度でも世界大戦は起きるし欠陥車は炎上するしロケットは爆発するしシステム障害は起こる

    • by Anonymous Coward

      そりゃ追求しないといけないんじゃない?
      人的ミスならそれを防ぐ対策をせねばなるまい。

      • とはいえ、そっちは、やっちゃいけない系「なぜなぜ」な感じよね

        # 自分はあれ苦手なので、うまく捉えられてるかわからないが

        --
        M-FalconSky (暑いか寒い)
      • by Anonymous Coward

        まあ、チェック体制強化するってなるだろうな。

        顧客テスト肯定で修正プログラムの適用ミスが発生するたびに手順が増え、書類が増え、人が増え、
        それでも適用ミスはゼロにはならなくて、これ以上の対策は無理ですと顧客に頭下げたプロジェクトを思い出すな。

        • by Anonymous Coward

          分析が不完全、対策が不適切だから手間とミスがダブルで増えるというのはあるあるパターン

          • by Anonymous Coward

            特定のファームウェアのバージョンだとより酷い問題を引き起こすので、その設定を適用しないとなってたかもしれんし。
            分散システムだとよくある。

    • by Anonymous Coward

      結果的に設定値自動切り替えが行われない設定になっていたというだけで、そもそも「人的ミス」(設定ミス)なのかもまだよくわからないけど、

       「うっかりミスです」→うっかりミスしてしまうことになった原因を見つけて是正
       「すべて私の不徳の致すところです」→そうなってしまった原因を見つけて是正
       「むしゃくしゃしてやった」→ダブルチェックするとか、悪意を持ってやったのならセキュリティの問題でもあるからその辺の是正

      となるだけ。
      これは組織やプロジェクトの問題だから、一担当者のコメントは参考程度のもの

    • by Anonymous Coward

      Q:その設定を行った場合のリスクやデメリットは何が考えられますか?
      私がQ側だったらまずこうかなあ。

  • by Anonymous Coward on 2020年10月07日 15時14分 (#3902251)

    2台ともダメになってたら止めるしかないわけ?

    ここに返信
    • by hakikuma (47737) on 2020年10月07日 15時22分 (#3902255)

      証券取引所システムのバックアップが
      たった一系統しかないとは思えません。

      • by Anonymous Coward on 2020年10月07日 17時29分 (#3902382)

        プライマリセンタ2系統とセカンダリセンタ (機能縮小版) 2系統の構成で、プライマリセンタ1系統が故障したがプライマリセンタ2系統に切り替わらず、セカンダリセンタを使用する決定もしなかった。

        日本取引所グループのBCP [jpx.co.jp]には、「セカンダリセンタへ切り替える場合、売買・取引の再開は24時間以内を目標とするが、当日中の再開は行わない」と書かれている。
        当日中に原因箇所の特定・除去など再起動の目処が立たなかった場合は、翌日はセカンダリセンタで売買・取引を再開するつもりだったと考えられる。

        • by Anonymous Coward

          セカンダリセンタはコールドスタンバイで立ち上げも少々時間を要するとかも言ってたっけか。
          ホットスタンバイな2号機と無停止で交代できた場合は良しとして、
          それ以外は再開によるトラブル防止の為に状況分析と再開影響分析が優先されるんだろうね。

          今回も1号機直して午後から再開は可能だったけど、
          取引の都合上問題が起きそうなので避けた結果の一日停止だし。
          障害対応ルールは二次災害予防の観点でかなり慎重のようだ。

      • by Anonymous Coward

        取引データのバックアップはもっと強力だと思いますが、情報配信システムならこんなものでしょう。平日の9:30-11:30と12:30-15:00が取引時間で、何年かに一度は何かしら取引停止のトラブルがあります。そもそも365日24時間いつでも換金する必要のある資産を株式で保有するのは間違いでしょう。

    • by Anonymous Coward on 2020年10月07日 19時11分 (#3902497)

      それが気に入らないなら3重にするしかないですね。それでも気に入らないなら4に。それでも…。
      RAIDは何台で構成してあれば気が済みますか?っていうのと同じこと。
      絶対に止まらないシステムなど存在しない。隕石が落ちてきたら止まるし。
      どこで線を引くかの問題で、議論するならその線引きは妥当か、何故妥当と言えるのかという話になる。
      でも万人が納得するのはきっと不可能でしょうね。コストが妥当かという問題もあるからね。

    • by Anonymous Coward

      そうだよ

      # だから3台目と4台目と...N台目も買ってください

      • by Anonymous Coward

        そしてRAIDコントローラーが死亡。

    • by Anonymous Coward

      待機系の故障に気付かなくて障害が発生した瞬間に詰んでしまうのは稀によくある話。
      似たようなのにRAIDの2台目のHDDが壊れてやっと障害に気付いたが時既にお寿司というのがある。

      • by Anonymous Coward

        1台目の故障に気づいてても、予算無いから交換用HDDの購入はちょっとまってといわれてるうちに、2台目が無事死亡するケースもあるとか...

        • by Anonymous Coward

          一台目故障から交換再構築完了まで(場合によっては再構築開始前から)負荷が上昇するから、
          実は故障率が独立してなくて実際の冗長性は足りてない、とかもまま聞く話。

      • by Anonymous Coward

        RAIDって構成しているHDDが、

        同じスペック(多くの場合、同じメーカ製の同じ型番)で、
        製造時期が近くて(製造スロットも同じだったり、近かったり)、
        同じ筐体内で(周囲の温度条件同じ)、
        同じアクセス頻度で利用されているんだから、

        ひとつ逝ったら、他のも近いうちに逝っちゃうリスクは高いと
        思わなくちゃいけないですよね。

        • by Anonymous Coward

          NetAppやらEMCやらはそこらへんは少しは考えていて、
          ファームウェアを独自のものに変更してセクタ数等をアライメントした複数社・製造時期が近くはあるが別ロットのHDD/SSDを1セット内に搭載しています。
          なのでHDD/SSDに搭載するファームウェアで共通のやらかしがない限りはある程度ばらけるように調整して出荷しています。

          セットで届くのであまり機会がないかもしれませんが、スロットから外してみると面白いですよ。
          2シェルフぐらいだとHDDはWD/HGST/Seagateのうち2社になるパターンがやっぱり多いですが、
          1ラック以上の場合だと今その会社で取り扱っているストレージでの仕入れ元が揃い踏みすることもあります。

          • by Anonymous Coward
            > セットで届くのであまり機会がないかもしれませんが、スロットから外してみると面白いですよ。
            スロットから外すのは、納入されて開梱直後の電源を入れる前にして下さい。
            運用状態でいきなり外すと、故障と判断されCEが特殊な処理をしないと再使用できません。
            そういう装置はLANにつながり、Webインターフェースの管理ソフトが動作してます。
            スロットから外さずに、管理ソフト(運用管理担当者に相談して)で確認して下さい。
      • by Anonymous Coward

        以前、FTサーバで待機系のファイルシステムがReadOnlyになっていることに
        半年以上気付かなかったことがあった。
        アプリをバージョンアップしようとして初めて気付いたw

        稼働系が故障しなくてホント助かった…

  • by Anonymous Coward on 2020年10月07日 16時11分 (#3902297)

    見たくもないけど、稀によく見るのは497日問題踏んだ時とかかな。
    今もSNMPでの監視では497日過ぎると監視しなくなったりするし。

    ここに返信
    • by Anonymous Coward

      テストしたときに、1号機から2号機に切り替えて設定が2号機が稼動、1号機がバックアップという感じに切り替わったけど
      本番の開始は2号機がバックアップってことで始めただけだったりしてな。

  • by Anonymous Coward on 2020年10月07日 18時23分 (#3902442)

    https://ja.wikipedia.org/wiki/%E6%9D%B1%E4%BA%AC%E8%A8%BC%E5%88%B8%E5%... [wikipedia.org]

    今回のはシビレたろうな。忘れた頃にやってくる大障害にどうやって対処するか悩む所。
    お上の「お認め」がないと実行できないような代物(もしくは設定)がミスる時は、たいがい周りの引継ぎが忘れてるんだろうよ(管轄外だと思って)。

    #そこで信頼ある部下がサポートしてくれるかどうかで、明企業か暗企業で分かれる。

    ここに返信
typodupeerror

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

読み込み中...