運の良さは否定しないけど、単なる幸運なわけがないだろ。ふざけんな。
そもそも、今回のシステム障害の発端になった技術者のミスは、あまりにも「あるあるの勘違い」なんじゃないか。全銀システムと各金融機関のシステムをつなぐ中継コンピューターのOS更改に伴い「金融機関名テーブル」のサイズが拡張したが、担当した技術者がメモリー上に必要な作業領域を十分に確保していなかった。その結果、他のプログラムによってデータが一部上書きされて破損した――。これが事の発端だが、ではなぜ担当技術者はそんなミスを犯したのか、そしてなぜ誰も気がつかずにスルーしてしまったのか。
12月の会見での説明によると、原因はまさに担当技術者の勘違いだ。金融機関名テーブルのほか、金融機関名テーブルの検索を高速化するための3つの「インデックステーブル」をまとめてメモリー上の作業領域に展開する生成プログラムの仕様を誤解して、各テーブルがそれぞれ展開されるものと思い込んでしまった。そのため、サイズを拡張した金融機関名テーブルが作業領域に収まったことをもって大丈夫と判断したようで、生成プログラムが確保すべき作業領域を拡張しなかったとのことだ。
どういうつもりでこの雑文を書いたのかは知らないけど、今まで50年無事故だったシステム運用と今回の技術者の設計ミスは関係ない。運用と設計の違いもわからないやつが記事を書くなよ。システムを無事故で運用するためにはもちろん稼働前には設計・製造を経る。しかし、製造・テストを経て本番運用に入ったらそこからは毎営業日に稼働させていく。
マシンの周辺には神棚を設けたりお札貼ったり御神酒をお供えしたり大変なんだぞ。
実際にデータセンタに出入りしている人で、見掛けたことある人は多いと思う。どうでもいいシステムではこういうことしないけど、ミッションクリティカルなシステムだとよく見掛ける。
という神頼みはもちろんだが、当然障害を起こさないように設計もしてインプリメントしている。もし小規模な障害がデータセンタ内で起きたとしても利用者に分からないレベルでリカバリできるようにも設計もしているしインプリメントもしている。その上で運用ミスが無いように手順を厳密に定め、人的ミスが極小化するように自動化したりフェイルセーフ、フールプルーフを組み込んでいる。なんなら、鉄道などで見掛けるように指差し確認や操作によってはダブルチェック(2人以上でチェック)も組み込んでいる。
上記引用した文で(いや、全文読んでも)そういう運用設計などを考慮して書いた部分は出てこない。つまり、運用エアプである。舐めすぎ。
また、元々稼働していたシステム内に今回の障害を発生させうる設計や実装があった(つまり障害要因を内包していた)というのであれば、それを指摘すべきである。
今回のシステム障害の発端になった技術者のミスは、あまりにも「あるあるの勘違い」なんじゃないか。
今回の障害を引き起こした設計担当者の勘違いは、元々稼働していたシステム内に今回の障害を発生させうる設計や実装があったという指摘ではないことが明白である。
50年トラブル無しはもちろん幸運は必要で、メイン電源障害時にバックアップ電源まで飛ぶとか、主要部分のRAIDコントローラーが死ぬ(RAID外でさらに二重化みたいにしないとどうしようもない)とか、二重三重の障害みたいな不運は無かったということは言える。その点では幸運は確かにある。
でも、障害が起きないように設計し運用してきたことを単なる幸運で片付けるのであれば、それはアタマワルイ。しかも今回起きた障害はずーっと障害なく運用してきたシステムと全く同じではなく新バージョンである。新バージョンの設計のミスは間違いないが、それをバージョンが異なる既存バージョンを「単なる幸運」と認定する材料には使えない。
まあ、こうやって微炎上するのがお仕事らしいのでこれ以上は突っ込んでも仕方ないだろう。いつもガチ炎上するほどの緻密さが無い。はてブあたりでチョロチョロ燃える程度の着火力しかない。
しかしまあ、本当に雑だよな。炎上する着火力にも欠けるとは。もう少し物を知っている人に書かせるか(当人はライターではなく編集者を名乗っている)、聞いてから書いたら？
