Malsukcesa migrado de IT-infrastrukturo rezultigis korupton de 1,3 miliardoj da bankaj klientrekordoj. Ĉio tio estis pro nesufiĉa testado kaj frivola sinteno al kompleksaj IT-sistemoj. Cloud4Y rakontas kiel ĝi okazis.
En 2018 la angla rimarkis, ke lia dujara "eksedziĝo" kun la banka grupo Lloyds (ambaŭ kompanioj kunfanditaj en 1995) estis tro multekosta. TSB daŭre estis ligita al sia iama partnero tra haste klonitaj Lloyds IT-sistemoj. Plej malbone, la banko devis pagi "alimenton", jaran licencadkotizon de 127 milionoj USD.
Malmultaj homoj ŝatas pagi monon al siaj eksuloj, do la 22-an de aprilo 2018 je la 18:00 TSB komencis la finan etapon de 18-monata plano, kiu devis ŝanĝi ĉion. Estis planite transdoni miliardojn da klientrekordoj al la IT-sistemo de la hispana kompanio Banco Sabadell, kiu aĉetis TSB por 2,2 miliardoj USD reen en 2015.
La CEO de Banco Sabadell, José Olu, parolis pri la venonta evento 2 semajnojn antaŭ Kristnasko 2017 dum festa kunlaborantaro en prestiĝa kongresejo en Barcelono. La plej grava migra ilo devis esti nova versio de la sistemo disvolvita de Banco Sabadell: Proteo. Ĝi eĉ estis renomita Proteo4UK specife por la TSB-migradprojekto.
Ĉe la prezento de Proteo4UK, la plenuma direktoro de Banco Sabadell, Jaime Guardiola Romojaro, fanfaronis, ke la nova sistemo estas grandskala projekto, kiu ne havas analogojn en Eŭropo, pri kiu laboris pli ol 1000 specialistoj. Kaj ke ĝia efektivigo provizos gravan akcelon al la kresko de Banco Sabadell en Britio.
La 22-an de aprilo 2018 estis fiksita kiel migrada tago. Estis kvieta dimanĉa vespero meze de printempo. La IT-sistemoj de la banko estis malfunkciaj kiam rekordoj estis transdonitaj de unu sistemo al alia. Kun publika aliro al bankkontoj restarigitaj malfrue dimanĉe, oni atendus, ke la banko malrapide kaj glate revenos al servo.
Sed dum Olyu kaj Guardiola Romojaro ĝoje elsendis de la scenejo pri la efektivigo de la projekto Proteo4UK, la dungitoj respondecaj pri la migra procezo estis tre nervozaj. La projekto, kiu daŭris 18 monatojn por kompletigi, estis grave malantaŭ horaro kaj superbuĝeto. Ne estis tempo por fari pliajn provojn. Sed transdoni ĉiujn datumojn de la kompanio (kiu, memoru, estas miliardoj da rekordoj) al alia sistemo estas herkula tasko.
Montriĝis, ke la inĝenieroj estis nervozaj pro bona kialo.
Stumpo en la retejo, kiun klientoj vidis tro longe
20 minutojn post kiam TSB malfermis aliron al la kontoj, estante plene certa ke la migrado iris glate, la unuaj raportoj pri problemoj alvenis.
La ŝparaĵoj de homoj subite malaperis el siaj kontoj. Aĉetoj de sensignifaj kvantoj estis erare registritaj kiel multmil-dolaraj elspezoj. Iuj homoj ensalutis en siajn personajn kontojn kaj vidis ne siajn bankkontojn, sed la kontojn de tute malsamaj homoj.
Je 21:00, TSB-reprezentantoj informis la lokan financan reguliganton (la UK Financial Conduct Authority, FCA) ke la banko havas problemojn. Sed la FCA jam rimarkis: TSB vere fuŝis malbone, kaj klientoj estas malsaĝigitaj. Kaj, kompreneble, ili komencis plendi (kaj nuntempe, faligi kelkajn liniojn en Twitter aŭ Fejsbuko ne estas precipe malfacila). Je 23:30 p.m., la FCA estis kontaktita de alia financa reguligisto, la Prudential Regulation Authority (PRA), kiu ankaŭ sentis, ke io estas malĝusta.
Jam bone post noktomezo ili sukcesis trairi al unu el la bankreprezentantoj. Kaj demandu al ili la solan demandon: "kio diable okazas?"
Necesis tempo por kompreni la amplekson de la tragedio, sed ni nun scias, ke 1,3 miliardoj da rekordoj de 5,4 milionoj da klientoj estis difektitaj dum la migrado. Dum almenaŭ semajno, klientoj ne povis administri sian monon de siaj komputiloj aŭ porteblaj aparatoj. Ili ne povis pagi la prunton, kaj multaj bankklientoj ricevis makulon en sia kredithistorio, same kiel malfruajn kotizojn.
Jen kiel aspektis la reta banko de kliento de TSB
Kiam misfunkciadoj komencis aperi, preskaŭ tuj poste, bankreprezentantoj insistis, ke la problemoj estas "periodaj". Tri tagojn poste, deklaro estis emisiita ke ĉiuj sistemoj estis normalaj. Sed klientoj daŭre raportis problemojn. Daŭris ĝis la 26-an de aprilo 2018, ke la ĉef-oficulo de la banko, Paul Pester, koncedis, ke TSB estis "surgenue" ĉar la IT-infrastrukturo de la banko daŭre havis "bendolarĝan problemon" malhelpante ĉirkaŭ milionon da klientoj aliri retajn bankservojn.
Du semajnojn en la migrado, la interreta bankada aplikaĵo ankoraŭ estis spertanta internajn erarojn ligitajn al la SQL-datumbazo.
Pagmalfacilaĵoj, precipe kun komercaj kaj hipotekaj fakturoj, daŭris ĝis kvar semajnoj. Kaj ĉieaj ĵurnalistoj eksciis, ke TSB malakceptis proponon de helpo de Lloyds Banking Group ĉe la komenco mem de la migra krizo. Ĝenerale, problemoj asociitaj kun ensaluto en interretaj servoj kaj la kapablo transdoni monon estis observitaj ĝis la 3-a de septembro.
Iom da historio
La unua ATM malfermiĝis la 27an de junio 1967 proksime de Barclays en Enfield
Bankaj IT-sistemoj fariĝas ĉiam pli kompleksaj kiam klientbezonoj kaj atendoj de la banko pliiĝas. Antaŭ Ĉirkaŭ 40-60 jaroj, ni estus feliĉaj viziti nian lokan bankan filion dum komercaj horoj por deponi monon aŭ retiri ĝin per la kasisto.
La monsumo en la konto estis rekte rilata al la kontantmono kaj moneroj, kiujn ni donis al la banko. Nia hejma kontado povus esti spurita per skribilo kaj papero, kaj komputilaj sistemoj ne estis alireblaj por klientoj. Bankodungitoj metis datumojn de paslibroj kaj aliaj amaskomunikiloj en aparatojn, kiuj kalkulis la monon.
Sed en 1967 en norda Londono unuafoje ATM kiu ne situis en la banka ejo. Kaj ĉi tiu evento ŝanĝis bankadon. Uzanta oportuneco fariĝis komparnormo por la disvolviĝo de financaj institucioj. Kaj ĉi tio helpis bankojn fariĝi pli kompleksaj koncerne laboradon kun klientoj kaj ilia mono. Post ĉio, dum komputilaj sistemoj estis haveblaj nur al bankdungitoj, ili estis kontentaj pri la malnova, "papera" maniero interagi kun klientoj. Nur kun la apero de ATM kaj tiam reta bankado, la ĝenerala publiko akiris rektan aliron al bankaj IT-sistemoj.
ATMs estis nur la komenco. Baldaŭ homoj povis eviti la linion ĉe la kasregistrilo simple telefone telefone al la banko. Ĉi tio postulis specialajn kartojn enigitajn en leganton kapablan deĉifri la du-tonajn multfrekvencajn (DTMF) signalojn elsenditajn kiam la uzanto premis la ŝlosilon "1" (retiri monon) aŭ "2" (deponaj fondusoj).
Interreto kaj poŝtelefona bankado alproksimigis klientojn al la kernaj sistemoj, kiuj funkciigas bankojn. Malgraŭ iliaj diversaj limigoj kaj agordoj, ĉiuj ĉi tiuj sistemoj devas interagi efike unu kun la alia kaj kun la ĉefkomputilo, farante kontajn ekvilibrajn kontrolojn, farante montranspagojn, ktp.
Malmultaj klientoj pensas pri kiom kompleksa estas la informvojo kiam vi, ekzemple, ensalutas en interretan bankon por vidi aŭ ĝisdatigi informojn pri la mono en via konto. Kiam vi ensalutas, ĉi tiuj datumoj estas trapasitaj tra aro da serviloj; kiam vi faras transakcion, la sistemo duobligas ĉi tiujn datumojn en la backend-infrastrukturo, kiu tiam faras la pezan ŝarĝon - translokante monon de unu konto al alia por pagi fakturojn, fari pagoj, kaj daŭrigi abonojn.
Nun multigu ĉi tiun procezon per pluraj miliardoj. Laŭ datumoj kompilitaj de la Monda Banko kun la helpo de la Fondaĵo Bill kaj Melinda Gates, plenkreskuloj tra la tuta mondo havas bankkonton. Ĉiu el ĉi tiuj homoj havas fakturojn por pagi. Iu pagas hipotekon aŭ transdonas monon por infanaj kluboj, iu pagas por Netflix-abono aŭ lui nuban servilon. Kaj ĉiuj ĉi homoj uzas pli ol unu bankon.
Multnombraj internaj IT-sistemoj de unu banko (movebla bankado, ATM-oj, ktp.) ne devas simple interagi unu kun la alia. Ili devas interagi kun aliaj bankaj sistemoj en Brazilo, Ĉinio kaj Germanio. Franca ATM devus povi disdoni monon, kiu estas sur bankkarto eldonita ie en Bolivio.
Mono ĉiam estis tutmonda, sed neniam antaŭe la sistemo estis tiel kompleksa. La nombro da manieroj uzi bankajn IT-sistemojn pliiĝas, sed la malnovaj manieroj daŭre estas uzataj. La sukceso de banko plejparte dependas de kiom "daŭrigebla" ĝia IT-infrastrukturo estas, kaj kiom efike la banko povas elteni subitan fiaskon pro kiu la sistemo estos senaktiva.
Neniuj provoj - preparu por problemoj
La CEO de Banco de Sabadell, Jaime Guardiola (maldekstre) estis certa, ke ĉio iros glate. Ne funkciis.
La komputilaj sistemoj de TSB ne tre bone solvis problemojn rapide. Ekzistis, kompreneble, programaj misfunkciadoj, sed fakte la banko "rompiĝis" pro la troa komplekseco de siaj IT-sistemoj. Laŭ la raporto, kiu estis preparita en la fruaj tagoj de la amasa malfunkcio, "la kombinaĵo de novaj aplikoj, pliigita uzo de mikroservoj kombinita kun la uzo de du Aktivaj / Aktivaj datumcentroj kondukis al kompleksa risko en produktado."
Iuj bankoj, kiel HSBC, funkcias tutmonde kaj tial ankaŭ havas tre kompleksajn, interligitajn sistemojn. Sed ili estas regule testitaj, migritaj kaj ĝisdatigitaj, laŭ unu HSBC IT-manaĝero en Lancaster. Li vidas HSBC kiel modelon pri kiel aliaj bankoj administru siajn IT-sistemojn: dediĉante personaron kaj pasigante sian tempon. Sed samtempe li akceptas, ke por pli malgranda banko, precipe tiu, kiu ne havas migradan sperton, fari tion ĝuste estas tre malfacila tasko.
La TSB-migrado estis malfacila. Kaj, laŭ fakuloj, la banka personaro simple ne povis atingi ĉi tiun nivelon de komplekseco laŭ kvalifikoj. Krome, ili eĉ ne ĝenis kontroli sian solvon aŭ testi la migradon anticipe.
Dum parolado en la Brita Parlamento pri bankaj problemoj, Andrew Bailey, ĉefo de la FCA, konfirmis ĉi tiun suspekton. Malbona kodo verŝajne nur kaŭzis la komencajn problemojn ĉe TSB, sed la interligitaj sistemoj de la tutmonda financa reto signifis, ke ĝiaj eraroj estis eternigitaj kaj neinversigeblaj. La banko daŭre vidis neatenditajn erarojn aliloke en sia IT-arkitekturo. Klientoj ricevis mesaĝojn sensignifajn aŭ senrilatajn al siaj problemoj.
Regresa testado povus helpi malhelpi katastrofon kaptante malbonan kodon antaŭ ol ĝi estis liberigita en produktadon kaj kaŭzis damaĝon kreante cimojn, kiuj ne povus esti reigitaj. Sed la banko decidis kuri tra minkampo, pri kiu ĝi eĉ ne sciis. La sekvoj estis antaŭvideblaj. Alia problemo estis la "optimumigo" de kostoj. Kiel ĝi manifestiĝis? La fakto estas, ke antaŭe oni decidis forigi la rezervajn kopiojn konservitajn ĉe Lloyds, ĉar ili "manĝis" tro da mono.
Britaj bankoj (kaj ankaŭ aliaj) strebas atingi nivelon de havebleco kvar-naŭa, tio estas, 99,99%. En la praktiko, tio signifas, ke la IT-sistemo devas esti disponebla ĉiam, kun ĝis 52 minutoj da malfunkcio jare. La sistemo "tri naŭoj", 99,9%, unuavide ne multe diferencas. Sed fakte tio signifas, ke malfunkcio atingas 8 horojn jare. Por la banko, "kvar naŭoj" estas bona, sed "tri naŭoj" ne.
Sed ĉiufoje kiam kompanio faras ŝanĝojn al sia IT-infrastrukturo, ĝi prenas riskojn. Post ĉio, io povas misfunkcii. Redukti ŝanĝojn povas helpi eviti problemojn, dum postulataj ŝanĝoj bezonas zorgan testadon. Kaj britaj reguligistoj enfokusigis sian atenton pri ĉi tiu punkto.
Eble la plej facila maniero eviti malfunkcion estas simple fari malpli da ŝanĝoj. Sed ĉiu banko, kiel ĉiu alia kompanio, estas devigita enkonduki pli kaj pli da utilaj funkcioj por klientoj kaj sia propra komerco por resti konkurenciva. Samtempe, bankoj ankoraŭ devas zorgi pri siaj klientoj, protektante siajn ŝparaĵojn kaj personajn datumojn, disponigante komfortajn kondiĉojn por uzi servojn. Rezultas, ke organizoj estas devigitaj elspezi multan tempon kaj monon por konservi la sanon de sia IT-infrastrukturo, samtempe proponante novajn servojn.
La nombro da raportitaj teknologiaj malsukcesoj en la financa servo en la UK pliiĝis je 187 procentoj inter 2017 kaj 2018, laŭ datumoj publikigitaj de la Financa Konduta Aŭtoritato de Britio. Plej ofte, la kaŭzo de misfunkciadoj estas problemoj en la funkciado de novaj funkcioj. Samtempe, estas kritike por bankoj certigi la konstantan seninterrompan funkciadon de ĉiuj servoj kaj preskaŭ tujan raportadon de transakcioj. Klientoj ĉiam estas nervozaj kiam ilia mono estas ie. Kaj kliento, kiu estas nervoza pri mono, ĉiam estas signo de problemo.
Kelkajn monatojn post la fiasko ĉe TSB (ĝis tiu tempo la ĉefoficisto de la banko eksiĝis), britaj financaj reguligistoj kaj la Banko de Anglio por diskuto pri operaciaj daŭripovaj aferoj. Do ili provis levi la demandon pri kiom profundaj bankoj iris por serĉi novigon, kaj ĉu ili povas garantii la stabilan funkciadon de la sistemo, kiun ili havas nun.
La dokumento ankaŭ proponis ŝanĝojn al leĝaro. Temis pri respondecigi homojn ene de la firmao pri tio, kio misfunkcias en la IT-sistemoj de tiu firmao. Britaj parlamentanoj klarigis ĝin jene: "Kiam vi estas persone respondeca, kaj vi povas bankroti aŭ iri al malliberejo, tio multe ŝanĝos la sintenon al laboro, inkluzive de pliigo de la tempo dediĉita al la temo de fidindeco kaj sekureco."
Rezultoj
Ĉiu ĝisdatigo kaj flikaĵo rilatas al riska administrado, precipe kiam centoj da milionoj da dolaroj estas implikitaj. Post ĉio, se io misfunkcias, ĝi povas esti multekosta laŭ mono kaj reputacio. Ŝajnus evidentaj aferoj. Kaj la fiasko de la banko dum migrado devus esti instruinta al ili multon.
Havis. Sed li ne instruis min. En novembro 2019, TSB, kiu denove atingis profiton kaj malrapide plibonigis sian reputacion, "ĝojigis" klientojn. en la kampo de informa teknologio. La dua bato al la banko signifis, ke ĝi estos devigita fermi 82 filiojn en 2020 por tranĉi siajn kostojn. Aŭ li simple ne povis ŝpari pri IT-specialistoj.
Avareco kun IT finfine kostas. TSB raportis perdon de 134 milionoj USD en 2018, kompare kun profito de 206 milionoj USD en 2017. Post-migradokostoj, inkluzive de klientkompenso, korektado de fraŭdaj transakcioj (kiuj akre pliiĝis dum la banka kaoso), kaj triaparta asistado, nombris 419 milionojn USD. La IT-provizanto de la banko ankaŭ estis fakturita 194 milionoj USD por sia rolo en la krizo.
Tamen, negrave kiaj lecionoj estas lernitaj de la fiasko de la banko de TSB, interrompoj ankoraŭ okazos. Ili estas neeviteblaj. Sed kun testado kaj bona kodo, kraŝoj kaj malfunkciaj tempoj povas esti multe reduktitaj. Cloud4Y, kiu ofte helpas grandajn kompaniojn migri al nuba infrastrukturo, komprenas la gravecon rapide moviĝi de unu sistemo al alia. Tial ni povas fari ŝarĝtestadon kaj uzi plurnivelan rezervan sistemon, same kiel aliajn eblojn, kiuj ebligas al vi kontroli ĉion eblan antaŭ ol komenci la migradon.
Kion alian vi povas legi en la blogo?
→
→
→
→
→
Abonu nian -kanalo, por ne maltrafi la sekvan artikolon! Ni skribas ne pli ol dufoje semajne kaj nur pri komerco.
fonto: www.habr.com