トラブルの帰結 ― 2023/10/12 23:20:05
全銀ネットの銀行間送金システム障害は案外単純な話で、
RC(リレーコンピュータ)更新時の
単体テストや結合テストのケース漏れです.
ここから始まった障害の連鎖が、銀行間全体の流れに波及しました.
送金元A銀行---RC---全銀---RC---送金先B銀行
というデータの流れで、A銀行側RCまたはB銀行側RCでトラブったため
データが未着になりました.
RCには全銀側で用意した手数料をチェックする処理がありましたが
対象となる14行中の11行はこれを使用し
残りの3行は独自に送金手数料を計算していたので使用せず
ここで明暗が分かれました.
障害発生時、更新前状態に切り戻さなかったのは、
銀行---I/F---RC---I/F---全銀---
という流れで、これはRCやインフラを含め多重化されていて
今回はRCの主系・従系両方とも同時に(ここが一番悪い)更新したため
切り戻すと銀行側I/Fまで戻すため、
全体に及ぶリスクを回避した結果、だそうです.正直平和ボケ.
実際ベンダはNTTデータでも
作ってるのは2次受け3次受けの零細ソフトウェア開発会社だったりするわけで
もう少し気を使えなかったのか、という感じはします.
まぁ作っても最終的に承認して責任を負うのは1次受けです.
今回はデータの流れを復旧させることを最優先としたため
送金手数料の計算結果を全て0円にして、
チェックロジックをノーエラーで通過するようにしただけです.
これを復旧と言ってしまうところが業界の末期症状というか
対外的・場当たり的な感じがします.
しっかりテストしていれば防げたはずなので、
テストはちゃんとやりましょうよ山岡さん、
というところに落ち着くでしょう.
RC(リレーコンピュータ)更新時の
単体テストや結合テストのケース漏れです.
ここから始まった障害の連鎖が、銀行間全体の流れに波及しました.
送金元A銀行---RC---全銀---RC---送金先B銀行
というデータの流れで、A銀行側RCまたはB銀行側RCでトラブったため
データが未着になりました.
RCには全銀側で用意した手数料をチェックする処理がありましたが
対象となる14行中の11行はこれを使用し
残りの3行は独自に送金手数料を計算していたので使用せず
ここで明暗が分かれました.
障害発生時、更新前状態に切り戻さなかったのは、
銀行---I/F---RC---I/F---全銀---
という流れで、これはRCやインフラを含め多重化されていて
今回はRCの主系・従系両方とも同時に(ここが一番悪い)更新したため
切り戻すと銀行側I/Fまで戻すため、
全体に及ぶリスクを回避した結果、だそうです.正直平和ボケ.
実際ベンダはNTTデータでも
作ってるのは2次受け3次受けの零細ソフトウェア開発会社だったりするわけで
もう少し気を使えなかったのか、という感じはします.
まぁ作っても最終的に承認して責任を負うのは1次受けです.
今回はデータの流れを復旧させることを最優先としたため
送金手数料の計算結果を全て0円にして、
チェックロジックをノーエラーで通過するようにしただけです.
これを復旧と言ってしまうところが業界の末期症状というか
対外的・場当たり的な感じがします.
しっかりテストしていれば防げたはずなので、
テストはちゃんとやりましょうよ山岡さん、
というところに落ち着くでしょう.
最近のコメント