Egy sikertelen IT-infrastruktúra-migráció 1,3 milliárd banki ügyfélrekord megsérüléséhez vezetett. Mindez az elégtelen tesztelésnek és a bonyolult informatikai rendszerekhez való komolytalan hozzáállásnak volt köszönhető. A Cloud4Y elmondja, hogyan történt.
2018-ban angolul
Kevesen szeretnek pénzt fizetni az exeinek, ezért 22. április 2018-én 18:00-kor a TSB megkezdte egy 18 hónapos terv utolsó szakaszát, amely állítólag mindent megváltoztatott. Több milliárd ügyfélrekordot terveztek átvinni a spanyol Banco Sabadell informatikai rendszerébe, amely még 2,2-ben 2015 milliárd dollárért vásárolta meg a TSB-t.
A Banco Sabadell vezérigazgatója, José Olu beszélt a közelgő eseményről 2 héttel 2017 karácsonya előtt egy ünnepi munkatársi értekezleten egy rangos barcelonai konferenciateremben. A legfontosabb migrációs eszköz a Banco Sabadell által fejlesztett rendszer új verziója: Proteo volt. Még a Proteo4UK nevet is átnevezték kifejezetten a TSB migrációs projekthez.
A Proteo4UK prezentációján a Banco Sabadell ügyvezető igazgatója, Jaime Guardiola Romojaro azzal dicsekedett, hogy az új rendszer egy nagyszabású, Európában nincs analógja, amelyen több mint 1000 szakember dolgozott. És hogy végrehajtása jelentős lökést fog adni a Banco Sabadell növekedéséhez az Egyesült Királyságban.
22. április 2018-ét jelölték ki a migráció napjává. Csendes vasárnap este volt a tavasz közepén. A bank informatikai rendszerei leálltak, mivel az iratok egyik rendszerből a másikba kerültek. Vasárnap késő este helyreállt a nyilvános hozzáférés a bankszámlákhoz, és arra számíthatunk, hogy a bank lassan és zökkenőmentesen visszatér a szolgálatba.
Ám miközben Olyu és Guardiola Romojaro boldogan közvetítette a színpadról a Proteo4UK projekt megvalósítását, a migrációs folyamatért felelős alkalmazottak nagyon idegesek voltak. A projekt, amelynek befejezése 18 hónapot vett igénybe, súlyosan elmaradt az ütemtervtől és túllépte a költségvetést. Nem volt idő további vizsgálatok elvégzésére. De a vállalat összes adatának (amely, ne feledjük, rekordmilliárd) átvitele egy másik rendszerbe herkulesi feladat.
Kiderült, hogy a mérnökök jó okkal voltak idegesek.
Egy csonk a webhelyen, amelyet az ügyfelek túl sokáig láttak
20 perccel azután, hogy a TSB megnyitotta a hozzáférést a számlákhoz, teljesen biztos volt benne, hogy a migráció zökkenőmentesen zajlott, megérkeztek az első problémákról szóló jelentések.
Az emberek megtakarításai hirtelen eltűntek a számláikról. A jelentéktelen összegű vásárlásokat tévesen többezer dolláros kiadásként könyvelték el. Vannak, akik bejelentkeztek személyes fiókjukba, és nem a saját bankszámlájukat látták, hanem teljesen más emberek számláit.
21:00 órakor a TSB képviselői értesítették a helyi pénzügyi szabályozó hatóságot (az Egyesült Királyság Financial Conduct Authority, FCA), hogy a bank bajban van. De az FCA már észrevette: a TSB tényleg csúnyán elcseszte, a vásárlókat pedig hülyévé tették. És persze panaszkodni kezdtek
Már jóval éjfél után sikerült átjutniuk az egyik bank képviselőjéhez. És tedd fel nekik az egyetlen kérdést: "mi a fene folyik itt?"
Időbe telt, míg megértették a tragédia mértékét, de ma már tudjuk, hogy 1,3 millió ügyfél 5,4 milliárd rekordja sérült meg a migráció során. Az ügyfelek legalább egy hétig nem tudták kezelni pénzüket számítógépükről vagy mobileszközeikről. Nem tudták kifizetni a kölcsönt, és sok banki ügyfélnek foltot kapott a hiteltörténete, valamint késedelmi díjak is.
Így nézett ki a TSB ügyfél online bankja
Amikor szinte azonnal megjelentek a hibák, a bank képviselői ragaszkodtak ahhoz, hogy a problémák „szakaszosak”. Három nappal később nyilatkozatot adtak ki, hogy minden rendszer normális. Az ügyfelek azonban továbbra is problémákat jelentettek. A bank vezérigazgatója, Pester Pál csak 26. április 2018-án ismerte el, hogy a TSB „térdre ereszkedett”, mivel a bank informatikai infrastruktúrájában továbbra is „sávszélesség-probléma” van, ami miatt körülbelül egymillió ügyfél nem fér hozzá az online banki szolgáltatásokhoz.
Két héttel a migráció után az online banki alkalmazás továbbra is belső hibákat észlelt az SQL-adatbázissal kapcsolatban.
A fizetési nehézségek, különösen az üzleti és jelzáloghitelek esetében, négy hétig is fennálltak. És mindenütt jelenlévő újságírók megtudták, hogy a TSB a migrációs válság legelején elutasította a Lloyds Banking Group segítségnyújtási ajánlatát. Általánosságban elmondható, hogy az online szolgáltatásokba való bejelentkezéssel és a pénzátutalási lehetőséggel kapcsolatos problémák szeptember 3-ig voltak megfigyelhetők.
Egy kis történelem
Az első ATM 27. június 1967-én nyílt meg a Barclays közelében, Enfieldben
A banki informatikai rendszerek egyre összetettebbé válnak, ahogy az ügyfelek igényei és a bankkal szembeni elvárások nőnek. Körülbelül 40-60 évvel ezelőtt szívesen felkerestük volna a helyi bankfiókunkat munkaidőben, hogy készpénzt befizessünk vagy a bankpénztáron keresztül felvegyünk.
A számlán lévő pénzösszeg közvetlenül összefüggött a banknak adott készpénzzel és érmékkel. Otthoni könyvelésünk papírral-tollal nyomon követhető volt, a számítógépes rendszereket az ügyfelek nem tudták elérni. A banki alkalmazottak betétkönyvek és egyéb adathordozók adatait helyezték el a pénzt számláló eszközökbe.
De 1967-ben először Észak-Londonban
Az ATM-ek csak a kezdet voltak. Hamarosan az emberek úgy tudták elkerülni a sort a pénztárnál, hogy egyszerűen felhívták telefonon a bankot. Ehhez speciális kártyákat kellett behelyezni egy olvasóba, amely képes megfejteni a kéthangú többfrekvenciás (DTMF) jeleket, amelyek akkor érkeznek, amikor a felhasználó megnyomja az „1” (pénzfelvétel) vagy a „2” (befizetés) gombot.
Az internet és a mobilbanki szolgáltatások közelebb vitték az ügyfeleket a bankokat működtető alaprendszerekhez. Különböző korlátaik és beállításaik ellenére ezeknek a rendszereknek hatékonyan kell együttműködniük egymással és a fő számítógéppel, számlaegyenleg-ellenőrzést, pénzátutalást stb.
Kevés ügyfél gondol arra, hogy milyen összetett az információs út, amikor például bejelentkezik egy online bankba, hogy megtekinthesse vagy frissítse a számláján lévő pénzre vonatkozó információkat. Amikor bejelentkezik, ezek az adatok egy kiszolgálón keresztül jutnak el; amikor tranzakciót hajt végre, a rendszer megkettőzi ezeket az adatokat a háttérinfrastruktúrában, amely aztán elvégzi a nehéz feladatot – pénzt utal át egyik számláról a másikra a számlák kifizetése érdekében. fizetést, és folytassa az előfizetéseket.
Most szorozza meg ezt a folyamatot több milliárddal. A Világbank által a Bill és Melinda Gates Alapítvány segítségével összeállított adatok szerint
Egy bank számos belső informatikai rendszere (mobilbank, ATM-ek stb.) nem léphet egyszerűen kölcsönhatásba egymással. Kapcsolatba kell lépniük más bankrendszerekkel Brazíliában, Kínában és Németországban. Egy francia ATM-nek képesnek kell lennie arra, hogy a valahol Bolíviában kibocsátott bankkártyán lévő pénzt kiadja.
A pénz mindig is globális volt, de a rendszer még soha nem volt ennyire összetett. A banki informatikai rendszerek használatának módjai növekszik, de a régi módok továbbra is használatban vannak. Egy bank sikere nagyban függ attól, hogy mennyire „karbantartható” az informatikai infrastruktúrája, és mennyire tud hatékonyan megbirkózni egy hirtelen fellépő hibával, amely miatt a rendszer tétlen lesz.
Nincsenek tesztek – készüljön fel a problémákra
A Banco de Sabadell vezérigazgatója, Jaime Guardiola (balra) bízott benne, hogy minden simán fog menni. Nem sikerült.
A TSB számítógépes rendszerei nem voltak túl jók a problémák gyors megoldásában. Szoftverhibák persze előfordultak, de a valóságban a bank az informatikai rendszerei túlzott bonyolultsága miatt „beszakadt”. A hatalmas leállás korai napjaiban készült jelentés szerint „az új alkalmazások kombinációja, a mikroszolgáltatások fokozott igénybevétele és két Active/Active adatközpont használata összetett kockázathoz vezetett a termelésben”.
Egyes bankok, mint például az HSBC, globálisan működnek, és ezért nagyon összetett, összekapcsolt rendszerekkel is rendelkeznek. A HSBC lancasteri IT-menedzsere szerint azonban rendszeresen tesztelik, migrálják és frissítik őket. Az HSBC-t modellnek tekinti arra vonatkozóan, hogy más bankok hogyan kezeljék informatikai rendszereiket: a személyzet odaadásával és az idejük elköltésével. Ugyanakkor elismeri, hogy egy kisebb banknak, különösen annak, amelyik nem rendelkezik migrációs tapasztalattal, nagyon nehéz feladat ezt helyesen végrehajtani.
A TSB migráció nehéz volt. Szakértők szerint pedig a banki személyzet képzettsége szempontjából egyszerűen nem tudta elérni ezt a bonyolultsági szintet. Ráadásul még arra sem vették a fáradságot, hogy előzetesen ellenőrizzék a megoldásukat, vagy teszteljék a migrációt.
A brit parlamentben a banki problémákról tartott beszédében Andrew Bailey, az FCA vezérigazgatója megerősítette ezt a gyanút. A rossz kód valószínűleg csak a kezdeti problémákat okozta a TSB-nél, de a globális pénzügyi hálózat összekapcsolt rendszerei azt eredményezték, hogy hibái állandósultak és visszafordíthatatlanok. A bank továbbra is tapasztalt váratlan hibákat informatikai architektúrájában. Az ügyfelek értelmetlen vagy a problémáikkal nem kapcsolatos üzeneteket kaptak.
A regressziós tesztelés segíthet megelőzni a katasztrófákat azáltal, hogy elkapja a rossz kódot az éles kiadás előtt, és károkat okoz azáltal, hogy olyan hibákat hoz létre, amelyeket nem lehetett visszaállítani. De a bank úgy döntött, hogy átrohan egy aknamezőn, amelyről nem is tudott. A következmények előre láthatóak voltak. A másik probléma a költségek „optimalizálása” volt. Hogyan nyilvánult meg? Az tény, hogy korábban úgy döntöttek, hogy megszüntetik a Lloyds-nál tárolt biztonsági másolatokat, mivel túl sok pénzt „esznek fel”.
A brit bankok (és mások is) négy-kilenc elérhetőségi szintet, azaz 99,99%-ot igyekeznek elérni. Ez a gyakorlatban azt jelenti, hogy az informatikai rendszernek folyamatosan elérhetőnek kell lennie, évente akár 52 perc leállással. A „három kilences” rendszer, 99,9%, első ránézésre nem sokban tér el egymástól. De a valóságban ez azt jelenti, hogy az állásidő eléri az évi 8 órát. A bank számára a „négy kilences” jó, de a „három kilences” nem.
De minden alkalommal, amikor egy vállalat megváltoztatja IT-infrastruktúráját, kockázatot vállal. Hiszen valami elromolhat. A változtatások csökkentése segíthet elkerülni a problémákat, míg a szükséges változtatások alapos tesztelést igényelnek. A brit szabályozók pedig erre a pontra összpontosították figyelmüket.
Talán az állásidő elkerülésének legegyszerűbb módja, ha egyszerűen kevesebb változtatást hajt végre. De minden bank, mint minden más cég, egyre több hasznos funkciót kénytelen bevezetni ügyfelei és saját vállalkozása számára a versenyképesség megőrzése érdekében. A bankok ugyanakkor továbbra is kötelesek gondoskodni ügyfeleikről, óvni megtakarításaikat és személyes adataikat, kényelmes feltételeket biztosítani a szolgáltatások igénybevételéhez. Kiderült, hogy a szervezetek rengeteg időt és pénzt kénytelenek áldozni informatikai infrastruktúrájuk egészségének megőrzésére, miközben új szolgáltatásokat kínálnak.
A brit Financial Conduct Authority által közzétett adatok szerint 187 és 2017 között 2018 százalékkal nőtt a bejelentett technológiai hibák száma a pénzügyi szolgáltatási szektorban az Egyesült Királyságban. Leggyakrabban a meghibásodások oka az új funkciók működésének problémája. A bankok számára ugyanakkor kritikus az összes szolgáltatás folyamatos zavartalan működése és a tranzakciók szinte azonnali jelentése. Az ügyfelek mindig idegesek, amikor a pénzük lóg valahol. A pénz miatt ideges ügyfél pedig mindig a baj jele.
Néhány hónappal a TSB kudarca után (amire a bank vezérigazgatója lemondott), az Egyesült Királyság pénzügyi szabályozói és a Bank of England
A dokumentum jogszabályi változtatásokat is javasolt. Arról volt szó, hogy a vállalaton belüli embereket felelősségre vonják azért, hogy mi történik rosszul a vállalat informatikai rendszereiben. A brit parlamenti képviselők ezt így magyarázták: „Ha Ön személyesen felelős, és csődbe juthat vagy börtönbe kerülhet, ez nagymértékben megváltoztatja a munkához való hozzáállást, beleértve a megbízhatóság és a biztonság kérdésére fordított időt is.”
Eredményei
Minden frissítés és javítás a kockázatkezelésen múlik, különösen, ha több száz millió dollárról van szó. Végül is, ha valami elromlik, az költséges lehet a pénz és a hírnév szempontjából. Nyilvánvaló dolgoknak tűnhet. A bank migráció közbeni csődje pedig sok mindenre meg kellett volna tanítania őket.
Volt. De nem tanított meg. 2019 novemberében az ismét nyereséges és lassan hírnevét javító TSB „örömmel” tette meg az ügyfeleket
Az informatikai fösvénységnek végül ára van. A TSB 134-ban 2018 millió dolláros veszteséget jelentett, szemben a 206-es 2017 millió dolláros nyereséggel. A migráció utáni költségek, beleértve az ügyfelek kompenzációját, a csalárd tranzakciók kijavítását (amelyek meredeken nőttek a banki káosz során), és a harmadik fél segítségét, összesen 419 millió dollárt tettek ki. A bank informatikai szolgáltatójának is 194 millió dollárt számláztak ki a válságban betöltött szerepéért.
Mindazonáltal, függetlenül attól, hogy milyen tanulságokat vonnak le a TSB bankcsődjéből, fennakadások továbbra is előfordulnak. Elkerülhetetlenek. De teszteléssel és jó kóddal az összeomlások és leállások jelentősen csökkenthetők. A Cloud4Y, amely gyakran segít a nagyvállalatoknak a felhőalapú infrastruktúrára való átállásban, megérti az egyik rendszerről a másikra való gyors átállás fontosságát. Ezért terhelési teszteket végezhetünk, és többszintű biztonsági mentési rendszert használhatunk, valamint olyan egyéb lehetőségeket, amelyek lehetővé teszik, hogy mindent ellenőrizzen az áttelepítés megkezdése előtt.
Mit olvashatsz még a blogon?
→
→
→
→
→
Iratkozzon fel a
Forrás: will.com