みずほ障害、データ移行失敗でバックアップ機能せず
コメント
注目のコメント
#みずほ #MIZUHO #システム障害
IT系各メディアの記事から想像するに、
● 「業務チャネル統合基盤」（富士通担当）のDBサーバーの故障が起因
● 故障の際にDBサーバの設定情報、構成情報等のデータ（情報）も複雑に破壊
● DBサーバそのものは（ハードウェアは）バックアップ系に自動的に切り替わった
● しかし、DBサーバの設定情報、構成情報等のデータは複雑に破壊された状態で引き渡された
● DBサーバのバックアップ系で自動起動を試みた際に、設定情報、構成情報等のデータが壊れていたので起動できず
・・・ みたいな感じだろうか。
（まさか、昨年10月の東証の共有ディスクの切り替え障害と繋がってたりはしないよね？）
対処としては、、、
● DBサーバの設定情報、構成情報等の定義情報のコールドバックアップからDBサーバ（バックアップ系）の再定義して起動
● 設定情報、構成情報等の定義情報以外の本データは共有ディスクやなんらか別の方法でアクセスできるはずなので、それをバックアップ系DBサーバに流し込む（インポートか繋ぎかえか等）
・・・ということをしたのだろうが、翌朝の営業時間開始までに間に合わなかった、ということなのだろうか。
（前日21時に障害発生 → 翌日9時の営業開始に間に合わず、正午頃に復旧・・・という事態から）
いずれにしても、翌日の営業開始に向けて、○○時までに復旧できなければ、代替手段に切り替える・・・という、「代替手段の準備」「障害発生〜復旧時の判断基準やその司令塔」は存在して機能していたのだろうか。
個人的には、、、勘定系システム全体を、MINORI (A) と MINORI (B) の二系統にして、完全に相互バックアップする仕組みにしてはどうかと思う。ベンダーもアーキテクチャも別々にして。（互いに健全な競争をし合う副次効果も見込む） （※ 支店にはA系とB系の両方を使える端末、ATM等を用意しておけばいいし、ネットチャネルやその他チャネル系も閉塞しちゃうか、もう一方の正常稼働系に順次切り替えていけばいい）
<追記>
「業務チャネル統合基盤」(富士通担当)にDBサーバ、DBMSが存在するのは何故だろう？ どんな業務データ(定義情報ではない)を扱っているのだろう？
富士通だとすると Symfoware Server ？いやな話しかもしれませんが、業務委託的には最高の状態に見えます。
一般論として
運用フェーズを請け負ってる企業は、障害の悪名に耐え、怒り狂う顧客を情報格差でわからん殺しをし続け、現場PMには法務と責任転嫁ゲームのプロを配置し致命的な追求は避けつづけ「誠意」だけは究極レベルで示し続ける。
エンジニアの仕事はコードの量産ではなく「誠意」の量産。
鬱病が何人も出たら最高。こんなに頑張ってるんだから。企業としては大口顧客からの受注をし続けられる。
これが日本の無限のベンダーロックイン。
「業務委託」(もしくは準委任)という制度下において悪魔的キャッシュカウです。
省庁もやられてるためデジタル庁の一丁目一番地の課題となってます。
なんなら致命的でないギリギリまで炎上してる方がテスト要因を過剰増員する理由に出来たりします。謝り倒しきれれば大量の工数積めて嬉しいわけで。
ちなみに企業側もかなりテクニカルです。ブチギレる部下や内部告発しかねない輩も増殖しますので、なだめすかす人柄と訳分からん説得力がありアンガーマネジメント的なプロを責任者、事業部長などにできると良いでしょう。
「直しきらない方が儲かるのが業務委託」
この前提において日本最大の銀行という無限の財布、究極の金鉱を顧客に据え限界まで搾るには定期的な大障害は、、悪くない状態です。ギリギリ死なない末期癌を継続できるような。悲しいかな。
こういった利益が相反する理由があるためシステムは理想的には内製化すべきなのですが、日本の制度下では超リスキー。
もし無能を取っちゃった場合首切れないためです。
故に「業務委託」の単位で首切り需要を担保せねばならない。
この「力学」が続く限り真面目にビジネスするとこうなります。
日本の最大の金庫が最悪のサグラダファミリア状態。
こんなおいしい状態はありません。
リソースを無尽蔵に投入しましょう。
さぁ行けピクミン達。炎の中から金を回収してくるのだ、と。
繰り返しますが一般論ですので。悪しからず。
