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

みずほ、不具合の波及把握できず 金融庁に報告へ

46
Picks
このまま本文を読む
本文を読む

コメント


のアイコン

注目のコメント

  • 銀行 調査役

    本当に関連ないということでしょう。そもそも、障害一つ一つは、小さい話なので、それらに関連を見つけることなんてできないということなのかしら。休日の事後対応の仕組みは、銀行員といえども人間ですので、すぐに支店に駆けつける等といった物理的な対応には限界があります。休日も病院周辺で待機を要する外科医ではないですからね。過剰な事後対応の仕組みとならないように願いたいものです。


  • Colleagues/ふるさと納税ガイド CTO

    この定期預金データの移行で負荷が上がってという話と似たような事案でちょっと面白いというと語弊がありますが、興味深い事案が割と起こってたりします。

    実はデータベースの更新はストレージへのデータ書き込みだけじゃなくて複数台用意して負荷分散する為のレプリカに更新データの伝搬したりなど読み出しよりも全然忙しいんですね。特にデータの削除とかめちゃくちゃ遅いんですよ。もちろんコンピュータレベルで遅いって話なので人間の認識スピードとは次元が違いますけど。

    で、負荷を上げない為にある程度のデータをまとめて更新をかけるとか、更新後にsleepを挟むとかいろいろノウハウがあるんですが、今まで動いてたソフトをそっくりそのまま使っているのに新しい環境に移すと突然負荷が上がって障害になってしまう事があるんですね。

    何も変えてないのに突然システムダウンして、何でよ?!と大騒ぎするんですが、実はデータベース更新の合間に計算量が多い処理が挟まってると、今まではそこの計算時間の長さが擬似的に負荷調整の役割をしてしまって、新しいサーバの計算スピードが上がるとプログラムに何の変更も加えていないのにシステムダウンして大障害になったりします。

    しかもこれはテスト環境だと殆ど発見できません。理由は簡単で開発環境やテスト環境に本番環境と同じような超高価なハードウェアは入れないんでちゃんと動いちゃうんですよねぇ。

    サーバが良くなると勝手に障害になるというのは、なかなか皮肉な感じで嬉しいんだか悲しいんだかという複雑な心境になります(苦笑)


  • ベイカレント・コンサルティング 常務執行役員 CDO

    つながりを解明してこその原因調査。
    真因を明らかにして、そこに手が打たれることを期待しています。
    それに尽きます。


アプリをダウンロード

NewsPicks について

SNSアカウント


関連サービス


法人・団体向けサービス


その他


© Uzabase, Inc

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