• 特集
  • 番組
  • トピックス
  • 学び
プレミアムを無料で体験

みずほとFacebook、大規模障害時に雲泥の差

日本経済新聞
7
Picks
このまま本文を読む
本文を読む

コメント


注目のコメント

  • 零細IT屋さん 代表取締役社長

    手順書のミス。でも6年前から存在してたミス。
    あと「地震想定の訓練」と「移行訓練』はしても「大規模障害想定の訓練」はしてない、と。

    で、多重ディスク障害は「めったに起きない出来事」なので「想定外」だったと。

    ふみゃー…
    いや、普通にあるでしょ…
    というか想定外のことを想定してテストするのが「テスト」ではないのか…



    (以下引用)
    DBサーバーを手動で待機系に切り替えるのと同時に、クラスターソフトウエアの設定を変更して、アプリケーションサーバーの接続先を待機系DBに変更する必要があったのだが、クラスターソフトの設定変更が手順書に盛り込まれていなかったのだ。

    みずほ銀行はもともと、サブセンターを災害対策用と位置付けており、障害が発生している業務チャネル統合基盤のDBサーバーだけサブセンターに切り替える手順を想定していなかった。そこで急きょ、富士通に対してDBサーバーをサブセンターに切り替える手順書の作成を依頼して、できたばかりの手順書を使って切り替えを敢行した。

    つまり元から用意していた手順書にはミスがあった一方で、その場で作った手順書にはミスがなかったのだろう。だからサブセンターへのDB切り替えだけが成功したのだ。

    今回障害が発生した業務チャネル統合基盤をみずほ銀行が稼働させたのは、MINORIの開発中だった15年のことだ。それ以来6年間にわたって、DBサーバーの切り替え手順書に存在するミスが見過ごされていた。

    (中略)

    金融機関の中には、定期的にメインセンターからサブセンターへシステムを切り替えているところもある。そうした日常のオペレーションに溶け込んだ形の訓練も、みずほ銀行は実施していなかった。


  • 株式会社コマースピック 代表取締役

    タイトルを見てクスッと笑ってしまい、本文を読んでFacebookはすごいなと感心し、みずほは(不安定な)安定稼働だなと安心した。


  • LinkedIn 営業

    そらテックジャイアントとメガバンクの中でも一番テクノロジーを軽視している銀行とじゃわけがちがう。


アプリをダウンロード

NewsPicks について

SNSアカウント


関連サービス


法人・団体向けサービス


その他


© Uzabase, Inc

マイニュースに代わり
フォローを今後利用しますか