Няўдалая міграцыя ІТ-інфраструктуры прывяла да пашкоджання 1,3 запісаў кліентаў банка. Усяму віной стала недастатковае тэставанне і легкадумнае стаўленне да складаных ІТ-сістэм. Cloud4Y распавядае, як гэта было.
У 2018 годзе англійская зразумеў, што яго "развод" двухгадовай даўніны з банкаўскай групай Lloyds (абедзве кампаніі аб'ядналіся ў 1995 годзе) абыходзіцца занадта дорага. TSB па-ранейшаму быў прывязаны да былога партнёра праз паспешна кланаваныя ІТ-сістэмы Lloyds. А горш за ўсё было тое, што банку даводзілася плаціць "аліменты" - адлічэнні ў выглядзе штогадовых ліцэнзійных збораў у памеры $ 127 млн.
Плаціць грошы сваім былым мала хто кахае, таму 22 красавіка 2018 года ў 18:00 TSB прыступіла да завяршальнага этапу расцягнутага на 18 месяцаў плана, які павінен быў усё змяніць. Планавалася перанесці мільярды запісаў кліентаў у ІТ-сістэму іспанскай кампаніі Banco Sabadell, якая набыла TSB за $2,2 млрд яшчэ ў 2015 годзе.
Кіраўнік Banco Sabadell Жазэ Олю распавёў аб маючай адбыцца падзеі за 2 тыдні да Калядаў 2017 года падчас святочнага сходу супрацоўнікаў у прэстыжнай канферэнц-зале ў Барселоне. Найважнейшым інструментам міграцыі павінна была стаць новая версія распрацаванай Banco Sabadell сістэмы: Proteo. Яе нават перайменавалі ў Proteo4UK спецыяльна для праекта міграцыі TSB.
На прэзентацыі Proteo4UK выканаўчы дырэктар Banco Sabadell Хайме Гвардыёла Рамахара пахваліўся, што новая сістэма - гэта не мае аналагаў у Еўропе маштабны праект, над якім працавала звыш 1000 спецыялістаў. І што яго рэалізацыя дасць істотны імпульс росту Banco Sabadell у Вялікабрытаніі.
Днём міграцыі прызначылі 22 красавіка 2018 года. Гэта быў ціхі нядзельны вечар у сярэдзіне вясны. ІТ-сістэмы банка былі адключаныя, бо выконваўся перанос запісаў з адной сістэмы ў іншую. Пры аднаўленні публічнага доступу да банкаўскіх рахункаў позна ўвечары ў нядзелю можна было чакаць, што банк павольна і плыўна вернецца ў строй.
Але пакуль Олю і Гвардыёла Рамахара радасна вяшчалі са сцэны аб рэалізацыі праекта Proteo4UK, супрацоўнікі, якія адказвалі за працэс міграцыі, моцна нерваваліся. Праект, на які адводзілася 18 месяцаў, сур'ёзна адставаў ад графіка і перавысіў бюджэт. Праводзіць дадатковыя тэсты не было калі. А бо перанос усіх дадзеных кампаніі (а гэта, нагадаем, мільярды запісаў) у іншую сістэму - гэта тытанічная праца.
Аказалася, інжынеры нерваваліся не дарма.
Заглушка на сайце, якую кліенты бачылі залішне доўга
Праз 20 хвілін пасля таго, як TSB адкрыў доступ да ўліковых запісак, быўшы цалкам упэўненым у тым, што міграцыя прайшла гладка, прыйшлі першыя паведамленні аб праблемах.
Назапашванні людзей раптоўна зніклі з рахункаў. Пакупкі на нязначныя сумы памылкова рэгістраваліся як шматтысячныя выдаткі. Некаторыя людзі аўтарызоўваліся ў сваіх асабістых кабінетах і бачылі не свае банкаўскія рахункі, а рахункі зусім іншых людзей.
У 21:00 прадстаўнікі TSB паведамілі мясцоваму фінансаваму рэгулятару (Упраўленне па фінансаваму рэгуляванні і наглядзе Вялікабрытаніі, FCA), што ў банка праблемы. Але FCA ужо звярнула на гэтую ўвагу: TSB сапраўды моцна аблажаўся, а кліенты апынуліся ў дурнях. І, зразумела, сталі скардзіцца ў (а ў наш час чаркнуць пару радкоў у твітары або фэйсбуку не складае адмысловай працы). У 23:30 з FCA звязаўся іншы фінансавы рэгулятар, Prudential Regulation Authority (PRA), які таксама адчуў нешта нядобрае.
Ужо глыбока апоўначы ім удалося датэлефанавацца да аднаго з прадстаўнікоў банка. І задаць ім адзінае пытанне: "што, чорт вазьмі, адбываецца?".
Для разумення маштабаў трагедыі спатрэбіўся час, але цяпер мы ведаем, што падчас міграцыі было пашкоджана 1,3 запісаў 5,4 кліентаў. Як мінімум тыдзень кліенты не маглі кіраваць сваімі грашыма з кампутара і мабільных прылад. У іх не атрымлівалася заплаціць па крэдыце, і многія кліенты банка атрымалі пляму ў крэдытную гісторыю, а таксама штрафы за пратэрміноўку.
Вось так выглядаў анлайн-банк кліентаў TSB
Калі пачалі з'яўляцца збоі, амаль адразу пасля гэтага, прадстаўнікі банка запэўнівалі, што праблемы былі "перыядычнымі". Праз тры дні і ўвогуле была выпушчана заява, што ўсе сістэмы ў норме. Але кліенты працягвалі паведамляць аб праблемах. Толькі 26 красавіка 2018 года генеральны дырэктар банка Пол Пестэр прызнаў, што TSB «стаіць на каленях», паколькі ў ІТ-інфраструктуры банка па-ранейшаму захоўвалася «праблема з прапускной здольнасцю», якая не дазваляе доступу да паслуг анлайн-банкінгу каля мільёна кліентаў.
Праз два тыдні пасля пачатку міграцыі ўсё яшчэ паведамлялася аб збоях у дадатку для анлайн-банкінгу, якое выдавала ўнутраныя памылкі, звязаныя з базай дадзеных SQL.
Цяжкасці з плацяжамі, асабліва з бізнес-рахункамі і іпатэчнымі рахункамі, працягваліся да чатырох тыдняў. А усюдыісныя журналісты высветлілі, што TSB адхіліў прапанову аб дапамозе ад Lloyds Banking Group у самым пачатку міграцыйнага крызісу. У цэлым жа, праблемы, звязаныя з уваходам у анлайн-сэрвісы і магчымасцю пераводу грошай, назіраліся аж да 3 верасня.
Трохі гісторыі
Першы банкамат быў адкрыты 27 чэрвеня 1967 года каля Barclays у Enfield.
Банкаўскія ІТ-сістэмы становяцца ўсё больш складанымі, бо запатрабаванні кліентаў і іх чаканні ад банка растуць. Гадоў 40-60 таму мы былі б рады наведаць мясцовае аддзяленне банка ў працоўны час, каб унесці наяўныя грошы ці вывесці іх праз касу.
Колькасць грошай на рахунку напрамую была звязана з наяўнымі грашыма і манетамі, якія мы перадалі банку. Нашу хатнюю бухгалтэрыю можна было адсочваць з дапамогай ручкі і паперы, а камп'ютарныя сістэмы былі недаступныя для кліентаў. Супрацоўнікі банка змяшчалі дадзеныя са ашчадкніжак і іншых носьбітаў у прылады, якія і лічылі грошы.
Але ў 1967 годзе на поўначы Лондана ўпершыню банкамат, які знаходзіўся не на тэрыторыі банка. І гэтая падзея змяніла банкаўскую дзейнасць. Выгода карыстальніка стала арыенцірам для развіцця фінансавых арганізацый. І гэта дапамагло банкам стаць больш дасканалымі з пункту гледжання працы з кліентамі і іх грашыма. Бо пакуль кампутарныя сістэмы былі даступныя толькі банкаўскім службоўцам, іх уладкоўваў ранейшы, "папяровы" спосаб узаемадзеяння з кліентам. І толькі калі з'явіліся банкаматы, а затым і анлайн-банкінг, шырокая публіка атрымала прамы доступ да ІТ-сістэм банка.
Банкаматы былі толькі пачаткам. Неўзабаве людзі змаглі пазбегнуць чаргі ў касу, проста патэлефанаваўшы ў банк па тэлефоне. Для гэтага патрабаваліся адмысловыя карты, устаўленыя ў счытвальную прыладу, здольнае расшыфроўваць двухтанальныя шматчастотныя (DTMF) сігналы, якія перадаюцца пры націскам карыстачом клавішы «1» (зняць грошы) або «2» (унесці сродкі).
Інтэрнэт і мабільны банкінг наблізілі кліентаў да асноўных сістэм, якія забяспечваюць працу банкаў. Нягледзячы на розныя абмежаванні і настройкі, усе гэтыя сістэмы павінны эфектыўна ўзаемадзейнічаць адна з адной і з асноўным мэйнфрэймам, выконваючы праверку балансу рахунку, ажыццяўляючы грашовыя пераводы і гэтак далей.
Нешматлікія кліенты задумваюцца аб тым, наколькі складаны шлях праходзіць інфармацыя, калі вы, да прыкладу, заходзіце ў анлайн-банк, каб паглядзець ці абнавіць інфармацыю аб грошах на рахунку. Пры ўваходзе ў сістэму гэтыя дадзеныя перадаюцца праз набор сервераў, калі вы здзяйсняеце транзакцыю, сістэма дублюе гэтыя дадзеныя ў бэкэнд-інфраструктуры, якая затым выконвае цяжкую працу - пераводзіць грошы з аднаго рахунку на іншы для аплаты рахункаў, ажыццяўлення плацяжоў і працягу падпісак.
Цяпер памножце гэты працэс на некалькі мільярдаў. Паводле дадзеных, сабраных Сусветным банкам з дапамогай Фонду Біла і Мелінды Гейтс, дарослых ва ўсім свеце маюць банкаўскі рахунак. Кожны з гэтых людзей павінен аплочваць рахункі. Хтосьці плаціць іпатэку або пераводзіць грошы за дзіцячыя гурткі, хтосьці аплачвае падпіску на Netflix або арэнду хмарнага сервера. І ўсе гэтыя людзі карыстаюцца не адным банкам.
Шматлікія ўнутраныя ІТ-сістэмы аднаго банка (мабільны банкінг, банкаматы і інш.) павінны не проста ўзаемадзейнічаць сябар з сябрам. Ім трэба ўзаемадзейнічаць і з іншымі банкаўскімі сістэмамі ў Бразіліі, Кітаі, Германіі. Французскі банкамат павінен мець магчымасць выдаваць грошы, якія ёсць на банкаўскай карце, выпушчанай дзе-небудзь у Балівіі.
Грошы заўсёды былі глабальныя, але яшчэ ніколі гэтая сістэма не была такой складанай. Колькасць спосабаў скарыстацца ІТ-сістэмамі банка павялічваецца, але старыя спосабы па-ранейшаму ў хаду. Поспех банка шмат у чым залежыць ад таго, наколькі «рамонтапрыдатная» яго ІТ-інфраструктура, і наколькі эфектыўна банк можа справіцца з раптоўным збоем, з-за якога сістэма будзе прастойваць.
Няма тэстаў - рыхтуйся да праблем
Генеральны дырэктар Banco de Sabadell Хайме Гвардыёла (злева) быў упэўнены, што ўсё пройдзе гладка. Не атрымалася.
Кампутарныя сістэмы TSB былі не занадта вось добрыя з пункта гледжання хуткага рашэння праблем. Былі, вядома, і праграмныя збоі, але ў рэчаіснасці банк "зламаўся" з-за празмернай складанасці ІТ-сістэм. Паводле справаздачы, падрыхтаванай у першыя дні маштабнага збою, «спалучэнне новых прыкладанняў, пашыранага выкарыстання мікрасэрвісаў у спалучэнні з выкарыстаннем двух актыўных (Active/Active) цэнтраў апрацоўкі дадзеных прывяло да складанай рызыкі на вытворчасці».
Некаторыя банкі, напрыклад HSBC, працуюць глабальна, а таму таксама маюць вельмі складаныя, узаемазвязаныя сістэмы. Але яны, па словах аднаго з ІТ-кіраўнікоў HSBC ў Ланкастэра, рэгулярна тэстуюцца, пераносяцца і абнаўляюцца. Ён разглядае HSBC як мадэль таго, як іншыя банкі павінны кіраваць сваімі ІТ-сістэмамі: вылучаючы персанал і марнуючы свой час. Але пры гэтым прызнае, што для менш буйнога банка, асабліва які не мае вопыту міграцыі, зрабіць гэта правільна - вельмі складаная задача.
Міграцыя TSB была складанай. І, на думку спецыялістаў, персанал банка мог банальна не дацягваць да гэтага ўзроўню складанасці з пункту гледжання кваліфікацыі. Акрамя таго, яны нават не паклапаціліся аб тым, каб праверыць сваё рашэнне, пратэставаць міграцыю загадзя.
Падчас выступу ў брытанскім парламенце, прысвечанаму банкаўскім праблемам, Эндру Бейлі, выканаўчы дырэктар FCA, пацвердзіў гэтае падазрэнне. Дрэнны код, верагодна, выклікаў першапачатковыя праблемы толькі ў TSB, але ўзаемазвязаныя сістэмы глабальнай фінансавай сеткі азначалі, што яго памылкі былі ўвекавечаны і незваротныя. Банк працягваў бачыць нечаканыя памылкі ў іншых месцах сваёй ІТ-архітэктуры. Кліенты атрымлівалі паведамленні, якія былі бессэнсоўнымі ці не звязанымі з іх праблемамі.
Рэгрэсійнае тэсціраванне магло б дапамагчы прадухіліць катастрофу, выявіўшы дрэнны код да таго, як яго запусцілі б у працоўным асяроддзі, і ён нанёс шкоду, ствараючы памылкі, якія нельга было адкаціць. Але банк вырашыў прабегчыся па мінным полі, аб якім нават не ведаў. Наступствы былі прадказальныя. Яшчэ адной праблемай стала "аптымізацыя" выдаткаў. У чым яна выявілася? У тым, што раней было вырашана скончыць з рэзервовымі копіямі, якія захоўваліся ў Lloyds, бо яны з'ядалі занадта шмат грошай.
Брытанскія банкі (ды і іншыя таксама) імкнуцца да дасягнення ўзроўню даступнасці "чатыры дзявяткі", гэта значыць 99,99, 52%. На практыцы гэта азначае, што ІТ-сістэма павінна быць даступная стала, а час прастою складае да 99,9 хвілін у год. Сістэма "трох дзявятак", 8%, на першы погляд адрозніваецца не моцна. Але на справе азначае, што час прастою дасягае XNUMX гадзін за год. Для банка «чатыры дзявяткі» - гэта добра, а «тры дзявяткі» - не.
Але кожны раз, калі кампанія ўносіць змены ў сваю ІТ-інфраструктуру, яна рызыкуе. Бо нешта можа пайсці не так. Памяншэнне змен можа дапамагчы пазбегнуць праблем, у той час як патрабаваныя змены маюць патрэбу ў дбайным тэсціраванні. І на гэтым моманце засяродзілі ўвагу брытанскія рэгулятары.
Магчыма, самы просты спосаб пазбегнуць прастояў - проста ўнесці менш змен. Але кожны банк, як і любая іншая кампанія, вымушана ўкараняць усё больш карысных магчымасцей для кліентаў і ўласнага бізнесу, каб захоўваць канкурэнтаздольнасць. Пры гэтым банкі па-ранейшаму абавязаны клапаціцца аб сваіх кліентах, абараняючы іх зберажэнні і персанальныя дадзеныя, забяспечваючы камфортныя ўмовы карыстання сэрвісамі. Атрымліваецца, што арганізацыі змушаныя марнаваць кучу часу і грошай на падтрыманне працаздольнасці ІТ-інфраструктуры, адначасова прапануючы новыя паслугі.
Паводле дадзеных, якія апублікавала Упраўленне па фінансаваму рэгуляванню і наглядзе Вялікабрытаніі, колькасць зарэгістраваных тэхналагічных збояў у сектары фінансавых паслуг у Вялікабрытаніі вырасла на 187 працэнтаў за перыяд з 2017 па 2018 гады. Часцей за ўсё прычынай збояў з'яўляецца праблемы ў рабоце новага функцыяналу. Пры гэтым банкам крытычна важна забяспечыць пастаянную бесперабойную работу ўсіх сэрвісаў і амаль імгненную справаздачнасць па транзакцыях. Кліенты заўсёды нервуюцца, калі іх грошы боўтаюцца невядома дзе. А які нервуецца з-за грошай кліент - гэта заўсёды да бяды, дакладная прымета.
Праз некалькі месяцаў пасля збою ў TSB (да гэтага часу сышоў у адстаўку генеральны дырэктар банка) фінансавыя рэгулятары Вялікабрытаніі і Банк Англіі для абмеркавання па пытаннях аперацыйнай устойлівасці. Так яны спрабавалі ўзняць пытанне аб тым, наколькі глыбока зайшлі банкі ў пагоні за новаўвядзеннямі, і ці могуць яны гарантаваць стабільную працу той сістэмы, якая ёсць зараз.
У дакуменце таксама прапаноўвалася ўнесці змену ў заканадаўства. Гаворка ішла аб ускладанні на супрацоўнікаў унутры кампаніі адказнасці за тое, што ідзе не так у ІТ-сістэмах гэтай кампаніі. Брытанскія парламентарыі растлумачылі гэта так: "Калі вы нясеце асабістую адказнасць, і вас могуць збанкрутаваць або адправіць у турму, гэта моцна зменіць стаўленне да працы, у тым ліку павялічыць колькасць часу, які надаецца пытанню надзейнасці і бяспекі".
Вынікі
Кожнае абнаўленне і выпраўленне зводзяцца да кіравання рызыкамі, асабліва калі гаворка ідзе пра сотні мільёнаў долараў. Бо калі нешта пойдзе не так, то гэта можа дорага абысціся з пункту гледжання грошай і рэпутацыі. Здавалася б, відавочныя рэчы. І правал банка падчас міграцыі павінен быў шмат чаму іх навучыць.
Павінен быў. Але не навучыў. У лістападзе 2019 года TSB, які зноў выйшаў на акупляльнасць і паволі выпраўляў сваю рэпутацыю, «узрадаваў» кліентаў у сферы інфармацыйных тэхналогій. Другі ўдар па банку прывёў да таго, што ён будзе вымушаны закрыць 82 філіялы ў 2020 годзе, каб скараціць свае выдаткі. А мог бы проста не эканоміць на ІТ-адмыслоўцах.
Скупасць у адносінах да ІТ у канчатковым выніку абкладаецца пошлінай. TSB паведаміў аб стратах у памеры $134 млн у 2018 годзе ў параўнанні з прыбыткам у памеры $206 млн у 2017 годзе. Выдаткі пасля міграцыі, уключаючы кампенсацыі кліентам, выпраўленне ашуканскіх транзакцый (а іх колькасць рэзка павялічылася падчас банкаўскага хаосу), і дапамога іншых спецыялістаў склала $419 млн даляраў. ІТ-правайдэру банка таксама быў выстаўлены рахунак на суму $194 млн даляраў за яго роля ў крызісе.
Зрэшты, нягледзячы на тое, якія ўрокі былі засвоены пасля збою ў слоіку TSB, перабоі ўсё роўна будуць мець месца. Яны непазбежныя. Але дзякуючы тэсціраванню і добраму коду колькасць збояў і час прастою можна значна паменшыць. Cloud4Y, часта які дапамагае буйным кампаніям міграваць у хмарную інфраструктуру, добра разумее важнасць хуткага пераезду з адной сістэмы ў іншую. Таму ў нас можна правесці нагрузачнае тэсціраванне, і выкарыстоўваць шматузроўневую сістэму рэзервовага капіявання, а таксама іншыя опцыі, якія дазваляюць праверыць усё магчымае перад пачаткам міграцыі.
Што яшчэ карыснага можна пачытаць у блогу
→
→
→
→
→
Падпісвайцеся на наш -канал, каб не прапусціць чарговы артыкул! Пішам не часцей за два разы на тыдзень і толькі па справе.
Крыніца: habr.com