Невдала міграція ІТ-інфраструктури призвела до пошкодження 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 годин на рік. Для банку «чотири дев'ятки» — це добре, а «три дев'ятки» — ні.
Але щоразу, коли компанія вносить зміни до своєї ІТ-інфраструктури, вона ризикує. Бо щось може піти не так. Зменшення змін може допомогти уникнути проблем, у той час як необхідні зміни потребують ретельного тестування. І на цьому моменті привернули увагу британські регулятори.
Можливо, найпростіший спосіб уникнути простоїв просто внести менше змін. Але кожен банк, як і будь-яка інша компанія, змушена впроваджувати все більше корисних можливостей для клієнтів та власного бізнесу, щоби зберігати конкурентоспроможність. При цьому банки, як і раніше, зобов'язані піклуватися про своїх клієнтів, захищаючи їх заощадження та персональні дані, забезпечуючи комфортні умови користування сервісами. Виходить, що організації змушені витрачати купу часу та грошей на підтримку працездатності ІТ-інфраструктури, водночас пропонуючи нові послуги.
Згідно з даними, які опублікувало Управління з фінансового регулювання та нагляду Великобританії, кількість зареєстрованих технологічних збоїв у секторі фінансових послуг у Великобританії зросла на 187 відсотків за період із 2017 по 2018 роки. Найчастіше причиною збоїв є проблеми у роботі нового функціоналу. При цьому банкам критично важливо забезпечити постійну безперебійну роботу всіх сервісів та майже миттєву звітність щодо транзакцій. Клієнти завжди нервують, коли їхні гроші бовтаються невідомо де. А клієнт, що нервує через гроші, — це завжди до біди, вірна прикмета.
Через кілька місяців після збою в TSB (на той час пішов у відставку генеральний директор банку) фінансові регулятори Великобританії та Банк Англії для обговорення з питань операційної стійкості. Так вони намагалися порушити питання про те, наскільки глибоко зайшли банки в гонитві за нововведеннями, і чи можуть вони гарантувати стабільну роботу системи, яка є зараз.
У документі також пропонувалося внести зміни до законодавства. Йшлося про покладання на співробітників усередині компанії відповідальності за те, що йде не так у ІТ-системах цієї компанії. Британські парламентарі пояснили це так: «Коли ви несете особисту відповідальність, і вас можуть збанкрутувати або відправити у в'язницю, це сильно змінить ставлення до роботи, у тому числі збільшить кількість часу, що приділяється надійності та безпеці».
Підсумки
Кожне оновлення та виправлення зводяться до управління ризиками, особливо коли йдеться про сотні мільйонів доларів. Адже якщо щось піде не так, це може дорого обійтися з погляду грошей і репутації. Здавалося б, очевидні речі. І провал банку під час міграції мав багато чого їх навчити.
Повинен був. Але не навчив. У листопаді 2019 року TSB, який знову вийшов на окупність і потихеньку виправляв свою репутацію, «втішив» клієнтів у сфері інформаційних технологій. Другий удар по банку призвів до того, що він буде змушений закрити 82 філії у 2020 році, щоб скоротити свої витрати. А міг би просто не економити на ІТ-фахівцях.
Скупість по відношенню до ІТ зрештою оподатковується митом. TSB повідомив про збитки у розмірі $134 млн у 2018 році порівняно з прибутком у розмірі $206 млн у 2017 році. Витрати після міграції, включаючи компенсації клієнтам, виправлення шахрайських транзакцій (а їх кількість різко збільшилася під час банківського хаосу), і допомога сторонніх фахівців становила $419 млн. доларів. ІТ-провайдеру банку також було виставлено рахунок на суму $194 млн. доларів за його роль у кризі.
Втім, незважаючи на те, які уроки було засвоєно після збою в банку TSB, перебої все одно матимуть місце. Вони неминучі. Але завдяки тестуванню та гарному коду кількість збоїв та час простою можна значно зменшити. Cloud4Y, який часто допомагає великим компаніям мігрувати в хмарну інфраструктуру, добре розуміє важливість швидкого переїзду з однієї системи в іншу. Тому у нас можна провести навантажувальне тестування та використовувати багаторівневу систему резервного копіювання, а також інші опції, що дозволяють перевірити все можливе перед початком міграції.
Що ще корисного можна почитати у блозі
→
→
→
→
→
Підписуйтесь на наш -Канал, щоб не пропустити чергову статтю! Пишемо не частіше двох разів на тиждень і лише у справі.
Джерело: habr.com