Nieudana migracja infrastruktury IT spowodowała uszkodzenie 1,3 miliarda rekordów klientów banków. Wszystko wynikało z niewystarczających testów i niepoważnego podejścia do skomplikowanych systemów informatycznych. Cloud4Y opowiada, jak do tego doszło.
W 2018 roku język angielski zdał sobie sprawę, że jego dwuletni „rozwód” z grupą bankową Lloyds (obie firmy połączyły się w 1995 r.) był zbyt kosztowny. TSB nadal było powiązane ze swoim byłym partnerem poprzez pospiesznie sklonowane systemy informatyczne Lloyds. Co najgorsze, bank musiał płacić „alimenty”, czyli roczną opłatę licencyjną w wysokości 127 milionów dolarów.
Niewiele osób lubi płacić swoim byłym, dlatego 22 kwietnia 2018 roku o godzinie 18:00 TSB rozpoczął się ostatni etap 18-miesięcznego planu, który miał wszystko zmienić. Planowano przenieść miliardy rekordów klientów do systemu informatycznego hiszpańskiej firmy Banco Sabadell, która w 2,2 roku kupiła TSB za 2015 miliarda dolarów.
Dyrektor generalny Banco Sabadell, José Olu, mówił o nadchodzącym wydarzeniu na 2 tygodnie przed Bożym Narodzeniem 2017 podczas uroczystego spotkania pracowników w prestiżowej sali konferencyjnej w Barcelonie. Najważniejszym narzędziem migracji miała być nowa wersja systemu opracowanego przez Banco Sabadell: Proteo. Specjalnie na potrzeby projektu migracji TSB zmieniono nawet jego nazwę na Proteo4UK.
Podczas prezentacji Proteo4UK dyrektor wykonawczy Banco Sabadell Jaime Guardiola Romojaro pochwalił się, że nowy system to projekt zakrojony na szeroką skalę, nie mający odpowiednika w Europie, nad którym pracowało ponad 1000 specjalistów. I że jego wdrożenie zapewni znaczący impuls do rozwoju Banco Sabadell w Wielkiej Brytanii.
Dzień migracji wyznaczono na 22 kwietnia 2018 roku. Był spokojny niedzielny wieczór w środku wiosny. Systemy informatyczne banku uległy awarii w związku z przenoszeniem dokumentów z jednego systemu do drugiego. Po przywróceniu publicznego dostępu do rachunków bankowych w niedzielę późnym wieczorem można było oczekiwać, że bank będzie powoli i płynnie wracał do pracy.
Ale podczas gdy Olyu i Guardiola Romojaro radośnie transmitowali ze sceny relację z realizacji projektu Proteo4UK, pracownicy odpowiedzialni za proces migracji byli bardzo zdenerwowani. Projekt, którego realizacja trwała 18 miesięcy, był poważnie opóźniony w stosunku do harmonogramu i przekroczył budżet. Nie było czasu na przeprowadzenie dodatkowych badań. Ale przeniesienie wszystkich danych firmy (które, pamiętajcie, to miliardy rekordów) do innego systemu, to zadanie herkulesowe.
Okazało się, że inżynierowie byli zdenerwowani nie bez powodu.
Fragment witryny, który klienci widzieli zbyt długo
Po 20 minutach od otwarcia przez TSB dostępu do rachunków, mając całkowitą pewność, że migracja przebiegła sprawnie, nadeszły pierwsze raporty o problemach.
Oszczędności ludzi nagle zniknęły z ich kont. Zakupy na nieznaczne kwoty zostały błędnie zaksięgowane jako wielotysięczne wydatki. Część osób zalogowała się na swoje konta osobiste i zobaczyła nie swoje konta bankowe, ale konta zupełnie innych osób.
O godzinie 21:00 przedstawiciele TSB poinformowali lokalny organ nadzoru finansowego (brytyjski Urząd Nadzoru Finansowego, FCA), że bank ma kłopoty. Ale FCA już to zauważyła: TSB naprawdę schrzaniła sprawę, a klienci zostali oszukani. I, oczywiście, zaczęli narzekać (a w dzisiejszych czasach rzucenie kilku linijek na Twitterze czy Facebooku nie jest szczególnie trudne). O 23:30 z FCA skontaktował się inny organ nadzoru finansowego, Urząd Regulacji Ostrożnościowych (PRA), który również wyczuł, że coś jest nie tak.
Już dobrze po północy udało im się dodzwonić do jednego z przedstawicieli banku. I zadaj im jedyne pytanie: „co się do cholery dzieje?”
Zrozumienie skali tragedii zajęło trochę czasu, ale teraz wiemy, że podczas migracji ucierpiało 1,3 miliarda rekordów 5,4 miliona klientów. Przez co najmniej tydzień klienci nie mogli zarządzać swoimi pieniędzmi ze swoich komputerów i urządzeń mobilnych. Nie byli w stanie spłacić kredytu, a wielu klientów banków miało skazę na historii kredytowej, a także opłaty za zwłokę.
Tak wyglądał bank internetowy klienta TSB
Kiedy niemal natychmiast po tym zaczęły pojawiać się usterki, przedstawiciele banku upierali się, że problemy mają charakter „sporadyczny”. Trzy dni później wydano oświadczenie, że wszystkie systemy działają normalnie. Jednak klienci nadal zgłaszali problemy. Dopiero 26 kwietnia 2018 roku dyrektor generalny banku, Paul Pester, przyznał, że TSB „klęczy”, ponieważ w infrastrukturze IT banku w dalszym ciągu występują „problemy z przepustowością”, uniemożliwiające około milionowi klientów dostęp do usług bankowości internetowej.
Po dwóch tygodniach migracji w aplikacji bankowości internetowej nadal zgłaszano błędy wewnętrzne związane z bazą danych SQL.
Trudności z płatnościami, zwłaszcza w przypadku rachunków biznesowych i hipotecznych, trwały do czterech tygodni. A wszechobecni dziennikarze dowiedzieli się, że TSB już na początku kryzysu migracyjnego odrzuciło ofertę pomocy Lloyds Banking Group. Generalnie do 3 września obserwowano problemy związane z logowaniem do serwisów internetowych i możliwością przesyłania pieniędzy.
Trochę historii
Pierwszy bankomat został otwarty 27 czerwca 1967 roku w pobliżu Barclays w Enfield
Bankowe systemy informatyczne stają się coraz bardziej złożone wraz ze wzrostem potrzeb klientów i oczekiwań wobec banku. Około 40-60 lat temu chętnie odwiedzalibyśmy oddział naszego lokalnego banku w godzinach pracy, aby wpłacić gotówkę lub wypłacić ją za pośrednictwem kasy.
Ilość pieniędzy na koncie była bezpośrednio powiązana z gotówką i monetami, które przekazaliśmy bankowi. Księgowość naszego domu można było śledzić za pomocą pióra i papieru, a systemy komputerowe nie były dostępne dla klientów. Pracownicy banku umieszczali dane z książeczek oszczędnościowych i innych nośników w urządzeniach liczących pieniądze.
Ale w 1967 roku po raz pierwszy w północnym Londynie bankomat, który nie znajdował się na terenie banku. I to wydarzenie zmieniło bankowość. Wygoda użytkownika stała się wyznacznikiem rozwoju instytucji finansowych. Pomogło to bankom stać się bardziej wyrafinowanymi pod względem pracy z klientami i ich pieniędzmi. W końcu, choć systemy komputerowe były dostępne tylko dla pracowników banków, to im wystarczył stary, „papierowy” sposób interakcji z klientami. Dopiero wraz z pojawieniem się bankomatów, a następnie bankowości internetowej, społeczeństwo uzyskało bezpośredni dostęp do systemów informatycznych banków.
Bankomaty to dopiero początek. Wkrótce ludzie mogli uniknąć kolejek do kasy, po prostu dzwoniąc do banku przez telefon. Wymagało to włożenia do czytnika specjalnych kart zdolnych do rozszyfrowania dwutonowych sygnałów wieloczęstotliwościowych (DTMF) przesyłanych po naciśnięciu przez użytkownika klawisza „1” (wypłata pieniędzy) lub „2” (wpłata środków).
Bankowość internetowa i mobilna przybliżyła klientów do kluczowych systemów zasilających banki. Pomimo różnych ograniczeń i ustawień, wszystkie te systemy muszą skutecznie współdziałać ze sobą oraz z komputerem głównym, sprawdzając saldo konta, wykonując przelewy pieniężne i tak dalej.
Niewielu klientów zastanawia się, jak złożona jest ścieżka informacji, gdy na przykład logujesz się do banku internetowego, aby wyświetlić lub zaktualizować informacje o pieniądzach na koncie. Kiedy się logujesz, dane te są przesyłane przez zestaw serwerów; kiedy dokonujesz transakcji, system duplikuje te dane w infrastrukturze zaplecza, która następnie wykonuje całą ciężką pracę — przesyła pieniądze z jednego konta na drugie, aby opłacić rachunki, dokonać płatności i kontynuować subskrypcję.
Teraz pomnóż ten proces przez kilka miliardów. Według danych opracowanych przez Bank Światowy przy pomocy Fundacji Billa i Melindy Gatesów, dorośli na całym świecie mają konto bankowe. Każda z tych osób ma rachunki do zapłacenia. Ktoś płaci kredyt hipoteczny lub przelewa pieniądze na kluby dziecięce, ktoś płaci za abonament Netflix lub wynajmuje serwer w chmurze. I wszystkie te osoby korzystają z więcej niż jednego banku.
Liczne wewnętrzne systemy informatyczne jednego banku (bankowość mobilna, bankomaty itp.) nie mogą po prostu współdziałać ze sobą. Muszą współdziałać z innymi systemami bankowymi w Brazylii, Chinach i Niemczech. Francuski bankomat powinien móc wypłacać pieniądze znajdujące się na karcie bankowej wydanej gdzieś w Boliwii.
Pieniądz zawsze miał charakter globalny, ale nigdy wcześniej system nie był tak złożony. Liczba sposobów wykorzystania bankowych systemów informatycznych rośnie, jednak nadal stosowane są stare sposoby. Sukces banku w dużej mierze zależy od tego, jak „utrzymalna” jest jego infrastruktura informatyczna i jak skutecznie bank poradzi sobie z nagłą awarią, w wyniku której system będzie przestojowy.
Żadnych testów – przygotuj się na problemy
Dyrektor generalny Banco de Sabadell Jaime Guardiola (po lewej) był pewien, że wszystko pójdzie gładko. Nie wypracował.
Systemy komputerowe TSB nie były zbyt dobre w szybkim rozwiązywaniu problemów. Zdarzały się oczywiście błędy w oprogramowaniu, ale tak naprawdę bank „zbankrutował” z powodu nadmiernej złożoności systemów informatycznych. Według raportu, który powstał na początku masowej awarii, „połączenie nowych aplikacji, zwiększone wykorzystanie mikrousług w połączeniu z wykorzystaniem dwóch centrów danych Active/Active doprowadziło do złożonego ryzyka w produkcji”.
Niektóre banki, takie jak HSBC, działają globalnie i dlatego mają również bardzo złożone, wzajemnie powiązane systemy. Według jednego z menedżerów IT HSBC w Lancaster są one jednak regularnie testowane, migrowane i aktualizowane. Postrzega HSBC jako wzór tego, jak inne banki powinny zarządzać swoimi systemami informatycznymi: poświęcając pracowników i spędzając ich czas. Ale jednocześnie przyznaje, że dla mniejszego banku, zwłaszcza takiego, który nie ma doświadczenia migracyjnego, prawidłowe wykonanie tego jest bardzo trudnym zadaniem.
Migracja TSB była trudna. Zdaniem ekspertów pracownicy banku po prostu nie mogliby osiągnąć tego poziomu złożoności pod względem kwalifikacji. Co więcej, nawet nie zadali sobie trudu, aby wcześniej sprawdzić swoje rozwiązanie lub przetestować migrację.
Podczas przemówienia w brytyjskim parlamencie na temat problemów bankowych Andrew Bailey, dyrektor naczelny FCA, potwierdził te podejrzenia. Zły kod prawdopodobnie spowodował jedynie początkowe problemy w TSB, ale wzajemnie połączone systemy globalnej sieci finansowej sprawiły, że błędy te utrwaliły się i były nieodwracalne. Bank w dalszym ciągu odnotowywał nieoczekiwane błędy w innych miejscach swojej architektury IT. Klienci otrzymywali wiadomości, które były bez znaczenia lub niezwiązane z ich problemami.
Testy regresyjne mogą pomóc w zapobieganiu katastrofom, wyłapując zły kod przed wprowadzeniem go do środowiska produkcyjnego i powodując szkody w postaci błędów, których nie można cofnąć. Ale bank postanowił przebiec przez pole minowe, o którym nawet nie wiedział. Konsekwencje były do przewidzenia. Kolejnym problemem była „optymalizacja” kosztów. Jak się to objawiało? Faktem jest, że wcześniej zdecydowano się zrezygnować z kopii zapasowych przechowywanych w Lloyds, ponieważ „pochłaniały” za dużo pieniędzy.
Banki brytyjskie (i inne też) dążą do osiągnięcia poziomu dostępności cztery dziewiątki, czyli 99,99%. W praktyce oznacza to, że system informatyczny musi być dostępny przez cały czas, z maksymalnie 52 minutami przestoju w skali roku. System „trzech dziewiątek” na 99,9% na pierwszy rzut oka nie różni się zbytnio. Ale w rzeczywistości oznacza to, że przestoje sięgają 8 godzin rocznie. Dla banku „cztery dziewiątki” są dobre, ale „trzy dziewiątki” już nie.
Jednak za każdym razem, gdy firma wprowadza zmiany w swojej infrastrukturze IT, podejmuje ryzyko. W końcu coś może pójść nie tak. Ograniczenie zmian może pomóc uniknąć problemów, natomiast wymagane zmiany wymagają dokładnego przetestowania. Brytyjscy regulatorzy skupili swoją uwagę na tym punkcie.
Być może najłatwiejszym sposobem uniknięcia przestojów jest po prostu wprowadzenie mniejszej liczby zmian. Jednak każdy bank, jak każda inna firma, aby zachować konkurencyjność, zmuszony jest wprowadzać coraz więcej funkcji przydatnych dla klientów i własnego biznesu. Jednocześnie banki w dalszym ciągu mają obowiązek dbać o swoich klientów, chroniąc ich oszczędności i dane osobowe, zapewniając komfortowe warunki korzystania z usług. Okazuje się, że organizacje zmuszone są poświęcać dużo czasu i pieniędzy na utrzymanie dobrej kondycji swojej infrastruktury IT, oferując jednocześnie nowe usługi.
Według danych opublikowanych przez brytyjski Urząd Nadzoru Finansowego liczba zgłoszonych awarii technologicznych w sektorze usług finansowych w Wielkiej Brytanii wzrosła o 187 procent w latach 2017–2018. Najczęściej przyczyną awarii są problemy w działaniu nowej funkcjonalności. Jednocześnie dla banków niezwykle ważne jest zapewnienie stałego, nieprzerwanego działania wszystkich usług i niemal natychmiastowego raportowania transakcji. Klienci zawsze się denerwują, gdy ich pieniądze gdzieś wiszą. A klient, który denerwuje się pieniędzmi, jest zawsze oznaką kłopotów.
Kilka miesięcy po upadku TSB (kiedy to dyrektor generalny banku złożył rezygnację) brytyjskie organy nadzoru finansowego i Bank Anglii do dyskusji na temat kwestii zrównoważonego rozwoju operacyjnego. Próbowano więc postawić pytanie, jak głęboko banki poszły w pogoń za innowacjami i czy są w stanie zagwarantować stabilne działanie systemu, który obecnie posiadają.
W dokumencie zaproponowano także zmiany w przepisach. Chodziło o pociągnięcie ludzi w firmie do odpowiedzialności za to, co pójdzie nie tak w systemach informatycznych tej firmy. Brytyjscy parlamentarzyści tak to wyjaśniali: „Kiedy jesteś osobiście odpowiedzialny, a możesz zbankrutować lub pójść do więzienia, to ogromnie zmieni to podejście do pracy, w tym zwiększy ilość czasu poświęcanego kwestiom niezawodności i bezpieczeństwa”.
Wyniki
Każda aktualizacja i łatka sprowadza się do zarządzania ryzykiem, zwłaszcza gdy w grę wchodzą setki milionów dolarów. W końcu, jeśli coś pójdzie nie tak, może to być kosztowne pod względem pieniędzy i reputacji. Wydawałoby się, że to rzeczy oczywiste. A porażka banku podczas migracji powinna ich wiele nauczyć.
Miał. Ale on mnie nie nauczył. W listopadzie 2019 roku TSB, które ponownie osiągnęło rentowność i powoli poprawiało swoją reputację, „zachwyciło” klientów w dziedzinie technologii informatycznych. Drugi cios w bank oznaczał, że w 82 roku będzie on zmuszony zamknąć 2020 oddziały, aby obciąć koszty. Albo po prostu nie mógł oszczędzać na specjalistach IT.
Skąpstwo w IT ostatecznie ma swoją cenę. TSB odnotowało stratę w wysokości 134 mln dolarów w 2018 roku w porównaniu z zyskiem w wysokości 206 mln dolarów w 2017 roku. Koszty po migracji, w tym odszkodowania dla klientów, korygowanie fałszywych transakcji (które gwałtownie wzrosły podczas chaosu bankowego) oraz pomoc stron trzecich, wyniosły 419 milionów dolarów. Dostawca usług informatycznych banku również został obciążony kwotą 194 mln dolarów za swoją rolę w kryzysie.
Niezależnie jednak od wniosków, jakie wyciągniemy z upadłości banku TSB, zakłócenia nadal będą występować. Są nieuniknione. Jednak dzięki testowaniu i dobremu kodowi awarie i przestoje można znacznie ograniczyć. Cloud4Y, który często pomaga dużym firmom w migracji do infrastruktury chmurowej, rozumie, jak ważne jest szybkie przejście z jednego systemu do drugiego. Dlatego możemy przeprowadzić testy obciążeniowe i skorzystać z wielopoziomowego systemu tworzenia kopii zapasowych, a także innych opcji, które pozwalają sprawdzić wszystko, co możliwe, przed rozpoczęciem migracji.
Co jeszcze można przeczytać na blogu?
→
→
→
→
→
Zapisz się do naszego -channel, żeby nie przegapić kolejnego artykułu! Piszemy nie częściej niż dwa razy w tygodniu i tylko w sprawach służbowych.
Źródło: www.habr.com