今日のオリジナル番組


詳細を確認
タブーに切り込め!ここがおかしい「日本の保険」
本日配信
506Picks
Pick に失敗しました

人気 Picker
以前の障害時に動作の説明をさせていただきました。

メディアへの情報が小出しなので、自分が富士通で金融のストレージ構築を担当していた範囲で知っている知識で書くので、以下のコメントは多分に推測を含みますのでご了承ください。(壮大なネタの可能性があると思ってください)

富士通がアメリカから購入しているストレージにはNetAppという有名なメーカーがあります。
これは主にファイルストレージがメインの分野で、富士通が国産で設計しているEternusとはジャンルの違うストレージ機器です。

OEMのため、富士通での販売名はEternusと言っていますが、中身はNetAppのそれそのものです。

実はこのNetApp、今から5年ほど前にシステムのOSをドラスティックに変更しました。わかりやすくいうと、Windows10がMacOSに変わったぐらいの大変更です。

7modeという歴史あるシステムからcDotにかわり、自分も最初は全く歯がたたないくらい変化についていけませんでした。

その時クラスター構成が大幅に変わって、設定値がわかりにくかった記憶があります。

もし仮に、本件がこの機器で、該当osがこの話だとしたら、設定する場所がそもそも変わっており、有効にしていなかったという内容はなるほどなと思います。

実は金融系に限らず、どこの現場でも以前の設計書を使い回すことは非常に多く、基本設計(そもそもの大まかな動き)と詳細設計(たとえば今回のようなパラメータのオンやオフ)は踏襲することが多々あります。

また、システム納品には検収というのがありますが、システムがどう動いたかは試験仕様書とエビデンスを付けて納品することが多く、検収側がそこを細かくみていることはほとんどなかったと思います。

とても残念なのですが、今回の件がストレージ側の設定ミスに起因する場合、やはり納品した側の富士通の責任は重いと考えます。
しかしながら自分も経験しましたが、ストレージ専門の人は日本では本当に少なく、またレビューして指摘ができる人も案件を抱えすぎているのは、ITインフラを蔑ろにしていることも無視できません。

できれば本件はいろいろな憶測が私含めいろんな方から出ますので、詳細な説明がなされることを富士通には期待したいと思います。
2015のNYSEの障害ではNYSEに否があり1400万ドルのペナルティが課せられた。
今回の件で金融庁としても責任の所在を確認する義務はあるだろう。

https://search.yahoo.co.jp/amp/s/nypost.com/2018/03/06/new-york-stock-exchange-fined-14m-for-2015-outage/amp/%3Fusqp%3Dmq331AQRKAGYAbLeruLDv8Xo0QGwASA%253D
テストって、つくづく大事だということを思い知らされます。

入社当初に担当したシステムは、一企業のシステムでありながら、日本の金融システムの一部を担う重要なシステムでした。

そのときの上司が、新たなシステムを構築する際にフェールオーバー(今回の障害で行おうとしていたバックアップシステムに切り替えること)テストを3回実施していました。
1回じゃわからないことも、3回やれば安心できるということを言っていましたが、この信条は他の会社では見つけられないパッケージ製品のバグを見つけるなど、些細なバグも見逃さないことに貢献していました。

今回の東証のシステムはまさしく重要システムであり、このフェールオーバーテストをしていればわかったと思いますが、問題の機器のみが障害時のフェールオーバーテストはしていなかったのかもしれません。


一方で、こういったテスト対応には多大なコストがかかります。システム構築は、日本で高いといわれる人件費の塊であり、さらにその中でもシステムエンジニアの人件費は高いです。
これらのコストも踏まえて、どこまでテストするかを判断する必要があり、アメリカのシステムはテストを省力化しており、日本もその傾向がある認識です。

どういう基準でテストを省略すると判断してしまったのかは、今後のテスト実施の観点にしたいので、公開して欲しいなと思いました。
機器メーカーの仕様変更に追従するには、運用保守の定期イベントでキャッチアップする体制が重要だと学べます。

加えてリスクアセスメントに「保守レベルの低下」を追加して、リスク保有でも、リスク低減でも、常にステークホルダとの合意を維持したうえでコントローラブルな状態で保守したいものです。

ICT部分を外部に委託した事による 企業のリスクアセスメントの実効力確保が挑戦になるとしても、です。

フェイルオーバーやディザスタリカバリ、IaCのテストは大変ですが、テストイベントを企画して 実機でやってみる、願わくばF1のピット作業の様に訓練を重ねる機会を提供し、技能を向上できる仕掛けが求められているのかも知れません。
え?
富士通がこの変更を把握してないわけないでしょ。

『2015年9月のシステムの仕様変更前までは「オフ」でも15秒後に予備に切り替わる仕組みだったが、機器を製造した米メーカーが「オフ」時にはバックアップを作動させない方式に変更。これを富士通が把握せず、「オフ」にして東証に納入。マニュアルにも反映させなかったため、東証は気付かないままシステムを運用していたという。』

〈追記〉
ストレージの切替設定はそもそもそんなに単純ではない。
障害時の挙動(待ち時間など)について、この様なクリティカルなシステムで初期設定のままという事はあり得ないでしょう。

何らかのの意図で設定を施してるはず。

「OFFでも15秒後に切り替わるんで」
なんて言われて管理者は了承しないでしょう。
切替が要件にあるなら、ONにした上で切替条件を設定するのが当然。

どうも腑に落ちない。
富士通のマニュアルミスというまさかの結末。

東証関係者はえらい迷惑かけられましたね。

これは富士通は未来永劫「マニュアル大丈夫ですか?」とイジられるやつ
事故の当時は「富士通の責任は問わない」という発言でずいぶん持ち上げられた東証ですが、軽はずみな発言だったと言わざるを得ない。
ストレージのフェールオーバー設定がそもそもされていなかったという何ともお粗末な顛末。請負った富士通はド素人となじられても仕方ないレベルだし、受け入れた東証のリテラシーの低さも疑われる。そもそもシステム納入時点でフェールオーバーの試験不足してたんだろうなと。この規模であり得ないケース。公式発表見ましたが、原因も一言で情報を公開したくないという態度がありありと。こういう時に体質がよく見えます。サマリーするのは記者にやらせて、専門用語を使ったしっかりとした原因分析、対策について発表すべきだと思いますけどね。
(コメントに誤認あったので修正)
NetAppのOSの仕様変更に気づかなかったということでしょうか。ストレージの設定ってそこまで細かくチューニングしない印象なので、途中で仕様変更であれば試験でテストできないようなレアな障害ケースだとなかなか検出は難しいかも知れませんね。(今回のパラメータが一般的な試験項目で検出しやすいパラメータかどうかは分からず書いています。)
改善点を突き止めることができて良かった。記事を読んでみるとなーんだとなるけれど。機器管理は危機管理に通じる。われわれの日常でもマニュアルを精読することで解決することが多い。