Привет, Хабр! Меня зовут Александр, я архитектор платформы в ОТП Банке. В этой статье расскажу, как мы с командой переходили с коробочного решения дистанционного банковского обслуживания и сделали это за рекордные 6 месяцев: с чего начинали, какие результаты получили и как управляли процессами. В рамках этой статьи мы сделаем акцент на архитектурных подходах, а после уже расскажем про выстаивание процесса и инфраструктуру.
Необходимость перехода связана, в первую очередь, с трудностью и дороговизной доработок под бесконечно меняющиеся потребности бизнеса. С изменением экономического ландшафта ОТП банк – один из немногих все еще доступен для перевода валюты за рубеж. В связи с этим у нас кратно выросла клиентская база, а за ним потянулась невозможность использования ДБО в полуручном режиме (коробка) с интеграциями на dblink. Бизнесу потребовался современный и отказоустойчивый интернет-банк, который также позволял бы быстро дорабатываться под активно изменяющиеся требования бизнеса.
((The shit hits the fan)) и для команды с учетом найма был выставлен амбициозный срок дедлайна – 6 месяцев до МВП. Сказать, что задача была амбициозной – ничего не сказать.
6 месяцев – это срок, за который обычно только разрабатывают техническое задание, а не создают и запускают полноценный продукт.
Цели бизнеса и первые шаги
Итак, зачем нам вообще все это было нужно?
Бизнесу требовался современный интернет-банк, который мог бы:
— Быстро дорабатываться под новые требования;
— Обеспечивать высокую доступность;
— Поддерживать масштабирование;
— Соответствовать высоким стандартам безопасности.
Да, мы смогли добиться выхода продукта в ПРОМ за короткий срок. В таких сроках главное – выделить правильный функционал и правильные интеграции.
Изначальные требования бизнеса были объемны и предполагали около 10 внешних интеграций, однако после обсуждения и анализа day 0 содержал лишь 1 основную интеграцию с АБС на уже существующих синхронных протоколах и 2 с базовыми системами нотификации клиента/ сотрудника. В таком виде был быстро реализован «костяк», который на текущий момент уже оброс асинхронными и событийными моделями интеграций с основными банковскими системами (8 систем).
Главное и самое трудное в любом крупном учреждении, на мой взгляд, именно пробить первую дорогу, потому как проблемы везде идентичны – длительные бюрократические согласования, критичные зависимости от систем, которые работают по водопаду и дорабатываются редко, проблемы с выделением инфраструктуры и стендов, проблемы с CI-CD.
Именно поэтому первый функционал в прод должен быть как можно меньше, так как после решения базовых проблем, по уже построенным рельсам мы можем очень быстро наращивать «мясо» на продукт и получить качественный и правильный результат. По своему опыту знаю, что крайне редко удается объяснить бизнесу, цели которого всегда отличны от целей IT, но нам в ОТП повезло и были крутые продакты, которые все понимали.
Целевая архитектура
Как бы ни были важны сроки, главное – в погоне за ними не получить Big Ball of mud. Для этого еще до начала активной разработки и аналитики был проработан и согласован основной концепт solution архитектуры, от которого был выделен day-0, day-1 и полный продукт.
Сильно упрощенный концепт архитектуры с используемыми технологиями выглядит так:
Подобная слоистая архитектура хорошо зарекомендовала себя в других проектах и организациях, поэтому решили использовать ее для разработки ДБО с нуля. Основной смысл подобного разделения микросервисов в разных требованиях к микросервисам и разным релизным циклам. Если для продуктов в первую очередь важна скорость доставки новых фичей для клиента, то для сервисов платформенного слоя в первую очередь важна доступность данных, а доработка новой функциональности должна проходить дополнительные этапы проверки, так как в подобной архитектуре падение продуктового сервиса, депозитов, например, никак не затронет остальные сервисы и клиент лишится только доли функциональности, тогда как при падении платформенного сервиса может упасть большое количество связанных продуктовых сервисов. Подобная архитектура хорошо будет работать только с соблюдением закона Конвея, поэтому сейчас мы развиваем команды в сторону сильной платформенной команды и небольших продуктовых команд.
Бонусом подобной архитектуры выступают разные требования информационной безопасности к слоям, так как мы предоставляем доступ из интернета только к части микросервисов, а сервисы, которые будут работать с чувствительными данными будут скрыты интеграционным слоем, который, как и все наши интеграции, щедро закутан в mTLS.
Сейчас ближе к массовой миграции и уже полноценному продукту мы выглядим очень близко к этому, но все еще предстоит долгий путь.
Отказоустойчивость
Решение ДБО для клиентов должно быть доступно всегда, от этого зачастую зависит не только прибыль компании клиента, но и вопрос его существования. Понимая это, мы в своем решении пошли ва-банк и в целевой архитектуре предусмотрели практически все, с чем мы сталкивались за свою долгую карьеру в IT.
Независимость микросервисов от бэк-офисных систем
В частности, событийная модель интеграции с критичными бэк-офис системами. Мы реализуем горячий кэш (событийная модель интеграции на кафке) всех необходимых в синхронных взаимодействиях с клиентом данных. Фактически у нас вообще нет синхронных запросов куда-либо, когда мы отрисовываем клиенту страницу или, когда клиент отправляет заявку. Подобный подход позволяет нам не беспокоится о тех. окнах и недоступности бэк-офиса. В основном используется кафка и rabbit MQ, кое где еще остались IBM MQ, но, к сожалению, как и везде в стране, мы вынуждены от него уходить.
Геораспределенность
Наше решение развернуто на трех геораспределенных ЦОДах и сможет работать даже если один из ЦОДов отключится, клиент даже не заметит этого. При потере двух ЦОДов, к сожалению, наши распределенные системы перейдут в RO и клиент это заметит, но данные, тем не менее, мы не потеряем, а это в банковской сфере самое важное. Все наши сервисы разрабатывались stateless и поэтому не должно возникнуть серьезных проблем при комбинации ЦОДов master-master-slave, однако на первом этапе было принято решение работать по схеме master-slave, а третий ЦОД использовать для кворума распределенных систем (о них чуть позже). Также пока не решили проблему patrony кластера postgres при комбинации master-master, возможно, у вас есть опыт и вы подскажете в комментариях куда двигаться?
Распределенные системы
Как я уже упомянул, все сервисы, которые у нас развернуты в облачной инфраструктуре stateless, а значит не хранят персистетных данных. С учетом этого, в зависимости от структуры данных, мы развернули MinIO, ElasticSearch, Kafka, RabbitMQ. Архитектура развертки кластеров предусматривала работоспособность системы при полной потере одного из основных ЦОД. Решили не растягивать REDIS на ЦОДы, а сделать его неперсистентным кэшем на каждом облаке. В основном это связано с тем, что REDIS как быстрое хранилище теряет весь свой смысл, как только мы включаем сюда сетевые задержки. Если у вас есть успешные применения персистетнтного redis, мы были бы рады послушать.
Service Mesh на kubernetes (work in progress)
Наше решение развернуто в общебанковском облаке в кластерах Kubernetes, пока без сайдкаров, но тем не менее инфраструктура идет к этому и как только будет можно, мы сможем повысить свою доступность за счет применения автоскейла, blue-green и канареечных раскаток. Также это позволит нам изменить архитектуру развертки кластера, при котором у нас получится растянутый на несколько ЦОДов kubernetes кластер, причем еще и по разным зонам безопасности, включая PCI DSS, за счет mtls и разделения мастеров.
CI/CD
Сегодня невозможно себе представить динамично развивающуюся систему без отлаженного CI-CD, ведь именно он по большей части дает нам те самые заветные четыре девятки, поэтому с самого старта нашей разработки особое внимание было уделено автоматической раскатке и фактически мы, начиная с первого дистрибутива ничего не раскатывали вручную, а учитывая, что наша система уже состоит из 50+ микросервисов, а будет еще больше – это однозначно было правильным решением. CI/CD построен на базе TeamCity, мы не использовали ручную настройку через интерфейс, весь процесс был выстроен с помощью кода (TeamCity позволяет создавать темплейты с помощью Kotlin`a).
В итоге мы добились максимальной оптимизации добавления встраивания новых микросервисов в систему CI/CD (а в ходе такой ускоренной разработки среднее скорость создания нового МС-около недели), достаточно было добавить одну строчку в код пайплайна с наименованием репозитория из битбакета и на него автоматически подтягивались все нужные темплейты билда и деплоя. Нельзя не отметить, что деплой в продакшн среду осуществлялся сразу на два плеча, а также были добавлены все проверки безопасников –SAST – Static Application Security Testing, CS – container security, SCA – Software Composition Analysis, для контроля качества написанного кода.
Feature toggle
В ходе реализации объемные участки кода закрывались фича тоглами для удобства маневрирования функциональностью в продакшне, это позволяло нам гибко относится к релизам смежных систем, с которыми у нас уже были или еще планировались интеграции, а также давало возможность отключения некорректно отрабатывающих сценариев. Все создаваемые тогглы заносились в специализированный реестр и велся учет их актуальности.
Послесловие
Какими результатами мы готовы похвастаться:
— Новый интернет-банк, разработанный с нуля.
— Современная, отказоустойчивая платформа.
— Сокращение времени разработки на 50%.
— Увеличение скорости доработки функционала в 3 раза.
— Повышение удовлетворенности клиентов.
Создание современного и отказоустойчивого интернет-банка за такой короткий срок стало реальностью благодаря комплексному и слаженному подходу всех команд банка. Несмотря на ограничения и бюрократические препятствия в банковской сфере, наш опыт в разработке этого проекта подчеркнул важность эффективной коммуникации и сотрудничества между всеми участниками процесса. Это не просто история успеха, это история о том, что возможно все, если есть сильная команда, поддержка коллег, четкая цель, нестандартный подход и, конечно, вера в свои силы.
Мы не останавливаемся на достигнутом и продолжаем развивать наш ДБО, чтобы сделать его еще более удобным, функциональным и надежным.
ссылка на оригинал статьи https://habr.com/ru/articles/826558/
Добавить комментарий