東証、障害の原因を特定 「自動切り替えできない設定値になっていた」…… 値は分かるが、その「値」に至った過程がない。

ITmediaの記事である。テストでは上手くいっていた(これはPDFには書かれていないので前回の会見に基づくものかもしれない)が、本番では上手く行かなかったらしい。


これを見て、納得出来る人は、サーバー保守とか関係ない人だろう。何故なら、いつ誰がどこでに従っていない。端的に言えば、設定がおかしかったことしか分からないからだ。何故その設定だったのかがない訳で、この内容だと、答えになっていないし、むしろ最悪の場合同じ構成のサーバーで同様のトラブルが出る恐れもある。

尚、この手のパラメーターはメモリー故障によって書き換わることはない。

通常、ノードの死活監視は監視対象とは別に存在するユニットである。例え、内部でもユニットの制御管理機構としては別物である。もちろんノード監視装置が故障した場合は異常が出ることもあるのだが、今回はそうじゃなく、障害時の切替パラが非活性-De-activate/Disable-(0)だったわけでイージーミスの可能性が高いだろうが、そうだいう断言もないからある意味怖いのだ。

そもそも、専用の組込ハード(サーバー監視をPCI/PCIeボード等で行う制御や外付けなどで行う制御)を持っている前提なら、物理メモリーの故障の場合まずオペレーション中(活性状態)のノード切り替え装置のパラが変わることはない。サーバーから送られてくるシグナル(正常か、異常かの情報)が変わらないというのは有り得ても、切替するかどうかを決めるパラメーターが書き換わることはこの手の大手システムではまずない。絶対にない。もし、そんな阿呆なノード管理ハードウェアを使っているなら、そもそも故障監視(死活監視)の装置ではない。はっきりって「あんなの飾りです」とサーバーの勉強を正しくしている管理者からは転けにされ契約は取れなくなるだろう。

死活監視するはずが、故障したハードの影響を受けているのだから……。

じゃあ何故、物理メモリーが故障しても書き換わることはないと言い張れるのかというと、そもそも、監視のハードウェアは、監視対象のシステムメモリーとは分離されたユニットであり、設定をするポートは監視対象(SV)から飛んで来るシグナルとは別の管理者ポートに汎用のPCなどを繋いで設定していることが多いからだ。

古くからのシステムで言えば、シリアルバスやSCSIなどを経由して、外にあるコンソールボックスと常時通信を行わせ、その状態監視が切れたか、おかしなデータを送ってきたなら、異常が発生したノードを切り離すかまたは停止する。そのコンソールボックスのパラメーターは、サーバー通信用とは別の管理者用の制御ポートから設定するのが、ある程度の規模なら(自作したなら別で、安価なものではそういう仕組みを備えない物もあるにはある)普通なのだ。


一応イメージが掴めない人のために、下の図を見て欲しい。
サーバーもしくはディスクアレイが2台あるとして、その制御をノード管理ハードウェアが行う前提である。
発表の図がハード制御に見えるのでハード前提である。かなり簡略な図になる。
SV_NODE_HD.PNG
本来システム2台以上を多重監視するシステムは上記のようになる。
一応図を説明すると、サーバーが青で、監視に使うハードが朱色になっている。N_1、N_2が監視を行うためのハードウェア機能だ。
重要なのは、VN0(便宜上そう書いているが、名前がそうとは限らない)と呼ばれる部分だ。仮想ノードが実際にサーバーネットワーク上で使われているかどうかは、サーバーネットワーク仕様と予算(重要性)にもよるが、それがサーバーネットにあるにしろない(サーバーとは別の管理用ネットワーク)にしろ、監視しているサーバーより上位の部分に監視設定をする機構があるわけだ。

もちろん常時それが繋がっているとは限らず、N1=N2だけで通信を常に同期させていて、どちらかのコンソールポートに端末を繋ぐと設定や状態を詳しく見られるという場合もあるが、設定を行う場合はVN0に相当するコンピュータ※を用意していてそこで設定するのが普通だ。
即ち、サーバー(SV)からノード監視(N)に設定を書き換えなさいと命令することはできないのである。よほど、管理ポートもサーバー側にループさせて繋ぐ場合を除けば……(そんな運用したら完全に設計ミスである)

※専用のドライバーと制御ソフトを入れたPCをサーバーとケーブルで繋ぐ、またはメンテ用のLAN(RJ-45)にパソコンを繋ぎ、Webブラウザで設定する。いわゆるホームルータの設定画面のようなものや物によってはPowerShell、コマンドプロンプトのようなコンソールでコマンド制御するイメージと考えれば良いだろう。

