みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。
そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。
技術的な話
銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。
トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（いまも？）モダンなアーキテクチャだし、粗結合に出来ていて、全体としては真っ当な設計に見える。
入力のゲートウェイには処理区画という名前がついていて、それぞれ三重に多重化された上で30の処理区画（要するにKubernetesで言うpodみたいなものか）に分かれている。感心したのは、処理区画にはサーキットブレーカーがついていて、ここを経由して流入するトラフィックのエラー率が高まると、サーキットブレーカーが自動的に処理区画を閉塞して負荷を下げる仕組みになっているのだそうだ。こういうのはわりとモダンな考え方だ。
障害の経緯
障害発生に至るドミノ倒しの技術的な側面からの経緯は、分かりみしかなく、全く他人事とは思えない。
- 障害発生の前日に当日問題を起こすシステムの一つからモニタリングに警告が上がるが、見逃される(p.50)。想像だが、これだけ大規模なシステムの事だから、恒常的に色々な警告が上がっていて、全部をちゃんと診ていくのは無理な状態になっていたのではないだろうか。僕も、Launchableのシステムで「この警告は大体放っておくと直るから無視しよう」というのはある。
- 障害が発生してシステムのドミノ倒しが始まると、一時間に6400もの警告が上がって人間の処理能力を超えてモニタリングの意味が失われる(p.74)。この日一日では90000件のアラートが上がったらしい。大規模システムモニタリングの典型的な問題。世の中の人はこれをどうやって解決しているのか。
- 折角サーキットブレーカーが機能しはじめてトラフィックが遮断されはじめたのに、手動でブレーカーが入らないようにオーバーライドして劇的に状況を悪化させてしまう(p.51)。アラートが飛んできたら閾値をあげてアラートが出ないようにする、僕もやったことある…!! ちょっとだけ閾値を上げたら乗り切れるんじゃないかとつい思ってしまうんだよね。
後出しジャンケン的に言えば、日曜日に対応体制が手薄な中での障害対応手順(p.76)としては無理に攻めてサービスを稼働させたままで早期障害復旧を狙うよりは、安全側に倒してサービスや障害部位を切り離して二次災害を防ぐ方が良かっただろうなと思うが、ATMを止めるというのはやはり大きな決断なのだろう。現場のOpsとしては大した事のない障害だからうまくすれば乗り切れるはず…と楽観的になってしまう気持ちは分かる。
組織の話
情報伝達
システム障害を受けてみずほの内部でのその情報がどのように伝達されていったのかというのが面白い(p.56)。
- 9:50am 障害発生
- 10am ATMから繋がる電話を受けるATMコールセンターがパンクして90%の電話が繋がらなくなる
- 10:15am Opsから障害発生の一報がメールされる
- 11am-12am 危機管理の司令塔に様々なルートから情報が入って障害規模が大きいことが把握される
- 2pm 関係各部門の部長会が招集される
- 2:30pm 部長会で対応方針が決定されてこれ以後場当たりでない組織だった対応が始まる
- 5pm 非常対策プロジェクトチームが初会合
報告書を読むと、実質的な対応方針の決定は部長会で決まったように見えるが、そうすると非常対策プロジェクトチームというのが何なのかよくわからない。事前に準備された危機対策マニュアル的にはこっちが非常時の意思決定機関っぽいのだが(p.82)、そうだとするとそれが5pmからというのはあまりに遅すぎる。何が起こってどう対処しているのかを経営陣に報告する場のようにも見えるので(p.57)、そうだとしたら事後報告のための場だから5pmでも何の不思議もない。
自分の体験
僕も以前0-day攻撃に週末対処しなくてはいけなくなった事がある。技術の人は攻撃方法を把握して修正を開発してテストして出荷しないといけないし、営業はお客さんに連絡をしないといけないし、広報は外向けに何をどう発信するか気になるし、社長は何が起こっているか把握したい…という感じで、色々な人が色々な情報をリアルタイムに必要とするのがこういう火事場の特徴だ。
僕はこの経験から、メールはこういうリアルタイムで変化する情報を多くの異なるステークホルダーに伝えるのは向いていないと学んだ。ステークホルダーが多様すぎて必ず帯に短し襷に長しになるし、それぞれのメールが自己完結するようにすると長くなりすぎるし、差分にすると新しく参加してくる人には意味不明になる。
プッシュ方式のメールが駄目なら、必要に応じて詳しい人に教えてもらうプル方式ではどうかというと、それも駄目だ。火事場では情報は少数の人に集まるので、みんなが同じ人から何かをき出そうとする事になってしまって、情報伝達だけで日が暮れてしまい、肝心の障害対応が出来ない。また、伝言ゲームで細かい内容が変質してしまったりする。
じゃあ何がいいかというと、Google Docをリアルタイムに編集していく、またはWikiのページを使ってリアルタイムに情報を更新していくのが良かった。あえて古い記録は残さずに上書きしていくことで、構造だって常に最新の情報だけが見られるようになってとても良かった。そして、密に連携して働く人達の間ではチャットが良い。
もっとも、これは数百人規模の会社の話なので、みずほ銀行の大きさになるとこれでうまくいくのかもよくわからない。火事場では自発的に分業が行われるが、大きい会社で必要な高度な役割分担が自発的に組織化されるかというと難しそうだ。
報告書中には色々な人が互いに電話を掛けたりメールで問い合わせをして、お互いに捕まえられない様子が描写される。日曜日だから電話じゃないと捕まえられないのかもしれないが、チャットとかGoogle Doc / Wiki 的なコミュニケーション・システムは存在してのだろうか。会議はしたらいいが、会議だけが情報伝達手段では駄目だと思う。
原因究明 vs 影響究明
障害発生から実質的な対策決定が行われるまでの４時間の時間が悔やまれる。
これについては鋭い視点があって、Opsは障害の原因究明と復旧に全力を注いでいたのだが、ビジネス側が必要なのはこの障害の影響範囲がどのくらいであるかという方だ(p.79)。障害規模が分からないと、復旧を待つべきなのか諦めて被害を最小限に抑えるべきなのか、判断が出来ない。Opsは顧客への影響を示す指標を集めるのが遅れた。これは身につまされた。
確かに僕の職場でも、インシデント対応中は技術スタッフが中心になってサービスを復元する事に力を入れてしまいがちだが、それだと会社の他の人の力を有効に使うことが出来ない。被害の範囲が分かれば、別な部門の人達にも色々な事が出来るようになる。
この視点は今後大事にしようと思った。
障害情報を受けての各部門の対応
全容の分からない、先の見えない、現在進行形のシステム障害を受けて、みずの各部門がどのように対応したかという話が興味深い。特に前出の情報共有のタイムラインと比べながら見ると、決断や行動に至った現場の人の自主性が分かり、味わい深い。
ATMセンター
ATMからの電話を受け付けるATMセンター。カードを食われてしまったお客さんからパンクする位電話が掛かって来ているのに、手順書通り遠隔でATMからカードを吐き出させる操作をするだけでATMを停めなかったので、同じATMを次の人が使おうとするとまたカードが食われるという、沈みゆく船の中でバケツで水を汲み出すような虚しい作業をする。想像だが、自発的に何かをやれるような立場の強い部門ではなかったのだろう。お客さんの怒りを直接浴びる立場だっただろうし、悲惨の一語。事後のPTSDケアが必要なんじゃないだろうか。
リテールバンキング
個人向けの商売を指揮するリテールバンキングの部門。ここは部長会の報告を受けて店舗に職員の出勤をとりあえず指示するも、集まった人が何をすべきかの対応策を伝えたのは5:30pm。ATMセンターよりは権限がありそうなのでこの主体性のなさは残念。多分、司令塔の意思決定を待っていたのだろう。足並みを揃えようとしたらそういう事になるからね。
お客さんへの影響を全体的に考えるという視点は一番もっていそうだけど。
コールセンター
ここも障害発生後直ぐに電話がパンク。でも、ATMセンターと違って、ここは12:30の段階で、だから情報がないうちに、カードや通帳は後でちゃんと返却するからお客さんはとにかく帰ってもらうという対応を自主的に始める。これは素晴らしい。ATMセンターとの差が光る。もっとも、この対応は電話が繋がった人にしか出来ないので、90%の電話が繋がらない状態では待受メッセージなどにこれを入れる必要があると思うのだが、そこまでは至らなかった模様。
ウェブバンキング
ウェブバンキングも反応が鈍く、障害発生から３時間後になってようやく障害通知をトップページに出して、当該機能を停めたのは更にその一時間後。これはかなりお寒い。自分達のところでモニタリングとかしていなかったっぽいので、自社開発のサービスを運用する技術スタッフがいるというより企画や経営の人しかいない部門で、運用は別部門任せだったんだろう。
広報
SNS経由で11amには障害発生を認識して、多分その規模感も感じていたんじゃないか。大企業では社内コミュニケーションより社外コミュニケーションの方が早いという典型的な例。悲惨なのは、障害発生を告知して、影響を受けたお客さんへのメッセージを載せようとするのだが、その文面を作るはずの部門が応答せず、折角問題を早く認識したのに障害告知が乗せられたのが1pm過ぎで、お客さんの誘導メッセージを配信できたのが4pm。広報ってやっぱりどこでも立場が弱いんだ…。でも、こういう状況で無視されたら自発的に勝手に文面を作って勝手に公開できないものなのだろうか。長いこと虐げられているとそういう自発性も奪われてしまうのだろうな。
店舗
46もの店舗で現場の判断で職員が招集され、162の店舗で自発的にATMを停止(p.86)。全480拠点とあるからこれは結構な割合だ。更に一部の店舗では、立ち往生する顧客に椅子や飲み物を用意したり店舗外ATMを巡回するなどの取り組みがされたそうだ。店舗レベルではそれなりの自主裁量がある様子。これは表彰されるべき。
経営陣
なんと頭取が最初に障害発生を知るのは1:30pmにニュースで(p.88)。副頭取が知るのは1:40pmに部下からの電話で(p.39)。まあお偉いさんがリアルタイムで状況を知ったって何か役に立つわけじゃないので現場の人としては後回しになりがちなのは分かるが、如何に下の人にお飾りだと思われているかを雄弁に物語る寂しいエピソード。僕が頭取だったら恥ずかしさで外を歩けなくなりそうだ。
自主性
現場が自主的に何かしなかったのをあげつらう事も出来るし、調査報告書にもそういうトーンもあるが、大きな会社では足並みを揃えてやらないとそれぞれの部署が自主性の名のもとにバラバラな事をやったらそれはそれで負の側面もあるだろう。
ATMセンターとコールセンターの対応が違うのがいい例。ATMの脇の電話をとって電話したらカードを出してもらえ、携帯でコールセンターを調べて電話したら帰れと言われるわけだ。どっちが正しいの？ってなる。
もしくは、リテールバンキングが店舗にある指示を出したのに、その一時間後に部長会で別な方針が決まったりとかなっていたらさらにドミノ倒しが拡大するでしょ。
むしろ非常対策プロジェクトチームの招集をまたずに部長会で実質的な方針を決定した辺り、現場が事前に策定された危機管理体制よりうまくやったのではないかという気さえする。また店舗の取り組みはとても良かった。
デザインの失敗
非常時の失敗というのは結局平時の備えの不足である。僕はこれをデザインの失敗と呼びたい。プロダクトの、もしくは組織の。
ATMカードを食ってしまう仕様
MINORIへのゲートウェイが死んでバックエンドにアクセス出来なくなった時にATMがカードと通帳を食ってしまう仕様は製品デザインの失敗という他はない。
一応調査報告書には、どうしてこういう挙動が選ばれたかという説明があって、すなわち、お客のデータの整合性が壊れている疑いがあるので追加で取引されるのを防ぐため。でも、本障害以前の数年間に大規模なカード取り込み障害が二度も発生している(p.69)ので、この仕様が大規模障害と組み合わさるとどういう悲惨な事態を招くかはよく分かっているはず。
これは残念過ぎる。実際、今回の障害を受けての対策の一番手はこの挙動を変更する事になっている。三度目の正直。
縦深防御の失敗
ATMカードを食うデザインの失敗は縦深防御の失敗でもある。ATMバックエンドが死んだらATMはどのように振る舞うべきか。依存するサービスが死んだら自分のサービスはどう振る舞うべきか、これはエンジニアリングの設計の大事な要素だ。火事が起こっても燃え広がらないようにする仕組み。
サーキットブレーカーが縦深防御の失敗のもう一例だ。一部を殺して他を活かす。せっかくそういう機能がついていながら、手動でブレーカーを停めて全体を燃やしてしまったのはとても残念だ。
育児的ソフトウェア開発
僕は「育児的ソフトウェア開発」というテーマであちこちで発表している。サービスを子に見立て、それを開発するチームを親に見立て、子供を育てるプロセスは親が育つプロセスでもあって、親と子の関係は簡単には切り離せないものですよ、という話。
この調査報告書でも、MINORIが開発フェーズから運用フェーズに移行する中で、開発体制が縮小されて、システムに詳しい人達が異動されたり退職したりした結果、技術者に蓄積された知識が減って、それが障害発生や原因究明の遅れを招いた、という話が出てくる(p.125)。
育児的なソフトウェア開発的観点からいえば、サービスは永遠に運用であるので開発チームを解体していはいけないという考えになるので、この点、我が意を得た思いだ。
現実
危機管理やシステム開発や運用に必要なリソースが投下されない理由の背景として、個人向けの リテールバンキングは収益性が低い部門だから、と調査報告書にはさらっと書いてある(p.115)。
なるほど、確かに企業としては利益のない部門に投資はしづらいのが現実だ。となると、リテールバンキングはうまく行っても利益は出ないし、炎上すると銀行の信用を傷つける、かといって辞めるわけにもいかないというお荷物以外の何者でもない存在という事になろう。
この問題はメガバンクに共通の問題だから、近い未来に３つのメガバンクのリテール部門がスピンオフされて合併して裏は一つのシステムを３つのブランドで売る…みたいな体制になったりして。
まとめ
中の人は本当に大変だったと思うので、まずご苦労さまといいたい。こういう調査報告書をちゃんと作って公開してくれてありがとう。とても学びが多かった。
あなたがたの中で罪のない者が、まずこの女に石を投げつけるがよい
— ヨハネによる福音書