En mislykket migrering av IT-infrastruktur resulterte i korrupsjon av 1,3 milliarder bankkundeposter. Alt dette skyldtes utilstrekkelig testing og en useriøs holdning til komplekse IT-systemer. Cloud4Y forteller hvordan det skjedde.
I 2018 engelsk innså at hans to år gamle "skilsmisse" med bankgruppen Lloyds (begge selskapene fusjonerte i 1995) var for dyr. TSB var fortsatt knyttet til sin tidligere partner gjennom raskt klonede Lloyds IT-systemer. Det verste av alt var at banken måtte betale «alimentasjon», en årlig lisensavgift på 127 millioner dollar.
De færreste liker å betale penger til eksene sine, så 22. april 2018 klokken 18:00 begynte TSB den siste fasen av en 18-måneders plan som skulle endre alt. Det var planlagt å overføre milliarder av kundeposter til IT-systemet til det spanske selskapet Banco Sabadell, som kjøpte TSB for 2,2 milliarder dollar tilbake i 2015.
Banco Sabadell-sjef José Olu snakket om det kommende arrangementet 2 uker før jul 2017 under et festlig personalmøte i en prestisjefylt konferansesal i Barcelona. Det viktigste migreringsverktøyet skulle være en ny versjon av systemet utviklet av Banco Sabadell: Proteo. Det ble til og med omdøpt til Proteo4UK spesielt for TSB-migrasjonsprosjektet.
Ved presentasjonen av Proteo4UK skrøt Banco Sabadells administrerende direktør Jaime Guardiola Romojaro av at det nye systemet er et storstilt prosjekt som ikke har noen analoger i Europa, som over 1000 spesialister jobbet på. Og at implementeringen vil gi et betydelig løft til veksten til Banco Sabadell i Storbritannia.
22. april 2018 ble satt som migrasjonsdag. Det var en rolig søndagskveld midt på våren. Bankens IT-systemer var nede da registreringer ble overført fra et system til et annet. Med offentlig tilgang til bankkontoer gjenopprettet sent på søndag, kan man forvente at banken sakte og jevnt kommer tilbake til tjeneste.
Men mens Olyu og Guardiola Romojaro gladelig sendte fra scenen om gjennomføringen av Proteo4UK-prosjektet, var de ansatte som var ansvarlige for migrasjonsprosessen veldig nervøse. Prosjektet, som tok 18 måneder å fullføre, var alvorlig forsinket og over budsjett. Det var ikke tid til å gjennomføre ytterligere tester. Men å overføre alle selskapets data (som, husk, er milliarder av poster) til et annet system er en herkulisk oppgave.
Det viste seg at ingeniørene var nervøse med god grunn.
En stubbe på siden som kundene så for lenge
20 minutter etter at TSB åpnet tilgang til kontoene, med full tillit til at migreringen gikk problemfritt, kom de første problemene.
Folks sparepenger forsvant plutselig fra kontoene deres. Kjøp av ubetydelige beløp ble feilaktig bokført som utgifter på flere tusen dollar. Noen mennesker logget på sine personlige kontoer og så ikke bankkontoene deres, men kontoene til helt andre personer.
Klokken 21 informerte TSB-representanter den lokale finanstilsynsmyndigheten (UK Financial Conduct Authority, FCA) om at banken var i trøbbel. Men FCA har allerede lagt merke til det: TSB har virkelig skrudd dårlig sammen, og kundene har blitt dumme. Og selvfølgelig begynte de å klage til (og nå for tiden er det ikke spesielt vanskelig å slippe noen linjer på Twitter eller Facebook). Klokken 23:30 ble FCA kontaktet av en annen finanstilsynsmyndighet, Prudential Regulation Authority (PRA), som også merket at noe var galt.
Allerede i god tid etter midnatt klarte de å komme igjennom til en av bankrepresentantene. Og spør dem det eneste spørsmålet: "hva i helvete er det som skjer?"
Det tok tid å forstå omfanget av tragedien, men vi vet nå at 1,3 milliarder poster på 5,4 millioner kunder ble skadet under migreringen. I minst en uke klarte ikke klienter å administrere pengene sine fra datamaskiner eller mobile enheter. De var ikke i stand til å betale lånet, og mange bankkunder fikk en lyte på kreditthistorikken, samt forsinkelsesgebyrer.
Slik så TSB-kundenettbanken ut
Da feilene begynte å dukke opp, nesten umiddelbart etter, insisterte bankrepresentanter på at problemene var «intermitterende». Tre dager senere ble det gitt en erklæring om at alle systemer var normale. Men kundene fortsatte å rapportere problemer. Det var først 26. april 2018 at bankens administrerende direktør, Paul Pester, innrømmet at TSB var «på knærne» ettersom bankens IT-infrastruktur fortsatte å ha et «båndbreddeproblem» som hindret rundt en million kunder i å få tilgang til nettbanktjenester.
To uker etter migreringen ble det fortsatt rapportert at nettbankapplikasjonen hadde interne feil relatert til SQL-databasen.
Betalingsvansker, spesielt med forretnings- og boliglånsregninger, fortsatte i opptil fire uker. Og allestedsnærværende journalister fant ut at TSB avviste et tilbud om hjelp fra Lloyds Banking Group helt i begynnelsen av migrasjonskrisen. Generelt ble det observert problemer knyttet til pålogging på netttjenester og muligheten til å overføre penger frem til 3. september.
En bit av historien
Den første minibanken åpnet 27. juni 1967 nær Barclays i Enfield
Bankens IT-systemer blir stadig mer komplekse ettersom kundenes behov og forventninger fra banken øker. For rundt 40-60 år siden ville vi gjerne besøkt vår lokale bankfilial i åpningstiden for å sette inn kontanter eller ta dem ut gjennom kassen.
Pengebeløpet på kontoen var direkte relatert til kontantene og myntene vi ga til banken. Hjemmeregnskapet vårt kunne spores med penn og papir, og datasystemer var ikke tilgjengelige for klienter. Bankansatte plasserte data fra passbooks og andre medier i enheter som talte pengene.
Men i 1967 i Nord-London for første gang en minibank som ikke var plassert i bankens lokaler. Og denne hendelsen endret bankvirksomhet. Brukervennlighet har blitt en målestokk for utviklingen av finansinstitusjoner. Og dette har hjulpet bankene til å bli mer sofistikerte når det gjelder å jobbe med kunder og pengene deres. Tross alt, mens datasystemer bare var tilgjengelige for bankansatte, var de fornøyde med den gamle "papir" måten å samhandle med klienter på. Det var først med bruk av minibanker og deretter nettbank at allmennheten fikk direkte tilgang til bankenes IT-systemer.
Minibanker var bare begynnelsen. Snart klarte folk å unngå køen ved kassaapparatet ved å ringe banken på telefon. Dette krevde spesielle kort satt inn i en leser som var i stand til å dechiffrere dual-tone multi-frequency (DTMF) signalene som ble sendt når brukeren trykket på tasten "1" (ta ut penger) eller "2" (innskuddsmidler).
Internett og mobilbank har brakt kundene nærmere kjernesystemene som driver banker. Til tross for deres varierende begrensninger og innstillinger, må alle disse systemene samhandle effektivt med hverandre og med stormaskinen, utføre kontobalansekontroller, foreta pengeoverføringer og så videre.
Få kunder tenker på hvor kompleks informasjonsveien er når du for eksempel logger deg inn i en nettbank for å se eller oppdatere informasjon om pengene på kontoen din. Når du logger på, sendes disse dataene gjennom et sett med servere; når du foretar en transaksjon, dupliserer systemet disse dataene i backend-infrastrukturen, som deretter gjør det tunge arbeidet – overføre penger fra en konto til en annen for å betale regninger, gjøre betalinger og fortsette abonnementer.
Multipliser nå denne prosessen med flere milliarder. I følge data samlet av Verdensbanken ved hjelp av Bill og Melinda Gates Foundation, voksne over hele verden har en bankkonto. Hver av disse menneskene har regninger å betale. Noen betaler boliglån eller overfører penger til barneklubber, noen betaler for et Netflix-abonnement eller leier en skyserver. Og alle disse menneskene bruker mer enn én bank.
Tallrike interne IT-systemer i en bank (mobilbank, minibanker osv.) må ikke bare samhandle med hverandre. De må samhandle med andre banksystemer i Brasil, Kina og Tyskland. En fransk minibank skal kunne dispensere penger som er på et bankkort utstedt et sted i Bolivia.
Penger har alltid vært globalt, men aldri før har systemet vært så komplekst. Antall måter å bruke bankens IT-systemer på øker, men de gamle måtene er fortsatt i bruk. Suksessen til en bank avhenger i stor grad av hvor "vedlikeholdbar" IT-infrastrukturen er, og hvor effektivt banken kan takle en plutselig feil som gjør at systemet blir inaktivt.
Ingen tester - forbered deg på problemer
Banco de Sabadell-sjef Jaime Guardiola (til venstre) var overbevist om at alt ville gå knirkefritt. Det gikk ikke.
TSBs datasystemer var ikke så flinke til å løse problemer raskt. Det var selvfølgelig programvarefeil, men i virkeligheten "brøt banken" på grunn av den overdrevne kompleksiteten til IT-systemene. I følge rapporten, som ble utarbeidet i de tidlige dagene av det massive strømbruddet, "førte kombinasjonen av nye applikasjoner, økt bruk av mikrotjenester kombinert med bruk av to aktive/aktive datasentre til kompleks risiko i produksjonen."
Noen banker, som HSBC, opererer globalt og har derfor også svært komplekse, sammenkoblede systemer. Men de blir regelmessig testet, migrert og oppdatert, ifølge en HSBC IT-sjef i Lancaster. Han ser på HSBC som en modell for hvordan andre banker skal administrere IT-systemene sine: ved å bruke ansatte og bruke tiden sin. Men han innrømmer samtidig at for en mindre bank, spesielt en som ikke har migreringserfaring, er det en svært vanskelig oppgave å gjøre dette riktig.
TSB-migrasjonen var vanskelig. Og ifølge eksperter kunne bankpersonalet rett og slett ikke nå dette kompleksitetsnivået når det gjelder kvalifikasjoner. I tillegg brydde de seg ikke engang om å sjekke løsningen eller teste migreringen på forhånd.
Under en tale i det britiske parlamentet om bankproblemer bekreftet Andrew Bailey, administrerende direktør i FCA, denne mistanken. Dårlig kode forårsaket sannsynligvis bare de første problemene hos TSB, men de sammenkoblede systemene til det globale finansielle nettverket gjorde at feilene ble foreviget og irreversible. Banken fortsatte å se uventede feil andre steder i IT-arkitekturen. Kunder mottok meldinger som var meningsløse eller som ikke var relatert til problemene deres.
Regresjonstesting kan bidra til å forhindre katastrofe ved å fange opp dårlig kode før den ble lansert i produksjon og forårsaket skade ved å lage feil som ikke kunne rulles tilbake. Men banken bestemte seg for å kjøre gjennom et minefelt som den ikke engang visste om. Konsekvensene var forutsigbare. Et annet problem var «optimalisering» av kostnadene. Hvordan viste det seg? Faktum er at det tidligere ble besluttet å gjøre unna sikkerhetskopiene som er lagret hos Lloyds, siden de "spiste opp" for mye penger.
Britiske banker (og andre også) streber etter å oppnå et tilgjengelighetsnivå på fire-ni, det vil si 99,99 %. I praksis betyr dette at IT-systemet skal være tilgjengelig til enhver tid, med inntil 52 minutter nedetid per år. "Tre ni"-systemet, 99,9%, skiller seg ikke mye ved første øyekast. Men i realiteten betyr dette at nedetiden når 8 timer per år. For banken er «fire niere» bra, men «tre niere» er det ikke.
Men hver gang et selskap gjør endringer i IT-infrastrukturen, tar det risiko. Tross alt kan noe gå galt. Å redusere endringer kan bidra til å unngå problemer, mens nødvendige endringer krever nøye testing. Og britiske regulatorer har fokusert oppmerksomheten på dette punktet.
Den kanskje enkleste måten å unngå nedetid på er å gjøre færre endringer. Men hver bank, som alle andre selskaper, er tvunget til å introdusere flere og flere nyttige funksjoner for kunder og sin egen virksomhet for å forbli konkurransedyktig. Samtidig er bankene fortsatt forpliktet til å ta vare på kundene sine, beskytte sparepengene og personopplysningene deres, gi komfortable betingelser for bruk av tjenester. Det viser seg at organisasjoner er tvunget til å bruke mye tid og penger på å opprettholde helsen til IT-infrastrukturen sin, samtidig som de tilbyr nye tjenester.
Antallet rapporterte teknologifeil i finanssektoren i Storbritannia økte med 187 prosent mellom 2017 og 2018, ifølge data utgitt av Storbritannias Financial Conduct Authority. Oftest er årsaken til feil problemer i driften av ny funksjonalitet. Samtidig er det kritisk for bankene å sikre konstant uavbrutt drift av alle tjenester og nesten øyeblikkelig rapportering av transaksjoner. Kunder er alltid nervøse når pengene henger et sted. Og en klient som er nervøs for penger er alltid et tegn på problemer.
Noen måneder etter fiaskoen i TSB (da hadde bankens administrerende direktør gått av), britiske finanstilsyn og Bank of England for diskusjon om operasjonelle bærekraftspørsmål. Så de prøvde å reise spørsmålet om hvor dypt bankene har gått i jakten på innovasjon, og om de kan garantere stabil drift av systemet som de har nå.
Dokumentet foreslo også endringer i lovgivningen. Det handlet om å holde folk i selskapet ansvarlige for hva som går galt i selskapets IT-systemer. Britiske parlamentarikere forklarte det på denne måten: "Når du er personlig ansvarlig, og du kan gå konkurs eller gå i fengsel, vil dette i stor grad endre holdningen til arbeid, inkludert å øke tiden som brukes til spørsmålet om pålitelighet og sikkerhet."
Resultater av
Hver oppdatering og oppdatering kommer ned til risikostyring, spesielt når hundrevis av millioner av dollar er involvert. Tross alt, hvis noe går galt, kan det bli kostbart i form av penger og omdømme. Det ville virke åpenbare ting. Og bankens svikt under migrasjonen burde ha lært dem mye.
Hadde. Men han lærte meg ikke. I november 2019 "glade" TSB, som igjen oppnådde lønnsomhet og sakte forbedret sitt rykte, kunder innen informasjonsteknologi. Det andre slaget til banken innebar at den vil bli tvunget til å stenge 82 filialer i 2020 for å kutte kostnadene. Eller han kunne rett og slett ikke spare på IT-spesialister.
Gjerrighet med IT har til syvende og sist en kostnad. TSB rapporterte et tap på 134 millioner dollar i 2018, sammenlignet med et overskudd på 206 millioner dollar i 2017. Kostnader etter migrering, inkludert kundekompensasjon, korrigering av uredelige transaksjoner (som økte kraftig under bankkaoset), og tredjepartshjelp, utgjorde 419 millioner dollar. Bankens IT-leverandør ble også fakturert 194 millioner dollar for sin rolle i krisen.
Uansett hvilken lærdom man trekker fra TSB-banksvikten, vil det likevel oppstå forstyrrelser. De er uunngåelige. Men med testing og god kode kan krasj og nedetid reduseres betraktelig. Cloud4Y, som ofte hjelper store selskaper med å migrere til skyinfrastruktur, forstår viktigheten av å raskt flytte fra ett system til et annet. Derfor kan vi gjennomføre belastningstesting og bruke et sikkerhetskopisystem på flere nivåer, samt andre alternativer som lar deg sjekke alt mulig før du starter migreringen.
Hva annet kan du lese på bloggen?
→
→
→
→
→
Abonner på vår -kanal slik at du ikke går glipp av neste artikkel! Vi skriver ikke mer enn to ganger i uken og kun på forretningsreise.
Kilde: www.habr.com