На что похож ИТ-ландшафт обычного банка в России
Речь про обычный розничный банк, как вы понимаете
ИТ-ландшафт чаще всего повторяет оргструктуру и отражает исторические процессы. Например, мы запускали банк в 2002 году, когда вообще все банки в России, пожалуй, кроме Сбера, были ориентированы на юрлиц. Возможно, сейчас это будет уже немного тяжело вспоминать, но банковского пластика почти не было, было много кеша. Соответственно, архитектура банка тех лет была заточена под юрлиц, то есть большие разовые транзакции, которые можно обрабатывать чуть ли не руками.
Ядро любого банка — АБС. Это движок, который, например, ведёт главную книгу счетов банка, выполняет бухгалтерские операции и формирует бухгалтерскую отчётность. У нас эта АБС от компании Кворум. Учитывая давний год рождения, первичная задача АБС тогда была вести учёт и формировать отчётность, которую жёстко требовал ЦБ, и делать, собственно, расчёты. Без этих двух вещей банк работать не может. Чуть позже мы стали заниматься картами, а у Кворума тогда не было карточного модуля, поэтому мы завели ещё и вторую АБС TranzWare. Обычно в банковском ландшафте это выглядит так: либо поверх старого «движка» вешается более новый карточный модуль, либо же сразу «из коробки» используется АБС с картами.
В нашем случае мы интегрировали две АБС, поделив их по продуктам. Сама необходимость отдельной АБС для карт обуславливалась тем, что тогдашняя архитектура не была готова к большому количеству транзакций, по которым нужно было отвечать чуть ли не в реальном времени. Из железа у нас в этот период были x64-машины IBM, причём чуть позже с ростом нагрузки появилась одна, вообще индивидуально собранная под нас.
Интегрировались они тогда напрямую без всяких промежуточных шин и брокеров. Ну, знаете, вот это «мои файлы — твои файлы, мой дом — твой дом».
С тех пор кое-что поменялось, конечно.
Ядро банка
АБС для юрлиц, АБС для физлиц (или одна АБС со всей бухгалтерией, проводками и отчётами, что случается чаще) + два дата-центра (один боевой, один для горячего резерва) плюс операторы — это минимальный набор для работы банка. Второй ЦОД и вообще жёсткие требования по Disaster Recovery обусловлены ещё тем, что ЦБ требует очень высокий уровень доступности сервисов ядра. Упрощая, если у какого-то крупного банка не будет в конце банковского дня рассчитан клиринг, то это проблема. На второй день это уже катастрофа федерального масштаба для экономики практически независимо от страны, поэтому центробанки по всему миру предъявляют очень жёсткие требования к тому, насколько качественный должен быть код (точнее, как должны быть устроены процессы разработки и деплоя) и насколько быстро банк должен восстанавливаться после разных аварий.
Тем не менее только на АБС работать практически невозможно, потому что не будет же никто каждую проводку вбивать в консоль. Хотя и такой период в банкинге был, когда клиент звонил по телефону или приходил в офис, а операторы работали чуть ли не напрямую с базой. К счастью, в 2002 году всё было уже куда и куда лучше.
Второй уровень: продукты и шина
Сама АБС очень редко хранит продуктовую логику. Условно, АБС — это движок, который обеспечивает взаимодействие с законами физики. Только вместо физики у нас ЦБ и финансовая система. По сути, язык API АБС представляет собой некий ассемблер банковских операций: зачислить на такой-то счёт, снять с такого-то счёта и т.п. Часто туда входит какая-то минимальная логика для очень стандартных продуктов вроде депозитов, но всё, что сложнее, реализуется в системах выше уровнем.
Наша первичная система уровнем выше уже была самописная. Это Homer, который изначально разрабатывался в Чехии для всей Группы Хоум Кредит, но в какой-то момент мы здесь поняли, что банкинг и ИТ в России растут неимоверно быстро и пора забирать разработку к себе. В итоге мы забрали у штаб-квартиры весь исходный код, переделали всё под реалии РФ и получили собственный сервис, который дальше развивали. Поскольку исторически мы сразу начали заниматься потребительскими кредитами, Homer очень быстро оброс функционалом расчёта кредитных продуктов наличными, кредитных карт и так далее.
Для работы с картами нужен ещё один отдельный сервис с отдельной логикой. Карточный продукт сам по себе намного более технологичная вещь, чем кредитный продукт. Например, потому что система завязана на много устройств, разные платёжные системы, интеграцию с ними. И карта очень специфический инструмент (особенно для тех лет) — нужен реалтаймовый процессинг, быстрые операции и т.п. Вы только вставили карту в терминал —, а банк уже должен дать ответ, а не рассматривать заявление 10 минут. Запросы из POS-терминалов и банкоматов идут в карточный процессинг, который подтверждает возможность совершения операций. Соответственно, все свои карты и банкоматы мы обслуживаем сами — процессинговый центр от Compass Рlus, на платформе TranzWare.
Третий уровень: каналы взаимодействия
Ядро делает сами банковские операции, продуктовый слой отвечает за логику, но ко всему этому ещё нужны фронты. Основных фронтов у нас (как и у большинства других банков) два. Первый — софт для офлайн-обслуживания, по сути — рабочее место оператора отделения, которое также используется для контакт-центра. Второй — онлайн-банкинг, дистанционное обслуживание. Там поверх одной и той же логики взаимодействий лежит фронт в виде web-версии, iOS-приложения и Android-приложения. Вполне возможно, что к этим фронтам присоединится со временем и чат-бот, но пока он выступает, скорее, ассистентом оператора в контакт-центре.
Фронты — это, по сути, интерфейсы к продуктовым системам, соединяются они с ними через шину.
Естественно, в 2002 году про онлайн-банкинг никто не думал, а сейчас это фокусный продукт. Клиентам очень важно иметь приложение, банк в кармане. Причём это реальная точка конкуренции: если вдруг клиенты не могут разобраться или получить какую-то услугу, то очень быстро меняют банк.
Россия — одна из самых требовательных стран по юзабилити и уровню сервиса в приложениях. Тот уровень, который есть у нас, сильно выше привычного европейского. Причём у нас люди не медлят менять банк при неудобствах: сначала человек пробует приложение, если удовлетворяет базовую потребность — начинает разбираться дальше и дальше. Мы много сил тратим на то, чтобы наше приложение было максимально близко к текущим потребностям наших клиентов и отраслевым бенчмаркам, плюс сейчас я могу сказать, что в некоторых продуктах и сервисах мы лидируем на рынке.
Также фронтами можно назвать интеграции со внешними партнёрами: тем же торговым сетям, которые выдают кредиты на покупку товаров, также предоставляются рабочие места операторов для оформления заявок на кредит. Часто — в их собственных торговых приложениях, то есть каждая сеть или каждое приложение — это своя отдельная интеграция. Их фронты работают по API с продуктами второго слоя, формируя заявки и передавая ответы.
Ещё один относительно новый канал — это доставка. Раньше была одна модель, когда клиент приходил к нам за чем-то физическим, например, за деньгами, документами или картой. Сейчас всё чаще и чаще мы доставляем что-то клиентам домой или на работу. Для такого обслуживания у нас есть отдельная система. Выездной сотрудник получает что-то вроде ограниченного по функционалу рабочего места оператора с возможностью построения маршрутов.
Работа с данными
Как я уже говорил, ИТ-ландшафт крупных банков в России, в принципе, практически одинаковый. Разница в кластеризации (структура ИТ стремится к структуре организации) и в более новых-старых решениях. У каждого крупного банка есть своя разработка, и каждый самостоятельно поддерживает свои решения. В современных финансовых организациях ИТ не живёт отдельно от бизнеса почти никогда, потому что это важный фактор бизнес-эффективности, то есть в конечном счёте конкуренции.
Конкуренция, связанная с ИТ, идёт сейчас в двух основных направлениях: практической применимости анализа данных и удобстве (речь как для юзабилити клиентов, так и для партнёров, а в случае партнёров ещё и удобстве интеграции). В первую очередь анализ данных — это умение работать с рисками. Финансовые организации ярко отличаются от всех остальных игроков ИТ-рынка как раз тем, что отлично понимают, какой риск сколько стоит. Это буквально ядро банковского бизнеса. Например, та же выдача кредита должна сопровождаться скорингом клиента по внешним источникам, по известным платёжным и банковским событиям, по look-alike и другим моделям — чтобы за несколько секунд принять решение о том, какую сумму и с какой вероятностью он сможет выплатить. Если кредит одобряется — значит, риск для нас приемлемый. Очень легко навыдавать безнадёжных кредитов и прогореть, с одной стороны, — и очень легко отдать кредитные сделки банкам-конкурентам с другой.
Также нужен постоянный анализ клиентских потребностей. Данные нужны для создания новых банковских продуктов и сервисов, поиска эффективных способов коммуникации с клиентом и так далее. Маркетинг не может без данных, розница не может без данных, никто не может без данных.
В случае конкретного анализа этих самых данных у нас тоже два поколения систем. Во-первых, традиционная CRM (есть системы для онлайн-принятия решений и офлайн-принятия), анализа маркетинговых компаний и т.п. Данные для этих систем берутся, естественно, не с прода, а с крупного хранилища, содержащего практически полные списки всех банковских событий с момента запуска банка. Данные этого хранилища мы почти не используем в операционных процессах, обновляем его итерациями с некоторым запозданием: для каких-то таблиц это минуты, для каких-то — дни.
Параллельно работает near-realtime-система на Hadoop для анализа больших данных. Она уже может поддерживать операционные процессы, в частности, матчинг, оперативный профиль, может использоваться для работы антифрода и т.п. Данные в неё попадают асинхронно проду, но почти с той же скоростью.
В этом месте вы можете спросить меня про антифрод и другие детали ИБ, но, увы, тут я не могу особо много рассказывать. Общая тенденция — от имплементированных в каждую продуктовую систему решений переходить к централизованному решению, работающему в режиме реалтайм. В ИБ ещё очень важно соответствовать и требованиям ЦБ, и требованиям платёжных систем, что означает определённые требования к архитектуре и процессам разработки и достаточно частые и подробные аудиты.
Текущие изменения
Можно с некоторым допущением сказать, что любой современный банк — это ИТ-компания с банковской лицензией.
Тренд текущей ситуации — замещение коммерческих продуктов, которые сейчас уходят с рынка. Если, например, замена системы бекапа — это просто проект с понятными сроками и понятной ценой, то вот матмодели, которые лежали в некоторых продуктах, заменить куда сложнее. Банкам сейчас придётся с нуля разрабатывать то, что раньше можно было просто купить. В этом плане нам достаточно повезло, что мы всегда делали акцент на собственную разработку. С уходом Визы и Мастеркарда ещё добавилось разработки для карточных продуктов — нужны новые платёжные сервисы и цифровые услуги. Замена всего этого требует капитала: в кризис выживает тот, кто крупнее. Стартапы-финтехи имеют все шансы умереть или продаться, потому что сейчас будет большой период разработки с отложенной выгодой, замены части систем и интеграций, но это и определённая возможность обновления архитектуры. Для банков с большой историей, как мы, это достаточно хороший шанс.
Тренды года те же самые, что и в прошлый, и позапрошлый год: большие данные и клиентская аналитика. Очень большое влияние оказывают переход бизнеса в онлайн и высокие требования к юзабилити клиентских приложений.
Управление разработкой
От гибкости архитектуры зависит скорость разработки, поэтому тенденции в развитии архитектуры тоже более-менее одинаковые: монолиты ядра разных лет, сервисный слой основных продуктов и современные микросервисы поверх. Вся новая разработка максимально ведётся в микросервисах из-за скорости разработки и внедрения и простоты поддержки. Как и всегда, есть потребность выпускать новые вещи быстро. И если в прошлые годы это было конкурентным преимуществом, то сейчас это уже жизненно важная потребность.
Крупные системы создают очень много зависимостей. В нашем случае это системы ядра и продукты: в ядре — монолиты, в продуктах — большие сервисы. Как я уже говорил, всё новое мы делаем на микросервисах, и это связано, в частности, с управленческими процессами и возможностью быстро вносить правки любой команде в то, что у неё в зоне ответственности. Стратегии разбора монолитов вроде «мы всё перепишем за 10 лет» у нас нет. Скорее, мы рассматриваем их как некий операционный ассемблер, а разработку сосредотачиваем не на изменении их функциональности, а на создании сервисов, которые эту функциональность реализуют через атомарные операции, обращаясь к ядру. Поэтому продуктовая логика на фронтах может меняться очень быстро.
В классической архитектуре современного банка у каждого подразделения есть своя крупная ИТ-система. Она чаще всего обособлена, то есть взаимодействует с другими системами на уровне, например, той же шины. Интеграционные проблемы внутри подразделения, естественно, куда меньше, чем снаружи. Именно поэтому нужны микросервисы — разработка двигается в сторону всё более и более тесной интеграции продуктов.
В нашем случае у нас организованы стримы, состоящие из ИТ-специалистов разных компетенций и людей, отвечающих за развитие бизнеса, каждый из которых отвечает за ценность, владеет чем-то крупным в части бизнеса, ИТ-системами или их компонентами и пакетами микросервисов. Команды стримов развивают архитектуру, сами решают, когда и как делать реинжиниринг или рефакторинг. Но, что важно, исходят они не из функциональных потребностей, а из потребности целого стрима. Внутри стримов самый главный вопрос — насколько быстро и безболезненно для основного бизнеса можно выпустить новую фичу или продукт. Некоторые банки продолжают жить редкими крупными релизами уровня «революция каждые полгода». Когда-то и у нас было 4 релиза в год, сейчас 2 релиза всего ландшафта в месяц + минорные патчи.
Естественно, процесс релиза в любом банке — это не то же самое, что поправить код на проде. Любой код, попадающий на прод, проверяется со всех сторон и не один раз. Причём требования ЦБ и вообще индустрии таковы, что проверять нужно не только возможные баги, но и злонамеренное изменение кода изнутри, поэтому тестирование и ревью делают как внутри команд, так и независимый отдел качества. Ещё одна важная вещь на фронтах — проверка интерфейсов, на том же Android сотни моделей телефонов, и если какая-то форма поедет на одной из них, мы потеряем клиентов. Разумеется, пропущенные баги в финансовой логике — это сразу и репутационные потери, и некислые штрафы или другие проблемы от регуляторов или платёжных систем. Кошмарный сон — остановить процессинг на несколько часов из-за ошибки в логике. Кроме нескольких итераций тестов и отладки в командах и потом ещё одной в отделе качества, есть два цикла регресса и нагрузочные тесты.
Релизы фронтов самообслуживания ещё требуют тщательного АБ-тестирования. Нельзя просто так взять и аналитически спрогнозировать поведение людей, нужны именно практические тесты, причём параллельные. Какие шаги в каком порядке, как называть элементы формы, какие данные запрашивать и когда — всё это влияет на продукт и требует поддержания большого количества разных динамических элементов. Для этого тоже нужны отдельные подходы к разработке и тестированию, а не сравнение релизов.
Интеграции с партнёрами — отдельная история. По сути, мы поучаствовали в строительстве отдельной компании-брокера, которая занимается максимально быстрой интеграцией бизнеса с нами и другими банками, чтобы бизнес мог предлагать услуги банка чуть ли не как свои. Крупных партнёров мы можем интегрировать напрямую, но обычно идёт точная работа с партнёрами в POS-бизнесе. Эта компания получает комиссию с заявок, то есть заинтересована в сервисе для них и в поддержании особенных интеграций для каждого по потребностям. Часто они «дружат» нас с сервисами и других банков тоже, что очень удобно для клиента. С точки зрения ландшафта это означает, что у нас есть шлюзы под каждый дружественный банк и партнёров. Понятно, что, если у вас околомонопольное положение на рынке, вы можете просто опубликовать API и сказать, чтобы на него равнялись, но банки из-за конкуренции должны быть гибкими для партнёров. В частности, нужно иметь в архитектуре кучу различных методов интеграций и держать их изолированными друг от друга.
Для управления стримами мы используем фреймворк SAFe, который часто противопоставляют классическому проектному управлению. Это подходы Agile и LEAN, которые не ставят цель проекта, а задают ценность стрима. Упрощённо, набираются компетенции, роли и строятся потоки поставки ценности. Процесс достаточно быстро реагирует на потребности рынка и позволяет оперативно направлять стримы на самую важную ценность для клиента. Классический проектный офис у нас, конечно, остался и адаптировался для сверхкрупных или срочных проектов: это, например, большие требования законодательства, системные вещи для банка. Проектный офис синхронизирует стримы и достаёт все нужные ресурсы. Внутри стримов есть бизнес-владелец, архитектор, ИТ-лидер, Agile-лидер и команды разработки. Эти команды кросс-функциональные настолько, чтобы полностью поддерживать свой продукт. Например, есть стрим карт, есть стрим наличных, есть кредитный стрим — каждая из команд может патчить или дополнять фичами свои части ИТ-ландшафта так, чтобы не зависеть от других команд. Внутри команды разработки обычно есть три базовых роли: аналитик, разработчик, тестировщик. Где-то добавляются девопсы, где-то юзабелисты и так далее по потребностям. Есть отдельные команды платформенных сервисов.
Как меняется ландшафт
Мы стараемся виртуализовать всё возможное и положить в контейнеры. Это эффективность утилизации железа и переход с х64 на х86. Плюс мы кроме своих ЦОДов в Москве и Обнинске используем облака, где можно размещать некритичные системы.
Очень много внимания сейчас уходит на «шины нового уровня» очередей сообщений, которые не требуют для работы синхронных методов, но при этом близки к реальному времени. Это та же Kafka, она лёгкая в подключении к ней разных источников. По факту она работает в асинхронном режиме, но позволяет интегрироваться в режиме близком к realtime и уменьшает излишние зависимости систем.
