バックアップ、5年「OFF」 富士通のマニュアルに誤り 東証システム障害
コメント
選択しているユーザー
テスト工程の重要性を思い知らされますね。ストレージ機器の設定ミスを検知する仕組みがなかったということになります。納期は限られているという状態であっても、運用上必要なテストが十分に行えていれば防げたと思います。
ミスを犯したのはベンダーであっても、実害を被るのはユーザ企業なので、いかにユーザ企業のIT担当が重要な役割を担っているかということだと思います。
注目のコメント
以前の障害時に動作の説明をさせていただきました。
メディアへの情報が小出しなので、自分が富士通で金融のストレージ構築を担当していた範囲で知っている知識で書くので、以下のコメントは多分に推測を含みますのでご了承ください。(壮大なネタの可能性があると思ってください)
富士通がアメリカから購入しているストレージには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他のエンジニアの方も指摘されていますが、本障害の起因がETERNUS(NetAppのOEM)の場合、7modeからcdotへ切り替えた後、デフォ値が変わった事が起因するかと。。
7modeとcdotは全くの別物で、さらに7toC(7modeからcdotへの移行方法)を実施してもデフォ値が変更されます。しかも変更されたデフォルトの値の確認コマンドも変わるという中々の仕様です。それを全て網羅できるエンジニアも日本では少数です(インフラエンジニアでも、とり分けストレージに対するノウハウを持った方は希少)。
また、移行後は設定値が気になるからと簡単に確認できないものとなるため、そのままずるずると今まできてしまっての本件になったものと推測します。
富士通には気の毒ですが、今回は移行後の確認の漏れが原因になりそうですね。。