なぜ銀行は破綻したのでしょうか？

IT インフラストラクチャの移行の失敗により、1,3 億件の銀行顧客記録が破損しました。 これはすべて、不十分なテストと、複雑な IT システムに対する軽薄な態度が原因でした。 Cloud4Y がそれがどのように起こったかを語ります。

2018年英語 TSB銀行 ロイズ銀行グループ（両社は1995年に合併）との127年前の「離婚」の費用が高すぎることに気づいた。 TSB は、急遽複製されたロイズの IT システムを通じて、依然として以前のパートナーと結びついていました。 最も悪いことに、銀行は年間ライセンス料XNUMX億XNUMX万ドルの「慰謝料」を支払わなければならなかった。

元恋人にお金を払いたい人はほとんどいないため、22年2018月18日00時、TSBはすべてを変えるはずだった18か月計画の最終段階を開始した。 数十億件の顧客記録を、2,2年に2015億ドルでTSBを買収したスペイン企業バンコ・サバデルのITシステムに転送する計画だった。

Banco Sabadell CEO の José Olu 氏は、2 年のクリスマスの 2017 週間前、バルセロナの有名な会議場で行われた祝賀スタッフ会議で、今後のイベントについて語った。 最も重要な移行ツールは、Banco Sabadell によって開発されたシステムの新しいバージョンである Proteo でした。 TSB 移行プロジェクト専用に Proteo4UK という名前も変更されました。

Proteo4UKのプレゼンテーションで、バンコ・サバデルのエグゼクティブ・ディレクター、ハイメ・グアルディオラ・ロモハロ氏は、この新しいシステムはヨーロッパに類例のない大規模プロジェクトであり、1000人以上の専門家が取り組んだと自慢した。 そして、その導入は英国におけるバンコ・サバデルの成長を大きく後押しするだろう。

22 年 2018 月 XNUMX 日が移行日として設定されました。 春半ばの静かな日曜の夜でした。 記録をあるシステムから別のシステムに転送しているときに、銀行の IT システムがダウンしました。 日曜遅くに銀行口座への一般アクセスが回復したため、銀行はゆっくりとスムーズに業務を再開すると期待されるだろう。

しかし、オリュ氏とグアルディオラ・ロモハロ氏がステージから Proteo4UK プロジェクトの実施について楽しそうに放送していた一方で、移行プロセスを担当する従業員は非常に緊張していました。 完了までに 18 か月かかったこのプロジェクトは予定より大幅に遅れ、予算を超過していました。 追加のテストを行う時間はありませんでした。 しかし、会社のすべてのデータ (数十億のレコードであることを思い出してください) を別のシステムに転送するのは大変な作業です。

エンジニアたちが緊張していたのには十分な理由があることが分かりました。

顧客が長時間見ていたサイトのスタブ

TSB がアカウントへのアクセスを開始してから 20 分後、移行がスムーズに完了したと確信し、問題の最初の報告が届きました。

人々の預金が突然口座から消えました。 少額の購入が誤って数千ドルの経費として記録された。 個人アカウントにログインすると、自分の銀行口座ではなく、まったく別の人の口座が表示された人もいます。

21時、TSBの代表者は地元の金融規制当局（英国金融行為監視機構、FCA）に銀行が困難に陥っていることを通報した。 しかし、FCA はすでに気づいています。TSB は本当にひどい失敗をし、顧客は馬鹿にされています。 そしてもちろん、彼らは不平を言い始めました ソーシャルネットワーク (そして今では、Twitter や Facebook に数行書き込むことは特に難しいことではありません)。 午後23時30分、FCAは別の金融規制当局である健全性規制当局（PRA）から連絡を受け、やはり何かがおかしいと感じた。

すでに真夜中をかなり過ぎた頃、彼らはなんとか銀行の担当者の一人と連絡を取ることができた。 そして、彼らに唯一の質問をしてください：「一体何が起こっているのですか？」

