SysAdmin's Group システム管理者の会
日本最大規模の
システム管理者のネットワーク

コラムを楽しむ

システム管理に携わる人たちが語る。様々な話題満載のコラムをお届けします。

ニューノーマルで悩む管理者の夜 第七夜 みずほ障害で悩む管理者の夜
2021年4月28日 10:00

コロナとCOCOAとみずほ障害

2021年になりまして、緊急事態宣言の2度目の発動、ワクチンの配布や変異株(*1)、さらに「まん延防止等重点措置(*2)」や見回り隊(*3)など、世間ではいろいろとごたごたしています。で、とうとう3度目の緊急事態宣言が2021年の4月25日に発動。ニュースはそれ一色です。そのごたごたに紛れて、通常であればIT業界を震撼させるシステムトラブルが立て続けに起こりました。

・COCOAのバグが6カ月放置

・みずほ銀行ATM障害

 

世間が騒がしくなければ、もっと騒がれていたような気がします。最初のCOCOAバグについては、2021年2月18日、最新バージョン1.2.2の配布を開始し、Anrdoid版・iOS版が更新されました。Android版では陽性者との接触について通知を受けられなかった問題を解消したらしいです。また、厚生労働省は、1日に1回の立ち上げを推奨しています。(https://www.mhlw.go.jp/stf/newpage_16841.html


図表7-1 COCOA画面

そして、みずほシステム障害。これは、システムの障害も問題ですが、その後の対処や関係者の発言、そして「10年に1度、大規模障害を発生させてしまう体質」が課題です。

 

頭取発言「システム運用」の責任

まず、3月1日に開かれた記者会見です。

みずほ銀行の藤原弘治頭取が障害の原因を説明した。
略。
システム障害の責任問題について問われると、藤原頭取は「システムは無事に成功裏にリリースされた。今回、システム運用でみずほ銀行とグループが責任を持って担うところが不十分だった」としたうえで、「みずほ銀行とグループが責任を持って対処する問題だ」とした。今後については、さらなる原因究明のうえで、再発防止に努めていく。

以上、日経XTECHのニュース(https://xtech.nikkei.com/atcl/nxt/news/18/09768/)から引用しました。
記事タイトルが「運用に問題があり自らの責任」とあり、また運用のせいにされるのか、と思っていましたが、システム運用における銀行とグループの責任所在が不十分だった、みたいな口上です。システム運用に銀行やグループの責任を置けば、今回のシステム障害は回避されたか、というと微妙だと思うのですが、考察を進めてみようと思います。また。「銀行とグループ」とあえて、銀行と(運用などを行っていた)グループ会社/組織が全く関係ない組織であるように語っている点も特徴です。

 

みずほ銀行の3つの大規模システム障害

みずほ銀行の過去のシステムトラブルについて、共有したいと思います。

みずほ銀行 システム障害の歴史

時期 障害 原因 影響 遠因など
2002年4月 第一勧業銀行、富士銀行、日本興業銀行の3行合併時。ATMで不具合。その後、口座振替の遅延に起因して二重引き落しや二重送金も発生。 RC(リレーコンピュータ)のトラブルと言われていたが、実際は口座振替処理(センターカット)のために新規導入したプログラム(日立製作所のメインフレーム上で稼働)の開発に失敗。 ・ATM処理停止
・口座振替未処理や二重引き落し
など
・非片寄せシステム
・オンラインの疎通確認ができていなかった(のにサービス開始)
・トラブル後の対処のミス
2011年3月 東日本大震災後、特定口座に対する義援金の振り込み処理。上限を超える件数の振り込み 上限を超える件数の振り込みによるバッチ処理未処理/遅延。その対処のため、バッチ/オンラインの並行稼働実施に起因する諸システムのトラブル。 ・ATM停止
・振り込み処理停止
・オンライン処理起動遅延
・窓口業務
など
・上限設定のミス
・振り込み口座の設定(リーフ口/通帳口)
・リカバリのミス
など
2021年2月 コロナ禍(緊急事態宣言下)で、ATMトラブル(カード/通帳が返却されず)
さらに、2週間で4つのシステム障害も発生
バッチ処理(データ更新)でのメモリー不足。
休日であるため窓口が休み【さらにコロナ禍で出行人数減少】
・ATM停止し、カード/通帳が排出されず
など
 
参考 
みずほ銀行発足初日に大障害、「必然」だった2002年の二重引き落とし(https://xtech.nikkei.com/atcl/nxt/column/18/00867/071700017/
みずほに2度目の試練、東日本大震災の直後に大規模障害(https://xtech.nikkei.com/atcl/nxt/column/18/00867/071600010/

図表7-2 みずほ銀行の3つの大規模なシステム障害

 

図表7-2に整理してみましたが、みずほのトラブルは非常にわかりやすい(=初歩的)といえます。2002年は、根本原因は、たぶん銀行合併で「銀行勘定系(*4)なのに片寄(*5)にしない」し、そもそもオンライン疎通がうまくいっていなかったような状態でリリースという(今では)信じられない状況でした。設計思想自体がアウトで、そもそもリリースできないシステムをリリースしたという判断が大問題です。
2011年は、口座の振り込み設定を法人-リーフ口という記帳しない設定にしなかったことが、(記帳処理の発生による)処理が重くなり、かつ上限設定を超えてしまった、ことが起因です。
また、2002年・2011年の両方とも、システム障害発生後のリカバリでヒューマンミスが発生していたようです。銀行勘定系などでは、1つのシステムトラブルが、連鎖的に他のシステムに影響するので、かなり注意が必要です。バッチ処理の遅れはそのバッチ完了を前提としている翌日のオンラインに影響を確実に与えますし、オンラインシステムが稼働できない場合、業務自体が開始できないこともあります。2011年と2021年では、このバッチ処理の未完了/処理オーバーに起因して、その後の処理もグダグダになっています。
さらに、3つのシステムトラブルに共通している大きな点は、イベントや外的要因に関係している点。最初は「三行合併」、次は「大震災」、今回は「コロナ禍」。つまり、通常でない状況に非常に弱いシステム/体制/会社ということが見えます。たぶん、思いっきり応用が利かない組織/会社なのでしょう。まさか、全行員=マニュアルで動く派遣さんなんでしょうか?

 

ヒューマンエラーは予防できるのか

2011年のシステム障害の原因の1つである「口座設定(上限設定)」を確認するヒューマンプロセスに問題があったとする説もあります。例えばダブルチェック(*6)をすれば防げたのではないか。などとする意見もあります。しかし、そもそもそのようなヒューマンエラーを0にすること自体が不可能です。それよりも、障害発生時に、どのように対処したら、被害が最小限に収まるかに力をそそぐほうが良いと思います。
この視点は、システム開発プロジェクトでも同じです。システム開発のトラブル、例えば進捗遅延、品質不良、技術的トラブルなどは、計画時にはまず「うまくいく」「発生しない」計画で立案されます。しかし、確実に発生します。矛盾しているようですが、現場の方々には分かってもらえると思います。要するに、想定外の事象、外的・内的要因に起因する、神様のサイコロが必ず振られる(*7)からです。これをうまい具合に塩梅(あんばい)するのは、プロジェクトマネジメントというものなのですが、それはまた別のテーマとして語りたいことです。

 

3度目のトラブル~ATM前での2時間待ち

休日勤務だった記者は28日昼前、昼食をとるために新潟市中央区の繁華街に向かった。正午ごろ、みずほ銀行新潟支店のATMコーナーに寄り、ATMに通帳を入れた。その直後、画面に「ただいま、お取り扱いできません」というメッセージが表示され、機械は停止した。預金通帳は中に吸い込まれたままだ。 休日の支店はシャッターが閉まって静まりかえっている。ATMわきにある係員呼び出し用のインターホンを使ってみたが、「ただいま大変混み合っています」との音声が繰り返されるばかり。スマートフォンで調べた緊急連絡先に電話しても同様の応答だった。

以上、朝日新聞デジタルの記事(https://www.asahi.com/articles/ASP313T0GP31UOHB004.html?iref=pc_rellink_02)です。記者が体験した2月28日のATM停止が書かれていました。かなりリアルな記事で、記者はカードではなく、通帳が飲み込まれたまま2時間を過ごしたらしい。怖い話です。筆者も、キャッシュカードで同様の事象を体験したことがあるのですが、カードが使えずに現金を下ろせないことは問題ありませんが(通帳や他のクレカで代替可能)、カード自体が返ってこないは、非常にまずいです。いまキャッシュカードには様々な機能がついています。その機能を利用して、日常生活をおくっている(例えば定期・クレジット・ポイントなど)人もたくさんいます。さらに、通帳など作成せず電子通帳にしてカード一枚の人も増えています。そもそも「カード1枚で。。。」というキャッチコピーでカードの勧誘や配布をしているのがカード会社や銀行です。そのカード自体がいきなり没収されてしまう。ATMを叩いても、戻ってこない、行員は出てこない。最悪です。「なんて日だ!(*8)
たぶん、銀行にも行員自体が出社していないのでしょう。政府が「緊急事態宣言」を出している期間ですから。テレワークをしているかは不明ですが、最小限の出社体制であることは間違いありません。しかし、行員でないとATMからカード/通帳は出せない、という仕組み(*9)は課題です。ニューノーマルにおけるジレンマです。さらに、係員呼び出しやコールセンターに繋がらないという事象は、顧客の恐怖感を煽る(あおる)ものです。チケットの入手申込で繋がらないこととは重要度が違います。金を入手する入口でとうせんぼされているようなものです。
そうですね、システム管理者的には、外的な障害で社内ネットワークが切断、「システムが使えないぞ」という嵐のようなコール(電話/メール)が発生している状況だといえるでしょうか?あ、絶対に二次災害が起こりますよね、次に起こるのはメールサーバ溢れ(あふれ)かな。。。

10年に一度のシステム障害

さて、2002年、2011年、2021年。ほぼ10年ごとに起こるみずほ銀行のシステム障害。次回は、2031年と予言したいところです。そのころに情報システム部に配属された行員は地獄かもしれない。「二度あることは三度ある」3度もあることは4度目もあります。この手のトラブルは周期があるのでしょう。
 トラブル発生→緊張+反省→緩みだす→もっと緩みだす→トラブル発生
のループ。みずほのみならず、どこの会社でも発生しているループです。
さらに、みずほ障害は、いつも他の障害を誘発することが多い気がします。今回も、関連しないだろう4つのシステム障害が立て続けに発生しています。システム自体は関連しないかもしれませんが、システム部は共通です。寝る間もなく、様々なシステムトラブルに対応するのは(たぶん)同じ人間(*10)です。どこの組織/部門でも、キーマンは少なく、なにかあったときに動ける人はいつも同じ。この2週間、本当に寝る間もなく対応/対処に追われていたと思います。

2021年2月28日~の2週間 みずほ銀行4つのシステム障害

日付 障害内容 原因/起因
2月28日 ・ATMトラブル(カード/通帳が返却されず)
・4000台超えのATMが機能停止
バッチ処理(データ更新)でのメモリー不足
3月3日 ・28拠点29台のATMが約3分に使えず ハードの故障によるシステムセンター間のネットワーク瞬断
3月7日 ・インターネットバンキングやATMで定期預金の預け入れが不能 カードローンのプログラムを更新する作業が原因
3月11日 ・約300件の国内他行向け外貨建て送金遅延 バックアップ(用のディスク装置)が不良→切り替え失敗→夜間バッチ未完了

図表7-3 2021年2月28日~の2週間 みずほ銀行4つのシステム障害 

 

そして、銀行のホームページには、謝罪の案内が告知されます。この謝罪が何回も続くのですから、企業としてはつらいことです。


図表7-4 みずほ謝罪

 

元役員の危険な脇アマ発言

以下の記事をご覧ください。

みずほは第三者を交え詳細を調べているが、ある幹部は「4件も相次いだのは気の緩みやシステムへの過信があったからかもしれない」と語る。4千億円超をかけて2019年夏に新システム(*11)へ移行。過去の大規模障害を踏まえ、3メガバンクでも最新式を導入していた。「稼働後は以前ほど銀行内でシステムが主要なテーマになっていないと感じる」と幹部は振り返る。移行時のことをよく知る元役員は2月末の障害について「システム構築に全力を傾け、稼働後の対応ノウハウ保持に手が回らなかった可能性がある。宝の持ち腐れであり、4千億をかけた代物を理解できていなかったのでは」と話す。その後も続く障害については「それぞれ原因が別であり、偶然としか言えない。みずほに根深い問題があるわけではないと思う」とした。

以上、朝日新聞デジタルの記事(https://www.asahi.com/articles/ASP3F6H50P3FULFA006.html)です。4つのシステム障害について、みずほ幹部や元役員が語ったものです。

この元役員の発言は、かなり問題があります。以下ピックアップします。

・対応ノウハウ保持に手が回らなかった可能性がある
・(4つのシステム障害は)原因が別であり、偶然
・みずほに根深い問題があるわけではない

保守・運用までしっかり引き継ぐのは、システム運用・保守をやっている人からすると当たり前のこと、手が回らなかったというのはかなりまずい言い訳です。
4つの障害の原因は別というのは、みんな理解しているし、しかし、だから偶然なんだというのは言い訳です。
前述しましたが、もし4つの障害の原因が別ならば、それが集中して同時期に発生したのは、「みずほ銀行」という発生個所に根深い原因があると想定されるのではないでしょうか?思いっきりわきの甘い発言ですし、もしこれが国会答弁ならば、野党からの突っ込みが入りまくるでしょう。文春砲もガンガン撃たれるかもしれません。
というよりも、この手の一カ所に集中・同時期というシステム障害は、「プロセス」や「組織」に問題があることが多々あります。例えば、再発防止策がピンポイントでしかなかったり(だから他で発生)、防止策の立案が遅かったり(だから対策前に継続的に発生)、キーマンが全集中(*12)で全稼働だったり(だから手が回らないし、人手不足)。

今回のようなシステムトラブルの防止策

毎回毎回、みずほ銀行のシステムトラブルになると、しっかり日経BP社などは動かないコンピュータで記事にしてくれます。書籍も発売されています。ありがたいことです。

日経BP社発売のみずほ銀行システム障害関連本

障害発生時期
(システムS時期)
書名 編集/著者 発売時期 ISBN-10 備考/コメント
2002/04 システム障害はなぜ起きたか~みずほの教訓 日経コンピュータ 2002年
6月
4822207838 歴史的な「システムトラブル本」。障害発生から、書籍発売までの期間が短く、衝撃を与えた。
2011/03 システム障害はなぜ二度起きたか みずほ、12年の教訓 日経コンピュータ 2011年
7月
4822262596  
2019/07 みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」 日経コンピュータ/
谷島宣之、大和田尚孝 他
2020年
2月
4296105353 みずほ「勘定系システム」の刷新・統合プロジェクト完了の軌跡。三度目の正直のタイトルが、無駄に。
内容は、新勘定系システム「MINORI」構築話だけでなく、前2冊の内容も含んでいる。

図表7-5 日経BP社のみずほ銀行システム障害関連本

筆者は、2002年/2011年トラブルもリアルに体験していますし、書籍に書かれていない業界のバックグラウンドもいろいろ聞いたりして知っていますが、この手のトラブルは組織文化を変えないと根絶は無理かと思っています。そして、第五夜のDXレポートで語ったように、企業文化の変換、真のDXはニューノーマルからニュータイプにならないと無理。いい例がこのみずほ事案です。何度でも何度でも何度でも(*13)、障害を起こし、止まるよ、です。
それよりも、システム障害は発生するものだと考えて、しっかりリカバリに力を注いで欲しい。新技術・新サービス、ついでに新業態や新常態の活用は、絶対にトラブルを引き起こします。旧から新に切り替えるのですから。その転換で発生するノイズやひずみ、副反応などを、上手く・早く・適切に処理することが、NEWなニューノーマル、ネクストニューノーマルではないでしょうか。
では良き眠りを(合掌)。

「夢をみるために毎朝僕は目覚めるのです」by村上春樹(2010年の村上春樹インタビュー集の名称)

 

 

    • 商標について
      本コラムに記載されている商品やサービスの名称は、関係各社の商標または商標登録です。文中では、(TM)や(R)を省略しているものもあります。
    • 引用・参照について
      本コラムで引用・参照した図表や文章については、明示して引用元・参照元を記載しております。
    • 著作権・免責について
      本コラムの著作権は、著作者に帰属します。本コラムは著者の主観に基づく情報の提供のみを目的としており、本コラムに記載された内容を用いた運用などは、読者の責任と判断においておこなってください。また、記載内容は、執筆時のものを使用しております。

 

*1 新型コロナウィルスの変異株。文字に書いてみると、「株」とか合ってるの?インフルエンザなんかも今後、「変異株」とか言うのかな、と思ったりします。2021年4月時点で、変異株は、だいたい3種類。イギリス型、南アフリカ型、ブラジル型の3種類がメジャーな変異株です。特徴は、例えばイギリス型は、オリジナル型に比べて、感染力が強いという点。 ちなみに、日本感染学会によると、変異”株”という呼称は正しく、変異”種”という呼称は誤っているらしい。つまり、新しいウィルスに変化したわけではなく、そもそもの属性に新しい属性が追加されたから、”株”だ、ということ。かなり強い語調で注意喚起しています。 【重要】変異「種」の誤用について(https://www.kansensho.or.jp/modules/news/index.php?content_id=221
また、近々ではインド変異株(二重変異株)が猛威を振るいつつあります。インドでは4月26日の死者数は2812人、新規感染者数は35万2991人、日本の新規感染者数(4月26日 3320人)並みの人数が死者数となっていますし、感染者数は30万超え。考えてみると、それくらい検査数も多いということですよね(感染者数<検査数)。人口が日本の10倍(インド約13億 日本は約1.2億)とはいえ、インドの検査体制/検査拠点の確保などは恐るべし。

*2 2021年4月12日から蔓延防止等重点措置が東京23区と八王子・立川・武蔵野・府中・調布・町田市に適用。うーん、昭島市や国分寺市、三鷹市は含まれていないんですよね。というか、コロナは市町村マップを考えて動いているわけではないのに、変な歯抜けがあるのが間抜けです。

*3 大阪・東京などへの「まん延防止等重点措置」適用時に、飲食店などが対策を実施しているかの確認、説明のための巡回を実施する組織。2人組でダークスーツ、アポなしで飲食店を訪問するらしい。なんのMOBだw

*4 勘定系システム。core banking system。銀行における勘定系システムとは、狭義には預金勘定元帳を処理し、為替、ATM、ネットワーク、対外システムとの接続を制御するシステムであり、銀行における基幹系システムの中核といえる。しかし、しばしば勘定系以外の情報系・国際系や対外系、インターネットバンキングや営業店端末などチャネル系システムを含んだ、銀行におけるオンラインシステム全般を指す言葉としても用いられ、しばしば混同して用いられることが多い(Wikiから)。(大手の)ITベンダーにとって、ハードウェア、ソフトウェア、運用など巨額の開発費用が見込まれるため、確実に受注したいシステム分野といえる。逆に、既存勘定系システムを、自社から他社にリプレースされた場合、営業を含めてかなり粛清の嵐が吹き荒れる(かもしれない)。

*5 銀行の合併などに伴う勘定系システムの統合ですが、一般的には3つの方法があります。1.片方のシステムに併せる(片寄せ)。2.新規に作成する。 3.既存(もしくは新規の)共同システムへの移行。 3.は主にしんきんや地銀の場合が多いです。

*6 ダブルチェック、クロスチェックなどとも言います。確認作業などの基本動作とも言えます。また、再発防止として、よく検討・実施されます。しかし、効果は微妙。これは人間心理も問題でもあるのですが、2番目にチェックする人は「すでに別の人がチェックしている」という前提で、無意識に「チェックOK」と判断することが多いのも理由です。もし、効果的に実行するのであれば、チェックする人は1番目/2番目の順番を見せずに、チェックさせるしかない。また、このダブルチェックは、単純に作業を×2するだけなので、作業コストが2倍になるわりには、(同じ作業の繰り返しになり)作業効率が悪いものになります。ま、最初からダブルチェックにしとけよ、という話もありますが、改善としてトリプルチェックにするのは、本当に何も考えていない施策といえます。

*7 「神はサイコロを振らない」は、アインシュタインの言葉であり、観測される現象が偶然に選ばれるという量子力学のあいまいさを批判したもの。つまり、「全ては法則や規則に基づいて理解することができる」が、科学でまだ解明されていないものがあるため「サイコロ」という確率によって事象が塩梅(あんばい)されるように見える、という考え。 本文的には、「サイコロ」のように見えますが、担当者の気分・体調、外的な情報、人間関係などの無数の確定状況によって、結果は決まっている、と考えること、なのでしょう。

*8 「なんて日だ」はバイきんぐ小峠の持ちネタ。

*9 行員でないとATMからカードは出せない仕組み。類似事例に、会社社内でないと押印できない、障害対応のためにデータセンターに社員がいないとログインできない、パスワードエラーを解除するために(リモートアクセスではなく)有線でログインしないと解除できない、など多々あります。セキュリティとの住み分けの問題です。

*10 この手のシステム障害は、技術的には全く違う組織/会社なのですが、統括するキーマンは案外同じ人だったりします。要するに、ある適度、内/外の対応ができて、いろんな分野の技術的知識を持つ人って希少なのです。ついでに、業務の流れや関連性がわかる人でないと、対処やプライオリティ付けが難しい。

*11 「みずほ銀行システム統合、苦闘の19年史」(日経BP)によると、元請けがみずほ情報総研で、その一次委託先が約70~80社、二次委託・賛辞委託先を含めて約1000社。言語はCOBOL,JAVA,Cなど(開発ツール使用)のようです。投資額が4000億台の半ば、開発規模は35万人月と言われています。

*12 「全集中」は「鬼滅の刃」を知ったかぶりできるワードの1つ。とりあえず、「全集中」と言っておけば今風と思われる。また、どう見ても「鬼滅」を見ていないようなおっさんが「全集中!」などと叫んだら、とりあえず生暖かい目で見てあげてください。

*13 DREAMS COME TRUE「何度でも」から。「何度でも」はフジテレビ系ドラマ「救命病棟24時」シーズン3(2005年)の主題歌でした。阪神淡路大震災(1905年)の10年後という意味で、首都圏直下地震の後の診療体制をテーマにしたものだったらしいのですが、その5年後に東日本大震災(2011年)が。。。救命病棟24時の次期テーマとして、感染症対策で人手不足/混乱している救急病棟をテーマにして欲しい。

ニューノーマルで悩む管理者の夜
2020年に発生したいわゆる「コロナ」のため、日本人のみな らず全世界の人々の生活は一変した(と言われています)。その 変化を体言するキーワードが、「ニューノーマル」。新常態と訳 すべきものですが、このニューノーマルに対応するために、ビジ ネスマン、エンジニア、家庭の主婦まで、日々あたふたする姿が 見られます。この珍常態を、システム管理者目線でゆるーく語っ ていこうと思います。
記事一覧へ
筆者紹介

司馬紅太郎(しば こうたろう)
大手IT会社に所属するPM兼SE兼何でも屋。趣味で執筆も行う。
代表作は「空想プロジェクトマネジメント読本」(技術評論社、2005年)、「ニッポンエンジニア転職図鑑』(幻冬舎メディアコンサルティング、2009年)など。2019年発売した「IT業界の病理学」(技術評論社)は2019年11月にAmazonでカテゴリー別ランキング3部門1位、総合150位まで獲得した迷書。
TW @shiba_koutaro

コメントを書く

未ログイン: ログインする

コメント: ログイン(会員登録)すると、コメントを書き込むことができます。

  • 新着Q&A
  • 最新の回答
回答数:22019年11月12日

システム管理者認定講座<全コース共通>試験のみ受験希望の方はこちら

動画で見るセミナー
動画で見るセミナー

2021年7月 第15回システム管理者の会 感謝の日イベントの開会のご挨拶の様子を掲載いたします。

個人情報保護方針
運営者につい て
利用規約
サイトマップ