知人も、入金されない、振り込みできないなどで、
大いに、世間を賑わした全銀のトラブル、
その原因報告が、ひっそりとホームページに。
詳細は、全銀のホームページを見てもらった方が良いし、
勝手な原因解釈図などを自前で作っても、
あくまで推測でしかないので、ここでは書きませんよ。
高齢技術者のただの独り言だと思って読んでもらうと大変助かります。
ネットなどでは、別な『でかいシステム』に例えて、
全部はテストできないという話もちらほら見受けましたが、
そこは大きな問題点ではない。
じゃ、何が問題点かと言えば？
いくつか考察してみました。
運用の問題点
ある程度システムに問題があっても、通常は運用で回避（するはずなんだけど）。
なんで正系・副系同時切替なの？
これほど大きいシステムならば、正副が準備されているはず。
それこそ、日にちを変えて、正を切り替えて稼働確認して、副を切り替える。
障害で、副だけの縮退環境で動作させるにせよ、
ここまで大きくならなかったと思われる。
というか、正正・正副・副正・副副の4wayとかになってないのね。
切戻準備はなかったの？
正副の同時期切替になると、移行計画書に、切戻計画なかったの？
いくら、EOLだからといって、切戻は必要だよね？
報告書を読んでいると、どうも、システムとしては、
ハードとソフト一体のようなので、尚更必要なはず。
移行日のまずさ
わざわざ、10日なんて、お金の流通が上がる日を選ばなくても。
もしかして、月末と25日だけが集中する日とか思ってた？
まぁ、年末は、銀行は、自前のシステムを切り替えたりで忙しいので、
年末移行は難しかったのかもね。
開発の問題点
うーん、どうも、横串テスト（本番前全体テスト）が不足してるような
結合テストしたの？
要約すると、4テーブルのうち、1テーブルを拡張したけど、
それに併せたメモリー拡張してませんでした、だからエラー出たよ。
テストしたときは、1テーブル毎だったので、問題なかったです。
え？本番前の結合テストしなかったの？？
それに、拡張した範囲もわかっているので、最初と最後の検索してなかったの？？
一番最初に、結合して最後までアクセス出来るって確認するよね。
高速性の担保のため、低水準言語利用してると思うけど
今回の話だと、本番環境起動後に、メモリアロケートした時点で、
メモリー破壊が発生するので、OS側で検知しないのかな？
クライアントゆるふわOSでもないので、何らかの検知方法は無いのかな？
アロケートが番地していなのか、OS任せによるものなのかで、変わってくるけど、
これだけのシステムになると、仮想メモリーなんか使うと、超絶遅くなるから、
きっちりしたサイジングが逆に徒になってるのかもね。
今回、全銀の話を他山の石として、自分の開発でも気をつけないと。
最後まで読んでいただきありがとうございます。
本内容については、公開資料からのあくまで、個人的推測ですので、
不快に思われた方は申し訳ないです。