開発言語一つを責めればなんとかなる話じゃなかった。金曜日までにおおよそ明らかにされるかと思ったけどまだらしい。
全銀ネットのシステム障害の件、きちんと報告が出ている。
また、ニュースも出ている。XTechも消えることあるから不安だけど一応貼っておく。
全銀ネットのPDFは18日付けだが、このニュースは19日付け。
こちらは少し情報が古い。
やっぱりCOBOLうんぬん関係なかった。
中継コンピュータ(RC) の不具合であり、プレスリリースで公開されたRCにCOBOLを使っている旨の記載はない。会見での質問でもRCの造りについての回答はUNIXマシンでCとかJavaとかって話だったっけ。あくまでも前回貼ったCOBOLを置き換えるという話はメインフレームをやめる話とリンクしている。
さあ、COBOLうんぬんで騒いだ奴らどう落とし前付ける？付けないよな。もう忘れているかもしれない。そういう残念な人たちに構っても仕方ないので、ここからはトラブルシュート／障害回復の話を書く。
今回は定常的に動作していたシステムではなく、システム移行の際に起きている。つまり、今まで問題無く動いていたシステムではなく別のシステムに切り替えている。このような場合、切り戻しの準備もされている。元の安定稼働していた側に戻せばひとまず障害状態から抜けることができる。
しかし、今回全銀ネットは「切り戻しを選択しなかった」と明言している。普通に考えると準備していないはずはないので、切り戻せなかったのではなく意図して切り戻さなかった。ここはこれから明らかにされるところだろう。切り戻したかったのに切り戻せないのであれば準備のミスである。今は原因究明を進めてもらう段階で、責めるタイミングではない。
オレが全体統括ならの仮定を書く。
14行が移行対象で10行で障害発生である。オレなら障害発生銀行の半分は切り戻しを指示する。単純ランダム選択ではなく、やっぱり大手は切り戻し対象にしちゃうかな。人間弱いもので、とりあえず大きな問題は回避したい。一方で小規模行ならトランザクション数も少ないし、それにともなう被影響顧客数も少ないので色々試しやすい。銀行へのお願いもしやすいかもしれない。
全銀ネットが全て切り戻ししない判断をした裏はまだわからないので、このように分けて対応することができない構造だったのかもしれない。切り戻しする／しないの話もあるが、分けて対応できない構造だったとすれば「ちょっと設計にセンスが無い」って話になる。どんなに頑張っても障害は発生するものなので、その障害発生時に障害を極小化するための設計は必要である。実際にはその障害箇所極小化するということは物理の話になる可能性が高い。物理的にリソースを分けて準備するということは、お金が掛かるのでどこまでやるかの最終判断は設計じゃなく経営ということになるが。
設計段階から考えていないなら馬鹿なんだけど、今まで問題無く稼働させてきた全銀ネットだし、それはあまり考えたくない。担当者が変わると劣化することはあるのでなんとも言えないけど。
今回のようなシステム移行に伴う障害の場合、システム移行作業なので現場には主要メンバーが詰めている。それでも である。色んなことが分かるメンバーがそれぞれそろっているのになぜ長時間化したのか。
まだ全てが明確になっていない状況なので想像で書くしかないのだが、今まではずっと問題無く動かしてきていたので障害対応が得意なトップではなかったのではないか。障害発生時にどうやって解決するのかを考えた時、技術的な能力が一番優れた人間に判断させるしかない。その「技術的な能力が一番優れた人間」は体制や役職的には一番上ではないかもしれない。でも、いちいちお伺い立てているようなシチュエーションではないわけで、「あいつが言う通り動け」って現場のトップが言えるかどうか、いやそもそもその「技術的な能力が一番優れた人間」人員選定をトップができるかに掛かっている。
Don't shoot the messenger.という言葉がある。訳は「悪い知らせを伝えた人を責めるな」。障害が起きてうまくいっていない時、必要なのは何が問題なのかをいち早く知ること。それが障害回復のための第一歩である。ダメなトップは悪い情報を集めている段階でもShoot the messengerをやっちゃうんだよね。そりゃ時間掛かるわ。もちろん今回の件がそうだったとは言っていない。それはこれから明らかになるはず。
今回の全銀ネットの件とは規模的には比べものにならないけど、国際問題になることを覚悟した件がある。
この時に現場にいたのは大ボスではなく中ボスだった。もう稼働して10日くらい経ってたし。元請社もそこそこ偉い人いたけどトップはいない。でも起きている障害は＜なんとかならないと国際問題＞である。結局、オレが立場も弁えず*1「うっせえ、黙っとけ」って言えるタイプだったから元請社も中ボスも仕切ってなんとかなった(なんとかしたとまでは能動的ではない)けど、普通の人は弁えちゃうからなかなか情報も上がらないしすぐに動かない。
きちんとした組織だと、上意下達で通常時にはうまく動くんだけど、障害対策やっているときは動きが悪くなるんだよね。まあそこらへんは全銀ネットについてはわかんないけど。
あと書いておきたいのは、障害回復とは直接関係ないけどココ。
RCは2台の冗長構成としていたが、同じ機能に問題があったためフェールセーフも働かなかった。更改作業の対象が14行だったにもかかわらずトラブルに見舞われたのが10行だったのは、内国為替制度運営費の入力方法が2パターンあったことに起因する。（1）金融機関側であらかじめ電文に金額を入力してRCに送信する方法、（2）RCが保有するテーブルを参照してRCが電文に金額を入力する方法、である。今回、トラブルが生じたのは（2）の方法を採用していた金融機関だった。
金融については分野ごとにトランザクションの特徴があって、銀行系は短くて多い証券系も短くて多い保険は長くて多くないというものがある。振込とか買い注文とか保険の契約とかを思い浮かべればわかるはず。
(2)の方法を採用していた銀行に三菱系2行があったというのは意外。(1)パターンで自前で作っちゃっうほうがラクなような気もするけど、そうできなかった(しなかった)理由はなんだろう。
ちょっと取り留めなくなったけど、トラブルシュートの現場は大変ですよ。
*1:わきまえず