悲劇の規模を理解するまでには時間がかかりましたが、移行中に 1,3 万人の顧客の 5,4 億件のレコードが被害を受けたことが現在判明しています。 少なくとも XNUMX 週間、顧客はコンピューターやモバイル デバイスからお金を管理できなくなりました。 彼らはローンを支払うことができず、多くの銀行顧客は延滞手数料だけでなく、信用履歴に傷を負うことになりました。

TSB顧客オンライン銀行はこんな感じ

問題が発生し始めた直後、銀行の担当者は問題は「断続的」であると主張した。 26日後、すべてのシステムは正常であるとの声明が発表された。 しかし、顧客からは引き続き問題が報告されました。 2018年XNUMX月XNUMX日になって初めて、同行の最高経営責任者ポール・ペスター氏は、同行のITインフラに「帯域幅の問題」が発生し続け、約XNUMX万人の顧客がオンライン・バンキング・サービスにアクセスできないため、TSBが「ひざまずいている」と認めた。

移行から XNUMX 週間が経過した時点でも、オンライン バンキング アプリケーションで SQL データベースに関連する内部エラーが発生していると報告されました。
特に事業費や住宅ローンの支払いに関する困難は最大 3 週間続いた。 そして、どこにでもいるジャーナリストは、移民危機の初期に​​TSBがロイズ・バンキング・グループからの援助の申し出を拒否したことを知った。 一般的に、オンライン サービスへのログインと送金機能に関連する問題が XNUMX 月 XNUMX 日まで観察されました。

歴史を少し

最初の ATM は 27 年 1967 月 XNUMX 日にエンフィールドのバークレイズ近くにオープンしました。

顧客のニーズと銀行への期待が高まるにつれて、銀行 IT システムはますます複雑になっています。 約 40 ～ 60 年前、私たちは営業時間内に地元の銀行の支店を訪問して現金を預け入れたり、窓口で現金を引き出したりすることができました。

口座内の金額は、銀行に渡した現金と硬貨に直接関係していました。 私たちの家の会計はペンと紙で追跡できましたが、顧客はコンピューターシステムにアクセスできませんでした。 銀行員は通帳やその他の媒体からのデータをお金を数える装置に入力した。

しかし、1967年に初めてロンドン北部で 設置されました 銀行の敷地内に設置されていないATM。 そしてこの出来事は銀行業界を変えました。 ユーザーの利便性は金融機関の発展の指標となっています。 そしてこれにより、銀行は顧客とその資金に対する取り組みがより洗練されるようになりました。 結局のところ、コンピューター システムを利用できるのは銀行員のみでしたが、彼らは顧客とやり取りする古い「紙」の方法に満足していました。 一般の人々が銀行の IT システムに直接アクセスできるようになったのは、ATM とその後のオンライン バンキングの出現によってのみです。

ATM は始まりにすぎませんでした。 すぐに人々は銀行に電話をかけるだけでレジの行列を避けることができるようになりました。 これには、ユーザーが「1」（お金の引き出し）または「2」（資金の入金）キーを押したときに送信されるデュアルトーン多重周波数（DTMF）信号を解読できるリーダーに挿入された特別なカードが必要でした。

インターネットとモバイル バンキングにより、顧客は銀行を動かすコア システムに近づくことができました。 さまざまな制限や設定にもかかわらず、これらのシステムはすべて、アカウント残高チェックや送金などを実行して、相互に、またメイン メインフレームと効果的に対話する必要があります。

たとえば、オンライン銀行にログインして口座内のお金に関する情報を表示または更新する場合、情報経路がどれほど複雑であるかを考えている顧客はほとんどいません。 ログインすると、このデータは一連のサーバーを介して渡され、取引を行うと、システムはこのデータをバックエンド インフラストラクチャに複製し、請求書の支払いのためにある口座から別の口座に送金するという重労働を実行します。支払いを完了し、サブスクリプションを継続します。

このプロセスを数十億倍にします。 ビル＆メリンダ・ゲイツ財団の協力を得て世界銀行がまとめたデータによると、 69パーセント 世界中の大人が銀行口座を持っています。 これらの人々はそれぞれ、支払うべき請求書を持っています。 誰かが住宅ローンを払ったり、児童クラブへの送金をしたり、誰かがNetflixのサブスクリプションやクラウドサーバーのレンタル料を払ったりします。 そして、これらの人々は皆、複数の銀行を利用しています。

