Dėl nesėkmingo IT infrastruktūros perkėlimo buvo sugadinti 1,3 mlrd. banko klientų įrašai. Visa tai lėmė nepakankamas testavimas ir lengvabūdiškas požiūris į sudėtingas IT sistemas. „Cloud4Y“ pasakoja, kaip tai atsitiko.
2018 metais anglų kalba suprato, kad jo dvejus metus trukusios „skyrybos“ su Lloyds bankų grupe (abi bendrovės susijungė 1995 m.) buvo per brangios. TSB vis dar buvo susieta su savo buvusiu partneriu per paskubomis klonuotas Lloyds IT sistemas. Blogiausia, kad bankas turėjo mokėti „alimentus“, 127 milijonų dolerių metinį licencijos mokestį.
Mažai kas mėgsta mokėti pinigus savo buvusiems, todėl 22 m. balandžio 2018 d. 18:00 TSB pradėjo paskutinį 18 mėnesių plano etapą, kuris turėjo pakeisti viską. Į Ispanijos bendrovės „Banco Sabadell“, kuri dar 2,2 metais TSB už 2015 mlrd. dolerių nusipirko, IT sistemą buvo planuota perkelti milijardus klientų įrašų.
Banco Sabadell generalinis direktorius José Olu kalbėjo apie būsimą renginį likus 2 savaitėms iki 2017 m. Kalėdų per šventinį darbuotojų susitikimą prestižinėje konferencijų salėje Barselonoje. Svarbiausias perkėlimo įrankis turėjo būti nauja „Banco Sabadell“ sukurtos sistemos versija: „Proteo“. Jis netgi buvo pervadintas Proteo4UK specialiai TSB migracijos projektui.
„Proteo4UK“ pristatyme „Banco Sabadell“ vykdomasis direktorius Jaime Guardiola Romojaro gyrėsi, kad naujoji sistema yra didelio masto, analogų Europoje neturintis projektas, prie kurio dirbo per 1000 specialistų. Ir kad jo įgyvendinimas labai paskatins Banco Sabadell augimą JK.
22 m. balandžio 2018 d. buvo paskelbta migracijos diena. Buvo ramus sekmadienio vakaras vidury pavasario. Banko IT sistemos neveikė, nes buvo perkeliami įrašai iš vienos sistemos į kitą. Vėlai sekmadienį atkūrus viešą prieigą prie banko sąskaitų, galima tikėtis, kad bankas lėtai ir sklandžiai grįš į savo veiklą.
Tačiau kol Olyu ir Guardiola Romojaro nuo scenos linksmai transliavo apie „Proteo4UK“ projekto įgyvendinimą, už migracijos procesą atsakingi darbuotojai labai nervinosi. Projektas, kuriam įgyvendinti prireikė 18 mėnesių, smarkiai atsiliko nuo grafiko ir viršijo biudžetą. Nebuvo laiko atlikti papildomus tyrimus. Tačiau visų įmonės duomenų (kurie, atminkite, milijardai įrašų) perkėlimas į kitą sistemą yra Heraklio užduotis.
Paaiškėjo, kad inžinieriai nervinosi dėl geros priežasties.
Svetainės skilimas, kurį klientai matė per ilgai
Praėjus 20 minučių po to, kai TSB atidarė prieigą prie sąskaitų, būdamas visiškai įsitikinęs, kad perkėlimas vyko sklandžiai, buvo gauti pirmieji pranešimai apie problemas.
Žmonių santaupos staiga dingo iš sąskaitų. Nereikšmingų sumų pirkimai klaidingai buvo įrašyti kaip daugiatūkstantinės išlaidos. Kai kurie žmonės prisijungę prie savo asmeninių paskyrų pamatė ne savo, o visiškai skirtingų žmonių sąskaitas.
21 val. TSB atstovai informavo vietos finansų reguliavimo instituciją (JK Financial Conduct Authority, FCA), kad bankas turi problemų. Tačiau FCA jau atkreipė dėmesį: TSB tikrai labai sugedo, o klientai buvo padaryti kvailiais. Ir, žinoma, jie pradėjo skųstis (o šiais laikais „Twitter“ ar „Facebook“ numesti kelias eilutes nėra ypač sunku). 23 val. į FCA susisiekė kita finansų reguliavimo institucija – Rizikos ribojimo reguliavimo institucija (PRA), kuri taip pat nujautė, kad kažkas negerai.
Jau gerokai po vidurnakčio jiems pavyko susisiekti su vienu iš banko atstovų. Ir užduokite jiems vienintelį klausimą: „kas, po velnių, vyksta?
Prireikė laiko suprasti tragedijos mastą, bet dabar žinome, kad perkėlimo metu buvo sugadinta 1,3 mlrd. 5,4 mln. klientų įrašų. Mažiausiai savaitę klientai negalėjo valdyti savo pinigų iš kompiuterių ar mobiliųjų įrenginių. Jie nesugebėjo sumokėti paskolos, o daugelio banko klientų kredito istorija buvo apgadinta, taip pat delspinigiai.
Taip atrodė TSB klientų internetinis bankas
Kai gedimai pradėjo ryškėti, beveik iš karto po to, banko atstovai tvirtino, kad problemos buvo „protrūkinės“. Po trijų dienų buvo paskelbtas pareiškimas, kad visos sistemos normalios. Tačiau klientai ir toliau pranešdavo apie problemas. Tik 26 m. balandžio 2018 d. banko vadovas Paulas Pesteris pripažino, kad TSB „klūpo“, nes banko IT infrastruktūroje ir toliau kilo „pralaidumo problema“, dėl kurios maždaug milijonas klientų negalėjo naudotis internetinės bankininkystės paslaugomis.
Praėjus dviem savaitėms po perkėlimo, internetinės bankininkystės programoje vis dar buvo pranešta apie vidines klaidas, susijusias su SQL duomenų baze.
Mokėjimo sunkumai, ypač su verslo ir hipotekos vekseliais, tęsėsi iki keturių savaičių. O visur esantys žurnalistai išsiaiškino, kad pačioje migracijos krizės pradžioje TSB atmetė „Lloyds Banking Group“ pagalbos pasiūlymą. Apskritai problemos, susijusios su prisijungimu prie internetinių paslaugų ir galimybe pervesti pinigus, buvo stebimos iki rugsėjo 3 d.
Truputis istorijos
Pirmasis bankomatas atidarytas 27 m. birželio 1967 d. netoli Barclays Enfilde
Bankinės IT sistemos tampa vis sudėtingesnės, nes didėja klientų poreikiai ir lūkesčiai iš banko. Maždaug prieš 40–60 metų mielai darbo valandomis apsilankydavome vietiniame banko padalinyje ir įneštume grynųjų pinigų arba išimtume juos per kasą.
Pinigų suma sąskaitoje buvo tiesiogiai susijusi su grynaisiais ir monetomis, kurias davėme bankui. Mūsų namų apskaitą buvo galima sekti rašikliu ir popieriumi, o kompiuterinės sistemos klientams nebuvo prieinamos. Banko darbuotojai duomenis iš sąskaitų knygelių ir kitų laikmenų įdėjo į įrenginius, kurie skaičiavo pinigus.
Tačiau pirmą kartą šiaurės Londone 1967 m bankomatą, kuris nebuvo banko patalpose. Ir šis įvykis pakeitė bankininkystę. Vartotojų patogumas tapo finansinių institucijų plėtros etalonu. Ir tai padėjo bankams tobulėti dirbant su klientais ir jų pinigais. Mat kol kompiuterinės sistemos buvo prieinamos tik banko darbuotojams, juos tenkino senas, „popierinis“ bendravimo su klientais būdas. Tik atsiradus bankomatams, o vėliau – internetinei bankininkystei, plačioji visuomenė gavo tiesioginę prieigą prie bankų IT sistemų.
Bankomatai buvo tik pradžia. Netrukus žmonės galėjo išvengti eilės prie kasos tiesiog paskambinę į banką telefonu. Tam reikėjo specialių kortelių, įterptų į skaitytuvą, galintį iššifruoti dviejų tonų daugiadažnius (DTMF) signalus, perduodamus, kai vartotojas paspaudžia klavišą „1“ (išsiimti pinigus) arba „2“ (įnešti lėšas).
Internetas ir mobilioji bankininkystė priartino klientus prie pagrindinių sistemų, kurios maitina bankus. Nepaisant skirtingų apribojimų ir nustatymų, visos šios sistemos turi efektyviai sąveikauti tarpusavyje ir su pagrindiniu kompiuteriu, atlikti sąskaitos likučio patikrinimus, pinigų pervedimus ir pan.
Nedaug klientų susimąsto, koks sudėtingas yra informacijos kelias, kai, pavyzdžiui, prisijungiate prie internetinio banko, norėdami peržiūrėti ar atnaujinti informaciją apie savo sąskaitoje esančius pinigus. Kai prisijungiate, šie duomenys perduodami per serverių rinkinį; kai atliekate operaciją, sistema dubliuoja šiuos duomenis užpakalinėje infrastruktūroje, kuri vėliau atlieka sunkų darbą – perveda pinigus iš vienos sąskaitos į kitą, kad apmokėtų sąskaitas. mokėjimus ir tęsti prenumeratą.
Dabar padauginkite šį procesą iš kelių milijardų. Remiantis duomenimis, kuriuos Pasaulio bankas surinko padedant Billo ir Melindos Geitsų fondui, suaugusiųjų visame pasaulyje turi banko sąskaitą. Kiekvienas iš šių žmonių turi sumokėti sąskaitas. Kažkas sumoka būsto paskolą ar perveda pinigus už vaikų klubus, kažkas sumoka už „Netflix“ prenumeratą ar debesies serverio nuomą. Ir visi šie žmonės naudojasi ne vienu banku.
Daugybė vidinių vieno banko IT sistemų (mobilioji bankininkystė, bankomatai ir kt.) neturi tiesiog sąveikauti viena su kita. Jie turi bendrauti su kitomis Brazilijos, Kinijos ir Vokietijos bankų sistemomis. Prancūziškas bankomatas turėtų galėti išduoti pinigus, esančius kažkur Bolivijoje išduotoje banko kortelėje.
Pinigai visada buvo pasauliniai, bet niekada anksčiau sistema nebuvo tokia sudėtinga. Naudojimosi bankų IT sistemomis būdų daugėja, tačiau vis dar naudojami seni būdai. Banko sėkmė labai priklauso nuo to, kiek „prižiūrima“ jo IT infrastruktūra ir kaip efektyviai bankas gali susidoroti su staiga įvykusiu gedimu, dėl kurio sistema neveiks.
Jokių testų – pasiruoškite problemoms
„Banco de Sabadell“ generalinis direktorius Jaime'as Guardiola (kairėje) buvo įsitikinęs, kad viskas vyks sklandžiai. Nepavyko.
TSB kompiuterinės sistemos nebuvo labai tinkamos greitai išspręsti problemas. Žinoma, buvo ir programinės įrangos nesklandumų, tačiau iš tikrųjų bankas „nulūžo“ dėl per didelio IT sistemų sudėtingumo. Remiantis ataskaita, kuri buvo parengta pirmosiomis didžiulio gedimo dienomis, „naujų programų derinys, padidėjęs mikropaslaugų naudojimas kartu su dviejų aktyvių / aktyvių duomenų centrų naudojimu sukėlė sudėtingą riziką gamyboje“.
Kai kurie bankai, pavyzdžiui, HSBC, veikia visame pasaulyje, todėl turi labai sudėtingas, tarpusavyje susijusias sistemas. Tačiau, pasak vieno HSBC IT vadovo Lankasteryje, jie reguliariai tikrinami, perkeliami ir atnaujinami. Jis mato HSBC kaip pavyzdį, kaip kiti bankai turėtų valdyti savo IT sistemas: skirdami darbuotojus ir skirdami savo laiką. Tačiau kartu jis pripažįsta, kad mažesniam bankui, ypač neturinčiam migracijos patirties, tai padaryti teisingai yra labai sunki užduotis.
TSB migracija buvo sunki. Ir, pasak ekspertų, banko darbuotojai tiesiog negalėjo pasiekti tokio sudėtingumo lygio kvalifikacijos požiūriu. Be to, jie net nepasivargino iš anksto patikrinti savo sprendimo ar išbandyti migracijos.
Per kalbą Didžiosios Britanijos parlamente apie bankininkystės problemas FCA generalinis direktorius Andrew Bailey patvirtino šį įtarimą. Blogas kodas tikriausiai sukėlė tik pradines TSB problemas, tačiau pasaulinio finansų tinklo tarpusavyje susijusios sistemos lėmė, kad jos klaidos buvo nuolatinės ir negrįžtamos. Bankas ir toliau matė netikėtų klaidų kitur savo IT architektūroje. Klientai gaudavo beprasmių arba su jų problemomis nesusijusių žinučių.
Regresijos testavimas galėtų padėti išvengti nelaimių, nes sugautų blogą kodą prieš jį išleidžiant į gamybą ir būtų padaryta žala, nes atsiranda klaidų, kurių negalima panaikinti. Tačiau bankas nusprendė bėgti per minų lauką, apie kurį net nežinojo. Pasekmės buvo nuspėjamos. Kita problema buvo išlaidų „optimizavimas“. Kaip tai pasireiškė? Faktas yra tas, kad anksčiau buvo nuspręsta atsisakyti atsarginių kopijų, saugomų Lloyds, nes jos „suvalgė“ per daug pinigų.
Didžiosios Britanijos bankai (ir kiti) siekia pasiekti keturių devynių prieinamumo lygį, ty 99,99%. Praktiškai tai reiškia, kad IT sistema turi būti prieinama visą laiką, prastova iki 52 minučių per metus. „Trijų devynerių“ sistema, 99,9%, iš pirmo žvilgsnio mažai kuo skiriasi. Tačiau iš tikrųjų tai reiškia, kad prastovos siekia 8 valandas per metus. Bankui „keturi devyneri“ yra gerai, bet „trys devyneri“ ne.
Tačiau kiekvieną kartą, kai įmonė keičia IT infrastruktūrą, ji rizikuoja. Juk gali kažkas ne taip. Pakeitimų mažinimas gali padėti išvengti problemų, o reikiamus pakeitimus reikia kruopščiai išbandyti. Didžiosios Britanijos reguliavimo institucijos sutelkė savo dėmesį į šį klausimą.
Galbūt paprasčiausias būdas išvengti prastovų yra tiesiog atlikti mažiau pakeitimų. Tačiau kiekvienas bankas, kaip ir bet kuri kita įmonė, siekdamas išlikti konkurencingas, yra priverstas įdiegti vis daugiau naudingų funkcijų klientams ir savo verslui. Kartu bankai ir toliau privalo rūpintis savo klientais, saugoti jų santaupas ir asmens duomenis, sudaryti patogias sąlygas naudotis paslaugomis. Pasirodo, organizacijos yra priverstos išleisti daug laiko ir pinigų, išlaikydamos savo IT infrastruktūros sveikatą, kartu siūlydamos naujas paslaugas.
Remiantis JK Finansinio elgesio tarnybos paskelbtais duomenimis, praneštų apie technologijų gedimus JK finansinių paslaugų sektoriuje 187–2017 m. Dažniausiai gedimų priežastis yra naujo funkcionalumo veikimo problemos. Kartu bankams itin svarbu užtikrinti nuolatinį nenutrūkstamą visų paslaugų veikimą ir beveik momentinį operacijų ataskaitų teikimą. Klientai visada nervinasi, kai jų pinigai kažkur kabo. O dėl pinigų nervinantis klientas visada yra bėdos ženklas.
Praėjus keliems mėnesiams po nesėkmės TSB (iki to laiko banko generalinis direktorius atsistatydino), JK finansų reguliavimo institucijos ir Anglijos bankas diskusijai veiklos tvarumo klausimais. Taigi jie bandė kelti klausimą, kaip giliai bankai nuėjo siekdami naujovių ir ar jie gali garantuoti stabilų dabartinės sistemos veikimą.
Dokumente taip pat siūlomi teisės aktų pakeitimai. Buvo siekiama, kad įmonės darbuotojai būtų atsakingi už tai, kas negerai tos įmonės IT sistemose. Didžiosios Britanijos parlamentarai tai paaiškino taip: „Kai esi asmeniškai atsakingas ir gali bankrutuoti ar sėsti į kalėjimą, tai labai pakeis požiūrį į darbą, be kita ko, padidins laiko, skiriamo patikimumo ir saugumo klausimams, kiekį.
rezultatai
Kiekvienas atnaujinimas ir pataisymas susijęs su rizikos valdymu, ypač kai tai susiję su šimtais milijonų dolerių. Juk jei kas nors nepavyks, tai gali brangiai kainuoti pinigų ir reputacijos požiūriu. Atrodytų akivaizdūs dalykai. O banko žlugimas migracijos metu turėjo juos daug ko išmokyti.
Turėjo. Bet jis manęs nemokė. 2019 metų lapkritį vėl pelninga ir pamažu reputaciją gerinusi TSB „pradžiugino“ klientus informacinių technologijų srityje. Antrasis smūgis bankui reiškė, kad 82 m. jis bus priverstas uždaryti 2020 filialus, kad sumažintų savo išlaidas. Arba jis tiesiog negalėjo sutaupyti IT specialistams.
Šykštumas naudojant IT galiausiai kainuoja. TSB pranešė, kad 134 m. patyrė 2018 mln. USD nuostolį, palyginti su 206 mln. USD pelnu 2017 m. Išlaidos po migracijos, įskaitant kompensaciją klientams, apgaulingų operacijų taisymą (kurios smarkiai išaugo per bankų chaosą) ir trečiųjų šalių pagalba, siekė 419 mln. Banko IT tiekėjui taip pat buvo skirta 194 mln. USD už vaidmenį krizėje.
Tačiau, kad ir kokios pamokos būtų išmoktos iš TSB banko žlugimo, sutrikimų vis tiek bus. Jie neišvengiami. Tačiau naudojant testavimą ir gerą kodą, gedimų ir prastovų galima žymiai sumažinti. Cloud4Y, kuri dažnai padeda didelėms įmonėms pereiti prie debesų infrastruktūros, supranta, kaip svarbu greitai pereiti iš vienos sistemos į kitą. Todėl galime atlikti apkrovos testavimą ir naudoti kelių lygių atsarginę sistemą bei kitas parinktis, kurios leidžia prieš pradedant migraciją patikrinti viską, kas įmanoma.
Ką dar galite perskaityti tinklaraštyje?
→
→
→
→
→
Užsiprenumeruokite mūsų -kanalas, kad nepraleistumėte kito straipsnio! Rašome ne dažniau kaip du kartus per savaitę ir tik darbo reikalais.
Šaltinis: www.habr.com