テーマ：迂回システムを構築できるか
■なにげなニュース
すでに記憶から抜け落ちているヒトもいるかもしれないが全銀のシステム障害は今まで起きたことがないので少し驚いた。何が原因だろうと気になっていたのだが、多少解説めいた記事があったので引用する。
○NTTデータ、全銀ネットの障害対応を説明–根本原因にめども「包括的な点検が必要」
全銀ネットの10月18日の発表によると、障害はRCで処理する金融機関の送金／着金の手数料に関連した「内国為替制度運営費」で発生した。ここでの処理方法の1つに「あらかじめRCに設定されたテーブルを参照してRCが電文に金額を入力」があり、その処理にエラーが発生してRCが異常終了し、電文の送受信に影響が生じた。
https://japan.zdnet.com/article/35211137/
即時処理のためにキャッシュを使っていたのが一つの要因のようだ。ただ、この記事はある程度詳しく書かれているが正直本当のところは分からない。
そうこうしているうちに新しい障害のニュースが飛び込んできた。
○クレジットカード決済のシステム障害が復旧 コンビニなど全国で影響
2023/11/11
クレジットカードの決済ができないトラブルが11日、全国で発生した。障害は夕方に発生し、夜に復旧した。決済システムを運営する「日本カードネットワーク」のシステムでトラブルが起きたとされる。
https://mainichi.jp/articles/20231111/k00/00m/020/255000c
ネットワークを経由して多くのサービスを享受する現代社会ではインフラが障害を起こすと云うことは他のライフライン（電気ガスなどのエネルギー、交通インフラ）が使えなくなることを意味しており重大である。
■頻繁に起きるシステム障害
近年の事故で云えば、航空会社のシステムダウン、マイクロソフトなどのWWEBサービスの停止など頻繁に起きている印象がある。これらは防ぐことはできないのだろうか。
一言で言えばシステムにはバグが潜在的に含まれることが必然であり、これを防ぐことはできない。
システム開発が持つ潜在的なリスクは、設計と実装が必ずしも一致しないことがあり得ることである。図面通りに加工ずるものであれば「計測」すれば分かる。コンピュータプログラムについて云えば「テスト」がこれにあたる。とはいえテスト仕様書自体もヒトが関わるので万全にはならない。巨大なシステムであればテスト項目自体が天文学的になる。
一般に、バグがないように作り込むことも重要なのだが、意図しない条件やバグが発生したときの回避ルート(Catch try)を埋め込むことが望ましいが、コレモテイド問題である。私が昔実装に関わっていたときには70％のコードはエラー処理だった。つまり普通は通らない。したがってテストなども疎かになりがちだ。
多くのシステム障害が、機器の交換、OSのバージョンアップ、システムの一部改修など従来であればパスしないであろうパスを取ることで起きる傾向がある。しかし、上記のようにテスト項目が膨大にあり、時間的な制約もある中で「万全」は難しい。
■全てに対応できるわけではない
ではどうするかと云えば、それほど解決策は多くはない。
（1）不完全情報を修復する
パリティチェックと同じように、情報がかけているかどうかを判定できるようにするとともに、完全情報に戻せるようにする。DNAのらせん構造が参考になるだろう。
（2）完全情報を推測する
これまでのデータ処理を蓄積しておき、処理の流れから類似の情報を選択し、可能性の高い順から提示し、「仮」の処理を行なう。ある程度進行してから正しいと確信できてから処理を確定させる。
しかし、こうしたシステムはユーザーとのインタラクティブな部分では可能であろうが、ゴーサインが出てしまった処理に対応することはできないだろう。いつか「もしかしたら間違っているかもしれない」ことを前提として自己修復できる、あるいは引き返すことができるメカニズムが必要だ。いつかそのようなソフトウエア開発ができるといいなと思う。
では現実的には銅なのかと云えば
（3）迂回システムを準備する
何か意図しない動作をしたら迂回システムで代替できるようにする。
（4）障害内容をレポートできるようにする
どうも最近のニュースを見ていると、原因の特定に時間がかかっているように見える。これを即応できるようにメッセージシステムを確立する。
残念だが私にはノウハウはないので具体性に欠けるが、可能だと信じている。
どうだろう。
（2023/11/12）