XNUMX つの銀行の多数の内部 IT システム (モバイル バンキング、ATM など) は、単に相互に通信するだけであってはなりません。 ブラジル、中国、ドイツの他の銀行システムと連携する必要があります。 フランスの ATM は、ボリビアのどこかで発行された銀行カードにあるお金を引き出すことができるはずです。

お金は常にグローバルですが、システムがこれほど複雑になったことはかつてありませんでした。 銀行の IT システムを活用する方法は増えていますが、古い方法も依然として使用されています。 銀行の成功は、IT インフラストラクチャがどれだけ「保守可能」であるか、そしてシステムがアイドル状態になる突然の障害に銀行がどれだけ効果的に対処できるかに大きく依存します。

テストなし - 問題に備えてください

サバデル銀行の最高経営責任者（CEO）ハイメ・グアルディオラ氏（左）は、すべてが順調に進むと確信していた。 うまくいきませんでした。

TSB のコンピュータ システムは、問題を迅速に解決するのがあまり得意ではありませんでした。 もちろん、ソフトウェアの不具合はありましたが、実際には、IT システムの過度の複雑さが原因で銀行は「破綻」しました。 大規模な障害の初期に作成されたこのレポートによると、「新しいアプリケーションの組み合わせ、マイクロサービスの使用増加、および XNUMX つのアクティブ/アクティブ データセンターの使用が、本番環境での複雑なリスクを引き起こしました。」

HSBC などの一部の銀行は世界的に事業を展開しているため、非常に複雑で相互接続されたシステムを備えています。 しかし、ランカスターのHSBC ITマネージャーの一人によると、これらは定期的にテスト、移行、更新されているという。 同氏はHSBCを、スタッフを専任し時間を費やすことで、他の銀行が自社のITシステムをどのように管理すべきかのモデルとみている。 しかし同時に、小規模な銀行、特に移行経験のない銀行にとって、これを正しく行うのは非常に難しい仕事であることも認めています。

TSB の移行は困難でした。 そして、専門家によると、銀行員は資格の点でこのレベルの複雑さに到達することは不可能です。 さらに、事前にソリューションを確認したり、移行をテストしたりすることさえしませんでした。

英国議会での銀行問題に関する演説で、FCAの最高経営責任者アンドリュー・ベイリー氏はこの疑惑を認めた。 おそらく、悪いコードは TSB で最初の問題を引き起こしただけでしょうが、世界的な金融ネットワークの相互接続されたシステムは、その間違いが永続的で取り返しのつかないことを意味していました。 この銀行では、IT アーキテクチャの他の場所で予期しないエラーが引き続き発生していました。 顧客は、意味のない、または問題とは無関係なメッセージを受け取りました。

回帰テストは、本番環境にリリースされる前に不良コードを発見し、ロールバックできないバグが発生して損害を引き起こすことにより、災害を防ぐのに役立ちます。 しかし、銀行は、自分でも気づいていなかった地雷原を通過することにしました。 結果は予測可能でした。 もう一つの課題はコストの「最適化」だった。 それはどのようにして現れたのでしょうか？ 実際のところ、ロイズ社はあまりにも多くの資金を「使い果たした」ため、ロイズ社に保管されていたバックアップ コピーを廃止することが以前に決定されていました。

英国の銀行 (および他の銀行も) は、フォーナインの可用性レベル、つまり 99,99% の達成に努めています。 実際には、これは IT システムが常に利用可能でなければならず、年間最大 52 分のダウンタイムが発生することを意味します。 99,9%の「スリーナイン」システムは、一見するとあまり変わりません。 しかし実際には、これはダウンタイムが年間 8 時間に達することを意味します。 銀行にとって、「フォーナイン」は良いですが、「スリーナイン」は良くありません。

しかし、企業が IT インフラストラクチャに変更を加えるたびに、リスクが伴います。 結局のところ、何か問題が起こる可能性があります。 変更を減らすと問題を回避できますが、必要な変更には慎重なテストが必要です。 そして英国の規制当局はこの点に注目している。

