みずほのシステム障害の根っこにあるものを考えてみる（業務システムの特別対応について）
大変に同情します。。。
継続したニュースになっていますが、なんというか根が深いですな。
よんてんごP（@yontengoP）さんの記事が興味深かったのでご紹介。
原因はどこにあるんだろう？
おそろしいのは、原因が「事象ごとに違う」というところ。それも、レイヤーをまたいで違うんですね。
→これは運用起因と言われていますが、銀行は一度の処理量が極端に多かったりしますからね。ハードウェアだけではなく、この処理とこの処理は同時実行しちゃダメとかいろいろありそうです。
→これはシステム負荷とか、スペックの問題っぽい。
→これはクライアントなのかサーバ側なのか、同時ということは、サーバ側の要因があったとしてもクライアントも関係しているんでしょうね。
今回の問題は、年末年始の特別対応
これを読んで「うわー大変だなーでも、システムあるあるだなー」と思いました。
今回の事象は一言でいうと「システムが年末年始の特別対応を想定していなかった」というように読めます。
・全銀システム経由の他行宛振込に係るコアタイム（他銀行振込ができる時間）は通常15:20分に設定している
・ただし月末は振り込み手続きが集中するため、コアタイムを午後4時20分まで延長している。これは他行も同様である。
・年末の最終営業日だけは、全銀システムは毎月末と違い午後3時20分までとするルールになっている
年末年始の特別対応というのは、業種によってあるあるだと思います。
やっかいなのは、おそらくこの「年末の最終営業日」というのが、固定の日ではないということで、システム都合で決められるものではないってことです。
おそらく全銀協からお知らせが来るんでしょうね（来るのか、お知らせアップなのか知りませんが）
なので、決まったら何かしら「設定を投入する」みたいな運用をしないといけないのではないかと思います。もしくはその日だけ稼働時間調整するか。
年１回の特別対応は鬼門ではある
こういう完全につくりこめないものって、難しいですよね。。。
弊社の場合だと、どんなシステムをいつ止めるのかみたいなものを３か月くらい前から一覧を作って作業するベンダーと確認してます。
なぜ３か月かって？
・（弊社の場合）告知ベースで決まる
・いつ決まるかわからない
・決まったら確認するタスクを立ち上げておかないと忘れる
からです。
絶対に落としてはいけないタスクは、周囲を巻き込んでスケジューリングしておく
こういうのは、システム側のつくりこみとは別に、運用設計を組んでおく必要があります。
・「〇〇の担当が××の時期になったらリマインドする
・人事異動などで落とさないようにチケット化やスケジュール化してもらさないようにしておく
・ものによっては毎年の定例会議的なものを設けてしまう
みたいなやつですね。
最後、方法としては最強だと思っていますが、会議のリストラで「担当が時期になったら確認すりゃいいじゃん」なんてやると、タスク自体が落ちたりするの、あるあるであります。。。！（弊社の場合）
開発時の運用想定はドキュメントされていないことが多い
システム想定って大体仕様書の形でドキュメント化されています。さらに、システム運用の設計もドキュメント化されています。ここまでは大体開発ベンダーがやってレビューもきっちりやってくれます。
しかし、
非システムの部分の運用設計は通常ユーザに任せられています。
ここまで戻ってなんとかしようとするということは、少なくとも基本設計に戻らないといけないのでは。
ほかの事象を見ても、たとえば障害時の通知とか、保守切れのときの決めとか、そんないろいろが決まっていない（誰もタスクを持っていない）ものがある気がするんですよね。
これは大変だ。。。
みずほのシステム障害は、いろいろな本が出ていますね。
これは私も持っていますが、良書です。
その前のものも持っています。この２冊を読むと、組織的な問題とか困難さはわかります。
（いやあ、しんどそうなプロジェクトですね）
おしまい。