Comment la banque s'est cassée



La migration infructueuse de l'infrastructure informatique a endommagé 1,3 milliard de dossiers de clients bancaires. La faute était le manque de tests et une attitude frivole envers les systèmes informatiques complexes. Cloud4Y raconte comment c'était.

En 2018, la banque britannique TSB s'est rendu compte que son «divorce» il y a deux ans avec le groupe bancaire Lloyds (les deux sociétés fusionnées en 1995) était trop cher. Le BST était toujours lié à son ancien partenaire par le biais de systèmes informatiques Lloyds clonés à la hâte. Et le pire, c'est que la banque a dû payer des «pensions alimentaires pour enfants» - des déductions sous forme de droits de licence annuels de 127 millions de dollars.

Peu de gens aiment payer de l'argent à leurs ex, donc le 22 avril 2018 à 18h00, le BST a entamé la dernière étape d'un plan de 18 mois qui était censé tout changer. Il était prévu de transférer des milliards de dossiers clients vers le système informatique de la société espagnole Banco Sabadell, qui a racheté TSB pour 2,2 milliards de dollars en 2015.

Le PDG de Banco Sabadell, Jose Olyu, a parlé de l'événement à venir 2 semaines avant Noël 2017 lors d'une réunion festive du personnel dans une prestigieuse salle de conférence à Barcelone. L'outil de migration le plus important devait être la nouvelle version du système Banco Sabadell: Proteo. Il a même été renommé Proteo4UK spécifiquement pour le projet de migration du BST.

Lors de la présentation de Proteo4UK, Jaime Guardiola Romoharo, directeur exécutif de Banco Sabadell, s'est vanté que le nouveau système est un projet à grande échelle qui n'a pas d'analogues en Europe et a été travaillé par plus de 1000 spécialistes. Et que sa mise en œuvre donnera une impulsion significative à la croissance de Banco Sabadell au Royaume-Uni.

Le jour de la migration a été fixé au 22 avril 2018. C'était un dimanche soir tranquille au milieu du printemps. Les systèmes informatiques de la Banque ont été désactivés car les enregistrements ont été transférés d'un système à un autre. Avec la restauration de l'accès public aux comptes bancaires tard dimanche soir, on pourrait s'attendre à ce que la banque revienne lentement et en douceur.