おそらく、ダウンタイムを回避する最も簡単な方法は、単に変更を減らすことです。 しかし、どの銀行も、他の企業と同様に、競争力を維持するために、顧客や自社のビジネスに役立つ機能をどんどん導入する必要に迫られています。 同時に、銀行は依然として顧客に配慮し、顧客の貯蓄や個人データを保護し、サービスを利用するための快適な条件を提供する義務を負っています。 組織は、新しいサービスを提供しながら、IT インフラストラクチャの健全性を維持するために多大な時間と費用を費やすことを余儀なくされていることがわかりました。

英国金融行為監視機構が発表したデータによると、英国の金融サービス部門で報告されたテクノロジー障害の数は、187年から2017年の間に2018パーセント増加した。 ほとんどの場合、障害の原因は、新しい機能の動作上の問題です。 同時に、銀行にとっては、すべてのサービスを中断なく継続的に実行し、取引をほぼ瞬時に報告できるようにすることが重要です。 顧客は、自分のお金がどこかに落ちていると常に不安になります。 そして、お金のことで神経質になっているクライアントは、常にトラブルの兆候です。

TSBの破綻から数カ月後（その時点で同銀行のCEOは辞任していた）、英国の金融規制当局とイングランド銀行は 文書を発表した 運営の持続可能性の問題についての議論のために。 そこで彼らは、銀行がイノベーションの追求にどれだけ深く取り組んできたのか、そして現在のシステムの安定した運用を保証できるのかという問題を提起しようとした。

この文書では法改正も提案されている。 それは、会社の IT システムで何が起こったのかについて社内の人々に責任を負わせることでした。 英国の国会議員はこれを次のように説明している。「個人的に責任があり、破産したり刑務所に行く可能性がある場合、信頼性と安全性の問題に費やす時間が増えるなど、仕事に対する姿勢が大きく変わるだろう。」

結果

すべてのアップデートとパッチは、特に数億ドルが関係する場合には、リスク管理に帰着します。 結局のところ、何か問題が発生すると、金銭と評判の面で多大な損害を被る可能性があります。 それは当然のことのように思えるでしょう。 そして移住中の銀行の失敗は彼らに多くのことを学んだはずだ。

持っていた。 しかし、彼は私に教えてくれませんでした。 2019 年 XNUMX 月、TSB は再び黒字を達成し、徐々に評判を向上させ、顧客を「喜ばせた」 新たな失敗 情報技術の分野で。 同銀行への第二の打撃は、コスト削減のため82年に2020支店の閉鎖を余儀なくされることを意味した。 あるいは、IT スペシャリストを節約することもできませんでした。

IT をケチると最終的には代償が伴います。 TSBは、134年の2018億206万ドルの利益に対し、2017年には419億194万ドルの損失を報告した。 顧客補償、不正取引の修正（銀行混乱時に急増）、サードパーティ支援などを含む移行後のコストは合計XNUMX億XNUMX万ドルに達した。 銀行のITプロバイダーにも、危機における役割に対してXNUMX億XNUMX万ドルを請求された。

しかし、TSB 銀行破綻からどのような教訓が得られたとしても、混乱は依然として発生します。 それらは避けられないものです。 しかし、テストと適切なコードを使用すれば、クラッシュやダウンタイムを大幅に減らすことができます。 Cloud4Y は、大企業のクラウド インフラストラクチャへの移行を支援することが多く、あるシステムから別のシステムに迅速に移行することの重要性を理解しています。 したがって、負荷テストを実施し、マルチレベルのバックアップ システムや、移行を開始する前に可能な限りすべてをチェックできるその他のオプションを使用できます。

ブログでは他に何が読めますか? クラウド4Y

→ 塩分を含む太陽エネルギー
→ サイバーセキュリティの最前線にいる侵入テスター
→ グレートスノーフレーク理論
→ 風船上のインターネット
→ データセンターに枕は必要ですか?

購読してください Telegram次の記事を見逃さないように、 -channel をご覧ください。 私たちは週に XNUMX 回まで、ビジネスに関するもののみを書きます。

出所： habr.com