サービス復旧までが長かったですね。。。。
そして、影響範囲も大きかったようで、これは後片付けがとても大変そうですね。。。。
さて、記者会見を「ざっと」みました。だって、1時間もあるので。。。。
だいたいこんなところでしょうか。
ちなみに、この記者会見は6月27日夜に開かれていて、この時点ではまだ復旧はしておらず、復旧完了は翌日28日でした。
- 原因はシステム間のネットワークの不具合。
- 不具合の原因は判明している
- 運用管理サーバー（JP1）が各種基幹システムを運用管理している。
- 不具合は対処済。
- 現在は、安全着実な普及作業を慎重に準備している。
- 不具合の特定に時間がかかったため、障害が長期化した。
いまいちピンときませんでしたが、質疑応答になり、IT部門の方が話を始めると、少しだけ全体像がみえてきました。
- 各基幹システムとの通信設定は、JP1が一括管理している。
- 1-2か月に1度の頻度で定期的に再起動をしている。（ちょうど土日で再起動）
- 5月上旬に、サーバーを追加した。
- 通信設定の仕方に誤りがあり、「臨時」の設定をしていた。
- 本来であれば、正式なルートを確立という登録をする必要がある。
- この臨時のネットワーク設定が、週末の再起動で、消えてしまった。
- 人為的（設定ミス）な原因である。
- 外部機関との接続を司るシステムについては、更新のため、新旧のサーバーが併存していた。
- すべての外部接続（50数社）がすべて切替完了したら、新旧サーバーを正式に入れ替える計画だった。
（もし、聞き取りミスや理解不足などがありましたら、ごめんなさい。）
こちら、Twitterで出回っていた画像です。
みずほ証券ネット取引システムを介した株式、投資信託などの売買ができない障害についての記者会見会場で配られた資料はこちら こんなん草生える pic.twitter.com/XUwINQ5ejy— 無双 (@Domino0207) 2018年6月27日
なお、「JP1」という単語が何度か登場しましたが、日立製の運用管理パッケージで、このソフトウェア自体にはなにも不具合はないだろう、ということをコメントしておきます。
うーん、Linuxで例えると、本来であれば/etc/sysconfig/配下のnetowrkファイルを設定すべきところを、routeコマンドとかで設定していたので、再起動でルーティングが消えちゃった、ということかな？
ルーティングテーブルの確認だけなく、設定ファイルそのものを（期待通りか）確認したり、または本番稼働前に（運用後を想定して）再起動してみる、とかしないのかな？というのが私の素直な疑問です。
特に、後者なんて、再起動後に、再起動前の状態が保障されるんて、絶対ではないからね。
まあ、もうしばらくしたら、「日経XXX」とかの雑誌でも特集が組まれて、正確な真相が明らかになることでしょう。
最後になりましたが、当障害について対応いただいていた（または障害回復後の対応をまだ実施されている）関係者の方々、お疲れ様でした＆お疲れ様です！
0 件のコメント :
コメントを投稿