Mais alors qu'Olya et Guardiola Romoharo diffusaient avec joie depuis la scène la mise en œuvre du projet Proteo4UK, le personnel responsable du processus de migration était très nerveux. Le projet, qui a duré 18 mois, a pris beaucoup de retard et a dépassé le budget. Nous n'avons pas eu le temps d'effectuer des tests supplémentaires. Mais le transfert de toutes les données de l'entreprise (et, rappelons-le, des milliards d'enregistrements) vers un autre système est un travail titanesque.

Il s'est avéré que les ingénieurs n'étaient pas nerveux pour rien.


Un talon sur un site que les clients ont vu depuis trop longtemps

20 minutes après que le BST a ouvert l'accès aux comptes, étant sûr que la migration s'est bien déroulée, les premiers rapports de problèmes sont arrivés.

Les accumulations de personnes ont soudainement disparu. Les achats de petites quantités ont été enregistrés par erreur comme des milliers de dépenses. Certaines personnes se sont connectées à leurs comptes personnels et n'ont pas vu leurs comptes bancaires, mais les comptes de personnes complètement différentes.

À 21 heures, des représentants du BST ont déclaré au régulateur financier local (UK Financial Regulatory and Supervisory Authority, FCA) que la banque avait des problèmes. Mais FCA a déjà fait attention à cela: le BST a vraiment beaucoup foiré et les clients étaient des imbéciles. Et, bien sûr, ils ont commencé à se plaindre des réseaux sociaux (et de nos jours, écrire quelques lignes sur Twitter ou Facebook n'est pas difficile). À 23h30, un autre régulateur financier, la Prudential Regulation Authority (PRA), a contacté la FCA, qui a également estimé que quelque chose n'allait pas.

Déjà profond après minuit, ils ont réussi à communiquer avec l'un des représentants de la banque. Et posez-leur la seule question: "qu'est-ce qui se passe?"

Il a fallu du temps pour comprendre l'ampleur de la tragédie, mais maintenant nous savons que pendant la migration, 1,3 milliard de dossiers de 5,4 millions de clients ont été endommagés. Pendant au moins une semaine, les clients n'ont pas pu gérer leur argent à partir d'un ordinateur et d'appareils mobiles. Ils n'ont pas réussi à payer le prêt et de nombreux clients de la banque ont reçu une place dans leurs antécédents de crédit, ainsi que des frais de retard.


Voici à quoi ressemblait la banque de clients du BST en ligne

Lorsque les défaillances ont commencé à apparaître, presque immédiatement après, les représentants de la banque ont assuré que les problèmes étaient «périodiques». Trois jours plus tard, une déclaration a été publiée que tous les systèmes sont normaux. Mais les clients ont continué de signaler des problèmes. Ce n'est que le 26 avril 2018, le PDG de la Banque, Paul Pester, a admis que le TSB était «à genoux», car l'infrastructure informatique de la banque avait toujours un «problème de bande passante» qui ne permettait pas l'utilisation des services bancaires en ligne pour environ un million de clients.

Deux semaines après le début de la migration, des pannes étaient toujours signalées dans l'application de banque en ligne, ce qui a généré des erreurs internes liées à la base de données SQL.
Les difficultés de paiement, en particulier avec les comptes d'entreprise et les comptes hypothécaires, ont duré jusqu'à quatre semaines. Et des journalistes omniprésents ont découvert que le BST avait rejeté l'offre d'aide de Lloyds Banking Group au tout début de la crise migratoire. En général, les problèmes liés à l'accès aux services en ligne et à la possibilité de transférer de l'argent ont été observés jusqu'au 3 septembre.

Un peu d'histoire



Le premier guichet automatique a été ouvert le 27 juin 1967 près de Barclays à Enfield.

Les systèmes informatiques bancaires deviennent de plus en plus complexes, à mesure que les besoins des clients et leurs attentes de la banque augmentent. Il y a environ 40 à 60 ans, nous serions heureux de visiter la succursale locale de la banque pendant les heures de travail pour déposer de l'argent ou le retirer via la caisse.

Le montant d'argent sur le compte était directement lié à l'argent et aux pièces que nous avons transférés à la banque. Notre comptabilité à domicile pouvait être suivie avec un stylo et du papier, et les systèmes informatiques n'étaient pas disponibles pour les clients. Les employés de la banque ont placé les données des livrets et autres supports dans des appareils qui comptaient de l'argent.

Mais en 1967, au nord de Londres , un GAB a été installé pour la première fois , qui n'était pas situé sur le territoire de la banque. Et cet événement a changé la banque. La commodité d'utilisation est devenue une ligne directrice pour le développement des institutions financières. Et cela a aidé les banques à devenir plus sophistiquées en termes de collaboration avec les clients et leur argent. Après tout, alors que les systèmes informatiques n'étaient disponibles que pour les employés de banque, ils étaient satisfaits de la manière précédente, «papier», d'interagir avec un client. Et ce n’est que lorsqu’il y avait des distributeurs automatiques de billets, puis des services bancaires en ligne, que le grand public avait un accès direct aux systèmes informatiques de la banque.

Les guichets automatiques n'étaient que le début. Bientôt, les gens ont pu éviter la file d'attente à la caisse en appelant simplement la banque par téléphone. Cela nécessitait l'insertion de cartes spéciales dans un lecteur capable de décrypter les signaux multifréquence bicolores (DTMF) transmis lorsque l'utilisateur appuyait sur les touches «1» (retirer de l'argent) ou «2» (déposer de l'argent).

Internet et les services bancaires mobiles ont rapproché les clients des principaux systèmes qui soutiennent les banques. Malgré diverses limitations et paramètres, tous ces systèmes doivent interagir efficacement entre eux et avec le mainframe principal, vérifier le solde du compte, effectuer des transferts d'argent, etc.

Peu de clients pensent à la difficulté des informations lorsque, par exemple, vous vous rendez dans une banque en ligne pour consulter ou mettre à jour des informations sur l'argent de votre compte. Lorsque vous entrez dans le système, ces données sont transmises via un ensemble de serveurs, lorsque vous effectuez une transaction, le système duplique ces données dans l'infrastructure principale, qui effectue ensuite le travail acharné - transfère de l'argent d'un compte à un autre pour payer les factures, effectuer les paiements et poursuivre les abonnements.

Multipliez maintenant ce processus par plusieurs milliards. Selon les données compilées par la Banque mondiale par le biais de la Fondation Bill et Melinda Gates, 69% des adultes dans le monde ont un compte bancaire. Chacune de ces personnes doit payer ses factures. Quelqu'un paie une hypothèque ou transfère de l'argent pour des clubs pour enfants, quelqu'un paie un abonnement à Netflix ou loue un serveur cloud. Et tous ces gens utilisent plus d'une banque.

De nombreux systèmes informatiques internes d'une banque (services bancaires mobiles, distributeurs automatiques de billets, etc.) ne devraient pas simplement interagir les uns avec les autres. Ils doivent interagir avec d'autres systèmes bancaires au Brésil, en Chine et en Allemagne. Un GAB français devrait pouvoir émettre de l'argent qui se trouve sur une carte bancaire émise quelque part en Bolivie.

L'argent a toujours été mondial, mais jamais auparavant ce système n'a été aussi complexe. Le nombre de façons d’utiliser les systèmes informatiques de la banque augmente, mais les anciennes méthodes sont toujours utilisées. Le succès d’une banque dépend en grande partie de la «maintenabilité» de son infrastructure informatique et de son efficacité à faire face à une panne soudaine, ce qui rendra le système inactif.

Pas de tests - préparez-vous aux problèmes



Le PDG de Banco de Sabadell, Jaime Guardiola (à gauche), était convaincu que tout se passerait bien. Ça n'a pas marché.

Les systèmes informatiques du BST n'étaient pas très efficaces pour résoudre rapidement les problèmes. Il y a eu, bien sûr, des défaillances logicielles, mais en réalité la banque a «cassé» en raison de la complexité excessive des systèmes informatiques. Selon le rapport, qui a été préparé au début de la perturbation massive, «la combinaison de nouvelles applications, l'utilisation élargie des microservices en combinaison avec l'utilisation de deux centres de données actifs (actifs / actifs) a conduit à un risque complexe sur le lieu de travail».

Certaines banques, comme HSBC, opèrent à l'échelle mondiale et ont donc également des systèmes interconnectés très complexes. Mais selon l'un des responsables informatiques de HSBC à Lancaster, ils sont régulièrement testés, migrés et mis à jour. Il considère HSBC comme un modèle de la façon dont les autres banques devraient gérer leurs systèmes informatiques: affecter du personnel et passer leur temps. Mais en même temps, il admet que pour une petite banque, en particulier une banque qui n'a pas d'expérience en matière de migration, le faire correctement est une tâche très difficile.

La migration du BST a été difficile. Et, selon les experts, le personnel de la banque n'a pas réussi à atteindre ce niveau de complexité en termes de qualifications. De plus, ils n'ont même pas pris la peine de vérifier leur décision, de tester la migration à l'avance.

S'adressant au Parlement britannique sur les questions bancaires, Andrew Bailey, directeur exécutif de la FCA, a confirmé cette suspicion. Un mauvais code n'a probablement causé les problèmes initiaux qu'au TSB, mais les systèmes interconnectés du réseau financier mondial ont fait que ses erreurs se sont perpétuées et sont irréversibles. La banque a continué de constater des erreurs inattendues ailleurs dans son architecture informatique. Les clients ont reçu des messages dénués de sens ou sans rapport avec leurs problèmes.

Les tests de régression pourraient aider à prévenir une catastrophe en identifiant le mauvais code avant qu'il ne soit exécuté dans un environnement de production, et il a causé des dommages, créant des erreurs qui n'ont pas pu être annulées. Mais la banque a décidé de franchir le champ de mines, qu'il ne connaissait même pas. Les conséquences étaient prévisibles. Un autre problème était "l'optimisation" des coûts. Dans quoi se manifeste-t-il? Le fait qu'auparavant, il avait été décidé de supprimer les sauvegardes stockées dans Lloyds, car elles "mangeaient" trop d'argent.

Les banques britanniques (et d'autres aussi) s'efforcent d'atteindre un niveau d'accessibilité de "quatre neuf", soit 99,99%. Dans la pratique, cela signifie que le système informatique doit être disponible à tout moment et que les temps d'arrêt peuvent atteindre 52 minutes par an. Le système des «trois neuf», 99,9%, à première vue n'est pas très différent. Mais en fait, cela signifie que les temps d'arrêt atteignent 8 heures par an. Pour une banque, «quatre neuf» est bien, mais «trois neuf» ne l'est pas.

Mais chaque fois qu'une entreprise modifie son infrastructure informatique, elle prend des risques. Après tout, quelque chose peut mal tourner. La réduction des modifications peut aider à éviter les problèmes, tandis que les modifications requises doivent être testées de manière approfondie. Et à ce stade, les régulateurs britanniques ont attiré l'attention.

La façon la plus simple d'éviter les temps d'arrêt est peut-être de faire moins de modifications. Mais chaque banque, comme toute autre entreprise, est obligée d'introduire de plus en plus d'occasions utiles pour les clients et sa propre entreprise afin de rester compétitive. Dans le même temps, les banques sont toujours obligées de prendre soin de leurs clients, en protégeant leur épargne et leurs données personnelles, en fournissant des conditions confortables pour l'utilisation des services. Il s'avère que les organisations sont obligées de consacrer beaucoup de temps et d'argent à maintenir la santé de l'infrastructure informatique, tout en offrant de nouveaux services.

Selon les chiffres publiés par la UK Financial Regulatory and Supervisory Authority, le nombre de défaillances technologiques enregistrées dans le secteur des services financiers au Royaume-Uni a augmenté de 187% entre 2017 et 2018. Le plus souvent, la cause des échecs est un problème dans le fonctionnement de la nouvelle fonctionnalité. Dans le même temps, il est extrêmement important pour les banques d'assurer le fonctionnement continu et ininterrompu de tous les services et la notification presque instantanée des transactions. Les clients sont toujours nerveux lorsque leur argent traîne au milieu de nulle part. Un client qui est nerveux à propos de l'argent est toujours en difficulté, un signe certain.

Quelques mois après l'échec du TSB (date à laquelle le PDG de la banque avait démissionné), les régulateurs financiers britanniques et la Banque d'Angleterre ont publié un document de travail sur la durabilité opérationnelle. Ils ont donc tenté de se poser la question de savoir à quel point les banques étaient allées dans la recherche d'innovations et si elles pouvaient garantir le fonctionnement stable du système qui est maintenant disponible.

Le document proposait également des amendements à la loi. Il s'agissait de rendre les employés de l'entreprise responsables de ce qui n'allait pas dans les systèmes informatiques de l'entreprise. Les parlementaires britanniques l'ont expliqué ainsi: "Lorsque vous êtes personnellement responsable et que vous pouvez faire faillite ou être envoyé en prison, cela changera considérablement votre attitude au travail, notamment en augmentant le temps consacré à la question de la fiabilité et de la sécurité".

Résumé


Chaque mise à jour et correctif se résume à la gestion des risques, en particulier lorsqu'il s'agit de centaines de millions de dollars. Après tout, si quelque chose se passe mal, cela peut coûter cher en termes d'argent et de réputation. Cela semble évident. Et l'échec de la banque lors de la migration a dû leur apprendre beaucoup.

Ça aurait dû l'être. Mais n'a pas enseigné. En novembre 2019, le TSB, qui a de nouveau renoué avec sa rentabilité et amélioré lentement sa réputation, a «ravi» les clients d'un nouvel échec dans le domaine des technologies de l'information. Le deuxième coup porté à la banque l'a amenée à fermer 82 agences en 2020 afin de réduire ses coûts. Ou il ne pouvait tout simplement pas économiser sur les informaticiens.

La parcimonie envers l'informatique est finalement taxée. Le BST a déclaré une perte de 134 millions de dollars en 2018, contre un bénéfice de 206 millions de dollars en 2017. Les coûts après la migration, y compris l'indemnisation des clients, la correction des transactions frauduleuses (et leur nombre ont fortement augmenté pendant le chaos bancaire) et l'assistance de tiers spécialistes se sont élevés à 419 millions de dollars. Le fournisseur informatique de la banque a également été facturé 194 millions de dollars pour son rôle dans la crise.

Cependant, malgré les enseignements tirés après la faillite du BST, des interruptions continueront de se produire. Ils sont inévitables. Mais grâce aux tests et au bon code, le nombre de plantages et de temps d'arrêt peut être considérablement réduit. Cloud4Y, qui aide souvent les grandes entreprises à migrer vers l'infrastructure cloud, est bien conscient de l'importance de passer rapidement d'un système à un autre. Par conséquent, nous pouvons effectuer des tests de charge et utiliser un système de sauvegarde à plusieurs niveaux, ainsi que d'autres options qui vous permettent de vérifier tout ce qui est possible avant de démarrer la migration.

Quoi d'autre est utile de lire sur le blog Cloud4Y

Énergie solaire salée
→ Les pentesters à la pointe de la cybersécurité
→ La grande théorie du flocon de neige
Internet par ballons
Avez-vous besoin d'oreillers dans le centre de données?

Abonnez-vous à notre chaîne Telegram pour ne pas manquer un autre article! Nous écrivons pas plus de deux fois par semaine et uniquement pour affaires.

Source: https://habr.com/ru/post/fr484644/


All Articles