要は、故障を監視するシステムは、SV(server)_Nodeから受け付けるシグナルは全て動いているか動いていないかという情報だけということだ。
以下を見て貰えれば分かるだろう。以下は、待機ノードや両現用のサブノードを排除して、N1ノードとコンソール側だけをピックアップして情報のやりとりを端的に書いたものだ。(N2も同じように反対側に繋がっていると思って欲しい※。
SV_NODE_HD_detail.PNG
本来、ハードウェアをハードで監視しているなら、そのハードに対して、監視するハードウェアが必ずある。そちらのメモリーが故障したというなら別だが、監視している先のハードで異常が起きた場合、そのメモリーの影響で、監視用のハードが制御出来なくなったり、設定値が書き換わることはない。
何故かというと、監視対象のハードの監視基板を制御するハードが別にあり、そちらで監視対象のどこを監視し、どこが壊れたら制御を切り替えるかの設定を行っているからだ。


※N2ノードも両現用(サブ)で冗長兼用として動いているなら、N1と同じ動きを、稼働はしているが待機ノードとして故障時のみ役割を引き継ぐなら、ソフト異常などの制御の一部は簡略化されている可能性がある。即ち、N1、N2で監視対象を変えることが出来ると言うわけだ。同じように設定をするのを忘れて、N1だけをN2に切り替えることばかり考えていると、N2が壊れた時にN1に切り替わらず巻き込まれることも、あったり……。尚、前の図の説明で書いているが、N1とN2を仲介Vノードを使わず、相互連動させられる方法(装置)もある。その場合でも、監視用と管理用は別の出入り口(端子)となり、管理用の出入り口に汎用のパソコンを繋いで設定する。


これらを踏まえると、「自動切り替えできない設定値になっていた」のは確かに原因だが、「稼働前のテストでは、1号機と2号機相互の死活監視を途絶えさせても、自動切り替えできていた。」のに対して、もしも勝手に切り替わったという話ならば、その原因はまだ不明だ。原因は勝手に切り替わったコンソール側やN1、N2制御基盤(N1が故障検知をしないように書き換えたならN1、N2が受けても反応しない設定ならN2)にあるのではないかという話になるからだ。

早い話、SV1のメモリー異常が原因で自動切替出来ない設定にN1やN0の設定が切り替わることはどう足掻いてもない「はず」だ。
しかし、稼働前のテストでは上手に動いた。
だから、絶対に設定はしていたのだと、仮定した場合、
いわゆるN1やN2の制御を監督する装置が壊れているか、設定が時々勝手に変わると言うことだ。その場合、実は深刻なバグや障害がこのノード切替する装置にあるということになる。


もちろんこれは、ハードウェア制御ならばだ。

やってはいないと思うが、N1とN2の管理をそのまま監視先のSV1に任せたとか、予算不足ならないとは言えない。
それでも監視ルートのネットワークは別に用意し、且つ通常のモニタリングと、設定権限(通常はパスワードが必要)は別なので起きにくいだろう。

完全もしくは半端なソフトウェア制御の場合は、ミドルウェアやOS側で相互クラスタリングを行うか、OracleなどのDBのマイグレーション機能を使って分散処理させているはずなので、メモリー破損の状況によっては、仮死状態(半落ち)に陥ることがある。ただ、図を見る限りそれはない。


上記は、不安を煽る意地の悪い書き方であり、現実は多分、最初の設定ミス(確認漏れ)があったのか、または定期保守(リプレース1年でも1度は入っていると思うが)の際に何らかの理由でリセットされてしまって、気が付かなかったとかそんなところだろう。じゃあ、それで良いジャンとはいかない。何せ、デジタル庁を作る国なのだから……。

<人的ミスでも、機械のバグでも明確な結論まで調査し出すべき>

現場で頑張っている人が報われる社会というのは、原因が正しく認識されて、共有されることで同じ事が各所で起きない状況が作り上げられることにある。

ただ、それが中途半端だと、結果的に同じ問題が、同じ組織にかかわらず繰り返される恐れがある。

それが、例えば意図的に行われたりしたならば、当然その人は責任を取る必要があるだろうが、マニュアル上は一応しっかり対応していたというなら、責任は組織全体、場合によっては社会として似た仕組みを持つところ全体の問題になる。だから、最後まで突き詰めないといけない。それを次は起こさないように、即時周知はもちろんマニュアル化し徹底するしかない。今回はそこだと思うが……どう考えても消化不良だ。

これは、PDFデータのようなので会見で述べられたわけではないのだろうが……東証の最初の会見が良かっただけに、富士通の報告がこれだったからとしても、今回は少し残念だ。

<突き詰めた原因まで至らないとそれは役立たずどころか足かせ……
         原因より責任に向かうと突き詰めた原因を組織も出さなくなる……それは衰退を生む>

いや、もしもこれがハード側だったらと思うと、管理者なら背筋が凍るような話だろう。
なんでこんなに曖昧なのだろうか?諸外国ならば、人的ミスなら人的ミスと断言した上で、責任はともかく再発防止を述べるだろうが……
ハードにもソフト(人)にも見えるような雰囲気で曖昧を作っているから、結果的に同様の事例が他(東証に限らない)でも繰り返されることは世の中結構ある。あの時に、これをもう少し追求して調べていれば、今回これはなかったとか……私も、経験しているが、そういうのがこの発表にはあるのではないかと思えてくる訳だ。

一番怖いのはメンテの時等に何か操作するとリセットされるとか、想定にない条件で設定がかわったりすることが怖い。

本当はそういうのを含めて、原因の調査(必ずしも誰かの責任を問うためのものではない)というのだが、日本はどうにも、まず責任を問うためだけに原因を求めるのが社会になっている部分もあり、そういう人に限って、責任を求める事が目的で、改善する事には消極的だったりする。そして、その人の基準を軸にするから、結果的に追求の方向が最初と違ってしまうことも間々あり、それに時間を取られるのは面倒になる。

だから、組織もだんだん真実を言うのが面倒になり、怖くなる。そもそも、知らない人なら追求もしてこないから、この程度で良いと思うようにもなるだろう。
結果的に調査が不十分なままに終わってしまう。だからいつまでも、同じようなトラブルが起きる。

これが、最終結果なのであれば、そこに嵌まっているのではないかと問いたい。

卵なのかニワトリなのか、どっちがどっちなのか分からないが、
それこそ、日本の生産性が通信やデータも含めて低くなっている理由かも知れない。


これが、結果だという結果が出ても、それは別の原因を追及しなければいけない過程だったということは結構ある。しかし、最近はなかなかそこまで至らない。なんか知らないうちに、手元にある芋づるに繋がるイモではない別の芋づるを引っ張ってそっちがデカかったといってみたり(ドコモコウザ問題がそれ)、芋づるを敢えて切ってしまったり(今のところこれはそれになる恐れがある)、批難したいがあまり、一番手前にいるイモだけに責任を求める(政治問題はそれになりがち)ことも多い。
本当は、全体で結果的にその因果のある芋づるがどこまであって、それを全て掘り出して効率的に解消するにはどうすべきかを考えることだ。イモの1つが腐っているから、切り捨てて処分すれば満足という話じゃない。何故腐っているのかを解明してから、処分が必要なところを処分しないと、全部が腐ることだってあるし、お隣の別のイモや野菜に飛び火することもある。

即ち、本当の原因を見つけて、発表することがまず最初であり、それが出来ないなら下手をすれば衰退するということを忘れてはいけない。情報を出す中で大事なのは、発表したという体よりも、そこから得られる情報を共有することで、他でも同様事例が起きないように周知することだ。
だからこそ、それを本質的に理解もせずに、叩くのも論外だ。叩く(罰する)ならちゃんと、それを叩くことでで改善されるという根拠も示さなければいけない。そのためには、真相の全てが出るように努め続けないといけないのだ。






ブログ気持玉

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

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

→ログインへ

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

気持玉数 : 2

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

この記事へのコメント

大野康幸
2020年10月07日 22:09
メインユーザの投資家向けの公表としてはこの内容で十分なのかもしれませんが、技術者から見ると不自然に感じる情報量の少なさですね。
何というか釈然としないものを感じた方は多いのではないでしょうか。

JPXの公式発表をそのまま素直に受け取ると、
稼働前試験ではメモリ障害が発生した際の死活判定を評価していなかったということになります。
これが正しいするならば、稼働前試験の項目不良が今回の障害の原因であったと運営会社が認めてしまっています。

設定値の変更で今回の障害が解消したというのは事実でしょう。
しかし初歩的なことが試験項目から漏れているシステムに他のチェック漏れが無いか疑問を抱いてしましました。

疑念を払拭するためにJPXは客観的にシステムの健全性を確認できるエビデンスを提示する必要があるでしょうね。