Надежность ВТБ: как мы добились «четырёх девяток» доступности банковских систем
Привет! Меня зовут Иван Мартинович, я заместитель руководителя департамента поддержки прикладных систем и сервисов — вице-президент в ВТБ. В теперь уже далёком 2019 году мы запустили одну из ключевых программ цифровой трансформации банка, нацеленную на обеспечение надёжности целевых систем. О том, как мы проводили её в разгар пандемии коронавируса и что из этого всего вышло, мне бы и хотелось сегодня рассказать.
Итак, 2019-й, четвёртый квартал. В состав ВТБ входит ряд крупных банков, таких как Банк Москвы, ВТБ-24. В каждом присоединённом банке на протяжении долгих лет развивались собственные информационные системы. У каждого была своя философия, свой технологический стек, подход к ведению процессов, представления о том, как все сделать наилучшим образом в текущих условиях.
Все эти разрозненные благие намерения привели к тому, что три с половиной года назад в совокупности мы имели:
разномастные ландшафты со своими архитектурами, технологиями, стандартами;
устаревшие ЦОД«ы, не соответствующие требованиям надёжности;
устаревшие и разрозненные сети, как опорные в ЦОД«ах, так и региональные;
запутанную схему взаимодействия между ЦОД«ами;
коллективы, привыкшие к своим процессам, культурам, отношениям внутри компаний.
Всё это сказывалось на надёжности сервисов — доступность business- и mission-critical-систем банка составляла 96,74%. Наши клиенты могли наблюдать сбои и простои во время технических работ. Региональные офисы страдали от проблем из-за старого оборудования и сетей. Нам предстояло создать единый ландшафт — современный и надёжный. И быстро.
Задача обеспечения надёжности IT-ландшафта банка легла в название соответствующей программы. Её символом стали «четыре девятки» — 99,99% доступности банковских систем, — это то, к чему мы стремились. Для нас это означало, что в любой системе допустимы простои не более 52 минут в год, невзирая на аварии или технические работы.
Но легко сказать «давайте сделаем, чтобы не было простоев». На тот момент мы не могли соответствовать таким требованиям — у нас не было на руках всех инструментов, технологий, процессов. Решать проблемы приходилось буквально по всем фронтам. Для простоты мы разделили задачи на три больших кластера.
Кластер первый. Инфраструктура
Нам предстояло разобраться с ЦОД«ами. После объединения банков у ВТБ оказалось аж девять ЦОД«ов. Увы, они никуда не годились — два можно было назвать приличными, семь — изрядно устарели. И все девять не соответствовали нашим требованиям надёжности и безопасности. Тут был только один выход: делать заново и сразу так, как надо. Сказано — сделано! В итоге мы:
построили 2 целевых основных ЦОД«а по новым стандартам;
закупили туда современное оборудование вместо устаревшего;
построили новую опорную сеть внутри ЦОД«ов и между ними;
провели миграцию систем, причём с проверкой на соответствие новым паттернам надёжности и перестройкой резервирования и последующей доработкой при несоответствии.
В результате у нас появились ЦОД«ы, которые по параметрам доступности и непрерывности поставляемых сервисов соответствовали уровню Tier 3.
Один из наших новых ЦОДов
И вот еще немного ЦОДов
Параллельно начали заниматься платформой VDI, которая обеспечивала бы сотрудников виртуальными рабочими местами. У нас также сложился разрозненный ландшафт решений VDI, плюс ранее мы использовали VDI Horizon, но признали его недостаточно безопасным и решили заменить на собственную целевую платформу VDI. Как раз в то время в Россию пришёл Covid-19, люди массово переходили на удалённую работу — и возможности новой платформы оказались очень кстати. Только в начале пандемии она позволила нам создать 30 тысяч рабочих мест для удалёнщиков.
Наша региональная сеть, связывающая ЦОД с региональными офисами и точками продаж, тоже была устаревшей и разрозненной. Мы полностью заменили сетевое оборудование на новое, соответствующее нашим паттернами надёжности. Создали централизованные почтовые сервисы, разобрались с доставшимися нам от банков системами управления учётными записями пользователей сети — Active Directory, для их объединения мы реализовали новый проект.
Кроме того, мы полностью пересмотрели подход к организации инфраструктуры регионов. Переход на новую целевую сеть позволил отказаться от размещения в региональных офисах собственных инфраструктурных сервисов и перенести их все в целевые ЦОД ГО. Что значительно повысило их надёжность и сократило затраты на сопровождение.
Наш ЦОД снаружи
В инфраструктурном кластере была также значимая проблема, связанная с облачными решениями. На тот момент у нас уже были и облака, и средства виртуализации, но вендорские и устаревшие. Нам нужно было новое облако, причём покрывающее всю созданную инфраструктуру. Как и в случае с ЦОД«ами, мы взялись за разработку облака сами — хоть и не без помощи опенсорсных решений. Для управления разработали движок, облачный оркестратор, интерфейс. А для отслеживания параметров — построили системы биллинга и анализа отчётности по облаку.
С облаком у нас появились новые возможности на разных уровнях. На уровне IaaS мы смогли управлять виртуализацией серверов уже не с помощью сторонних решений вроде VMware, как делали это раньше, а опираясь на собственные решения. А на уровне PaaS — поднимать не просто виртуальные серверы, а серверы с интеграционными компонентами, развёрнутой базой данных, Kafka и так далее. При этом команды разработки теперь могли сами создавать инструменты и получать вычислительные мощности — просто и без участия в этом процессе каких-либо сотрудников поддержки, для чего был разработан и внедрён портал самообслуживания.
Создание облака и инструментов на его уровнях дало буст развитию других, смежных программ. Например, благодаря им существенно сократилась метрика time-to-market. Мы также могли теперь управлять нашими мощностями в виде ресурсов. Например, выделять командам разработки квоты на мощности, в рамках которых эти команды могут брать и использовать оборудование, возвращать его. И в целом новое облако позволило нам правильно утилизировать оборудование, чтобы оно не простаивало.
Кластер второй. Архитектура
Здесь мы начали работу с анализа. Собрали чек-лист требований надёжности и необходимых для их реализации элементов. Проверили по нему все наши критичные системы и выявили бэклог задач по каждой из них — своего рода техдолг. И уже по этим задачам запустили решающие их проекты.
Одна из ключевых задач этого кластера — резервирование. На старте программы во многих системах не было правильно реализованного резервирования. Резервирование должно было обеспечить нам не только защиту от сбоев и аварий на оборудовании, но и возможность проведения технических работ без остановки систем. Чтобы пользователи получали сервис 24/7 и больше не видели рассылок вроде «Уважаемый клиент, в ночь с такого-то по такое-то число будут проводиться технические работы, извините за неудобства».
Мы обратились к Stand-In — инструменту резервирования, создающему копию системы, на которую можно перейти в момент простоя основной системы. Причём мы пошли дальше и не стали делать репликацию только на аппаратном или платформенном уровне, как это обычно принято, а дополнительно реализовали её ещё и на прикладном уровне. То есть система в нашем случае реплицирует данные на защищённую дополнительную резервную часть.
Это работает так: когда нам нужно провести какие-то работы в рамках технологического окна, мы переводим систему в Stand-In. Клиенты не замечают этого и получают свой сервис, как обычно. Так же незаметно система переключается обратно. И такими Stand-In мы покрыли все наши критичные системы. В первую очередь — работающие онлайн высоконагруженные и критически важные системы: АБС, процессинг, системы противодействия мошенничеству, системы фронтального обслуживания — клиентские приложения и их веб-версии.
Кластер третий. Организация и процессы
Здесь нам пришлось решать проблемы наследия процессов, команд и корпоративных культур.
Одной из важных задач стала выработка понятной всем методологии и набора процессов. В ВТБ и до слияния были внедрены основные процессы, но цифровая трансформация заставила нас серьёзно пересмотреть их. Мы переосмыслили процессы управления инцидентами, авариями, проблемами, управление мощностями, мониторингом и другие. Но мало было просто разработать методологию — нам нужно было ещё донести её до сотрудников, обучить их. Также требовалось создать единые инструменты, где процессы будут автоматизированы. Для управления ими мы построили единую платформу.
Для того чтобы процессы заработали, нужны были данные — с ними мы могли бы понимать всю картину. У нас были разные средства мониторинга, но ни одно не позволяло консолидировать все данные и показывать весь ландшафт в целом. И опять нам пришлось создавать всё заново самим — на сей раз уже единую систему мониторинга. Мониторинг покрыл 100% наших систем и инфраструктуры под ними, и с его помощью мы наконец смогли в режиме реального времени наблюдать весь ландшафт, получать информацию о текущем состоянии сетей, железа, баз данных, взаимодействиях систем, бизнес-метриках. Мониторинг стал важным инструментом для сотрудников поддержки и ситуационного центра.
К слову, единый ситуационный центр тоже появился у нас в ходе реализации программы «Надёжность». Мы их построили даже два — в Москве и Самаре, чтобы в случае форс-мажоров в одном второй продолжил бы работать. И не только обеспечили их помещениями и оборудованием, но и инструментами реализации процессов.
Работа в ситуационном центре кипит
Наконец, мы создали для сотрудников ВТБ мобильное приложение, чтобы они оперативно получали информацию об авариях, работе бизнес-сервисов, могли видеть бизнес-метрики и реагировать в случае каких-то проблем.
Итоги
Мы завершили программу «Надёжность», и этот этап цифровой трансформации во втором квартале 2022 года. Уже можно подвести итоги и посмотреть, стоили ли эти изменения усилий и достигли ли мы своих целей. А лучше всего о результатах скажут цифры.
Инфраструктура
ЦОД«ы: вместо 9 устаревших и ненадёжных создали 2 новых ЦОД«а уровня Tier 3.
Оборудование: вывели из эксплуатации более 4000 единиц устаревшей техники.
Единая региональная сеть вобрала в себя 1400 точек продаж по стране:
создано более 30 000 виртуальных рабочих мест в целевых ЦОД«ах;
около 15 000 пользователей объединены на целевых доменах AD;
создана своими силами единая облачная платформа.
Архитектура
Техдолг: устранён на 100%. Да, все те бэклоги, всё наследие присоединённых банков, из которого мы его сформировали в начале программы, были выполнены.
Резервирование: реализовано 11 Stand-In в различных МС-системах, в их числе — процессинг, противодействие мошенничеству, фронтенд и т. д.
Интеграционные платформы присоединённых банков объединили в одну.
В кластере организации и процессов: 100% систем подключены к единой системе мониторинга и находятся под наблюдением ситуационных центров:
среднее время решения инцидентов снизилось на 72%;
среднее время реакции на инцидент сократилось в 5 раз;
аварий стало меньше в 2,4 раза;
общая длительность аварий сократилась в 16 раз;
в 20 раз сократилось время выявления критичных аварий;
в 13 раз снизилось время регистрации таких аварий;
в 3 раза быстрее стали устранять критичные аварии.
Экономический эффект программы «Надёжность» к её закрытию составил 17,9 млрд рублей. Мы прогнозируем, что через десять лет он вырастет до 80 млрд.
На этом цифровая трансформация ВТБ не закончилась, — это был лишь первый большой её этап. В начале 2023 года мы запустили новую программу — «Непрерывность». Теперь, когда мы устранили техдолг и достигли тех 99,99% надёжности, за которые боролись, сфокусируемся на повышении уровня доступности сервисов для клиентов, займёмся проблемами хранения информации архивных данных, продолжим улучшать наши ЦОД«ы и развивать облачные продукты VTB.Cloud. И в целом будем стремиться к технологическому суверенитету ВТБ. Программа продлится до конца 2025 года, и мы подробно расскажем и о ней.
Надеюсь, было интересно и познавательно. Буду рад ответить на вопросы о наших технических решениях.
