Неудачная миграция ИТ-инфраструктуры привела к повреждению 1,3 млрд записей клиентов банка. Всему виной стало недостаточное тестирование и легкомысленное отношение к сложным ИТ-системам. Cloud4Y рассказывает, как это было.
В 2018 году английский банк TSB осознал, что его «развод» двухлетней давности с банковской группой 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» (внести средства).
Интернет и мобильный банкинг приблизили клиентов к основным системам, обеспечивающим работу банков. Несмотря на разные ограничения и настройки, все эти системы должны эффективно взаимодействовать друг с другом и с основным мэйнфреймом, выполняя проверку баланса счёта, осуществляя денежные переводы и так далее.
Немногие клиенты задумываются о том, насколько сложный путь проходит информация, когда вы, к примеру, заходите в онлайн-банк, чтобы посмотреть или обновить информацию о деньгах на счёте. При входе в систему эти данные передаются через набор серверов, когда вы совершаете транзакцию, система дублирует эти данные в бэкэнд-инфраструктуре, которая затем выполняет тяжелую работу— переводит деньги с одного счёта на другой для оплаты счетов, осуществления платежей и продолжения подписок.
Теперь умножьте этот процесс на несколько миллиардов. Согласно данным, собранным Всемирным банком с помощью Фонда Билла и Мелинды Гейтс, 69 процентов взрослых во всём мире имеют банковский счет. Каждый из этих людей должен оплачивать счета. Кто-то платит ипотеку или переводит деньги за детские кружки, кто-то оплачивает подписку на 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, часто помогающий крупным компаниям мигрировать в облачную инфраструктуру, хорошо понимает важность быстрого переезда из одной системы в другую. Поэтому у нас можно провести нагрузочное тестирование, и использовать многоуровневую систему резервного копирования, а также другие опции, позволяющие проверить всё возможное перед началом миграции.
Что ещё полезного можно почитать в блоге Cloud4Y
→ Солёная солнечная энергия
→ Пентестеры на передовой кибербезопасности
→ Великая теория снежинок
→ Интернет на воздушных шарах
→ Нужны ли в ЦОД подушки?
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью! Пишем не чаще двух раз в неделю и только по делу.
