東証証券取引所……共有ディスク不良で停止……待機系に移行できず。

予想とは違って、ある意味初歩的な問題だった。まあ、不具合が起きるときは大体想定している障害とは違う事で且つ、なんでここがという場所で、起きるのは、私も知っているので、担当していた人には、ご苦労様としか言えない。


記者会見を見たのだが、共有ディスク(両現用※の一方)のメモリー不具合(とディスク不良かな)だったらしい。
RAIDメモリーなのか、それともシステムメモリ(サーバー用はECCがあるのでメモリーホストに問題があったのかもしれない。マザーボードと呼んでいたので、何かのホストメモリーだろう。RAIDが怪しい。)なのか、それとも何らかのキャッシュメモリーなのかは、私が見ていた時間内に記者からの質問もなされなかったので、不明だ。

※物理的に2台のシステムが相互に機能する分散型の仕組みのこと。

最も最初に起きたのがハードディスクの故障なのか、メモリー破損なのかはちょっとだれも再確認してくれなかったので分からない。
メモリーかディスク不良で、どうも定刻に行われる複数のバッチ処理が上手に機能しなかったということらしい。この状況になると、フェイルオーバー(この場合のフェイルオーバーは不具合が起きた片側を切り捨てて正常な片側だけで運用する片運用)機能が働き自動で片側だけになるはずなのだが、それも実行されなかったそうだ。それが、制御しているファームウェアやプログラムによる物か、メモリーに展開されているデータが化けたからかを今、富士通の調査センターに送って調べているということらしい。どちらにしても、故障切っ掛けでフェイルオーバーが出来なかったから被害が出てしまったそうだ。

尚、待機ノード(待機系)もあるにはあるようだが、待機ノードそのものは災害用ノードとして機能するようで、短時間切替出来るものではないということだ。
これは推測で、現実にそうかは分からないが、たぶん、これはこれ以外の他のサーバーにも障害が起きたときに切り替える待機グループの一部として構築されていたのだろう。簡単に言えば、ここだけ(共有ディスクだけ)がロスとしたときに切り替わるノードではなく、このサーバーも含めたA,B,Cという同じような役割を持つ一連のサーバーが止まるような場合に、切り替わる仕組みだったのだろうと思われる。

それから、サイバーテロではないようだ。このシステム不具合が起きた部分が、オープンネットワーク(インターネット)に属していない、いわゆるサーバードメイン内にあるものだったのだろうと思われる。だから、外から攻撃は不可能だと言うことである。もちろん、一応全体のチェックは掛けてそれがないことを確認しているそうだ。

直接これで影響を受けたのは、

情報配信サーバーのゲートウェイ
売買監視処理

である。

7時4分にこの障害が始まったようだが、この共有ディスクには、どうもいくつかのバッチが時間指定で実行されているようで、その不具合から一部がクラッシュしたという話のようだ。その結果、遮断することになり、さらに既に8時からの注文が入っていたため、8時54分にゲートウェイを遮断し停止し、終日注文を受け付けない仕組みをとったそうだ。

当日中再開(正午などのきりが良い場所での再開)などをしなかった理由は、

これを、放置しておけば、取引終了時間に成立しなかったことになるため、問題は無いが、運用時間中にリセットすると、既に東証のシステムに送られ溜まっている情報は全てリセットされ消えるのに対して、その情報(消えたと言う情報)が東証のシステムから証券会社やってこなくなるため、注文した人は、自分が注文を出しているものと思い込んで仕舞う恐れがある。それでは、大問題になる。
だから、当日再開をやらないことにして市場は開いたが、東証のシステムトラブルで取引が出来なかったという扱いにしたそうだ。
今日はIPOもあったので、これは正しい判断であると言える。当然だろう。

尚、明日はこの問題があった部分周辺を常時監視し万が一同じような状況になりそうならば、手作業で片側を強制切断するそうだ。これをやると片側(だと思う)で運用できる事が確認できて(どうも9時30分に試したようで、上手く行ったらしい)いるようなので、それで対応するということだ。もし、それでもダメなら明日も止まる可能性もあるが、部品は今夜中には交換され、テストもされるのだろう。

一応この記事執筆時点では、19:30に明日の売買について連絡するそうだ。


尚、責任などは、これに伴う影響がどれほどあったのかを総括して、今後決められることだろうと思う。どちらにしても、何もお咎めなしということはないと考えられる。


という話だ。一部推測を含んでいるので、実際にこの通りかは分からないが、言っていることに対して、酷いという雰囲気はなく、ドコモより遥かにマシな会見だった。もちろん、今日が勝負だと思っていた投資家からすると、ゆるせない人もいるだろうから、その辺りへの対応をどうするかは、これから求められるだろうし、結果的にこのような不具合が起きた以上、考慮不足だったというのは間違いない。

これからこの問題が起きないための仕組みをどう構築するか、去年システムを全面的に、入れ替えているようなので中のシステム担当者はきっと頭が痛いはずだ。次同じ事があるのは許されないが、だからといって仕組みを大きく変える訳にもいかないはずだから……。(下手に一部の仕組みを変更すれば、今度はそれが不具合を呼ぶ恐れもある)当分というか、下手をすると次のシステム入れ替えまで、この部分は手動で監視することになるのかもしれない。


ちなみに、これは概ね記者会見の概要説明で説明され終わった話だが、記者は、システムを知らない人がこのまとめて要る内容に相当する質問の堂々めぐりを16時30分~1時間以上していた。最後まで見なかったが、もうちょっと同じ質問の繰り返しではなく、システムに踏み込んだ質問をして欲しかった。というか、そういうことが多少でも分かる人が行かないと、基礎の説明で時間が費やされて大事なことを逃しそうだ。


ブログ気持玉

クリックして気持ちを伝えよう!

ログインしてクリックすれば、自分のブログへのリンクが付きます。

→ログインへ

なるほど(納得、参考になった、ヘー)
驚いた
面白い
ナイス
ガッツ(がんばれ!)
かわいい

気持玉数 : 5

なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー)
面白い 面白い
ナイス

この記事へのコメント

大野康幸
2020年10月01日 22:17
運用担当者にはお気の毒なインシデントですね。
システム構築時の試験では合格しているだろう箇所で問題が出てしまったのですから。
今後ベンダー側で原因を精査するということなので、問題の詳細が分かるにはまだ時間がかかりそうですね。

今回はメモリ障害が引き金となって正規の動作ができなかったというのが真相のように感じます。
であれば偶発障害で再発の可能性は低いでしょう。もちろん当面は定期チェックを密にして再発を防止する必要があるでしょうが。

一番厄介ケースは不感帯が存在しており、障害が発生したシステムから正常系に故障信号が上がらなかった場合です。
ソフトウェアの修正で不感帯をすぐに取り除けるなら良いのですが、無理な場合は運用マニュアルの見直しが必要になるでしょう。

この障害対応に今後追加の作業が発生し続けるなら、
運用担当者としては相当しんどい状況でしょうからうまく周囲から協力が得られば良いのですが。