Как платформенный подход помогает нам быстро выпускать сервисы и при этом делать упор на качество

Мы решили использовать сервисный подход не в угоду модным трендам, он эффективно помогает справиться с основной проблемой любой крупной разработки — рассогласованностью «интересов» команд бизнеса и ИТ. Зачастую команды (или стримы), ведущие продуктовую разработку, заинтересованы в максимально низком значении параметра time-to-market, чтобы быстро разработать какой-либо MVP-продукт и вывести его сразу же на АБ-тестирование на клиентах. Иногда это делается в ущерб качеству и инженерным практикам и стандартам, начинает копиться техдолг…

А вот у платформенного решения ключевые показатели KPI — скорость разработки, доступность и стабильность. В идею платформы заложены показатели эффективности, связанные с повышением качества и скорости разработки ИТ-продуктов, от чего выигрывают и команды разработки, и происходит улучшение бизнес-показателей стримов.

Платформа - это основной технологический драйвер, приводящий команды разработки к единому техническому знаменателю. Это набор общих сервисов, библиотек, общей инфраструктуры, практик и стандартов, общих Quality Gates, а также большое комьюнити инженеров, работающих в единой среде и по общим правилам. Платформа позволяет убрать «двойные косты» на разработку командами общих компонентов. Но в то же время, платформа - это дорого, так как нужна платформенная команда, развивающая платформу, а она может стоить немалых денег. Но про это чуть дальше.

Иными словами, главная цель создания сервисной цифровой платформы (СЦП) в «Газпромбанке» — улучшить технические показатели процессов «delivery» компании за счет превращения лучших ИТ-практик в корпоративные стандарты.

Однако влияние, которое оказывает переход на СЦП, выходит далеко за границы чисто технических инноваций. Не менее важен второй аспект изменений - он связан с трансформацией процесса разработки в компании в целом.

Традиционная организационная структура разработки в крупной компании неповоротлива и включает немало уровней эскалации решений: в крупных банках я встречал до восьми уровней. Это неэффективно в условиях, когда конкуренты борются за сокращение сроков вывода продуктов на рынок, а тебе каждую фичу нужно согласовать в 10 инстанциях. «Газпромбанк» принял решение радикально реорганизовать процессы разработки и предоставить максимальную автономность командам, в том числе платформенным. Идея заключается в том, чтобы отойти от функционального деления команд: отдел тестирования, отдел аналитики, отдел разработки отдел эксплуатации и так далее. Вместо этого появился набор кросс-функциональных команд, способных выполнить любую задачу самостоятельно в полном объеме, не теряя времени на ожидание в очереди у дверей соседних отделов.

В результате общая структура разработки значительно изменилась, превратившись, по сути, в группу стримов. Их внутренняя структура также стала гораздо проще. Например, я как ИТ-лидер платформенного стрима СЦП, ставлю крупные задачи (эпики) своим командам, а технические лиды этих команд управляют распределением задач между конкретными специалистами и сами решают, как они будут реализованы. Без этой трансформации нам вряд ли удалось бы создать эффективно работающую платформу, ведь команда должна уметь выполнить любую задачу самостоятельно: от анализа входящих требований до исполнения требований до эксплуатации сервисов в продакшене.

Появление СЦП обусловливает большие изменения и в ИТ-архитектуре, поддерживающей разработку. В классической модели главенствующую роль играет централизация процессов – над одним большим сервисом одновременно работают много команд. А в рамках микросервисной архитектуры нужно разбить большой сервис на множество отдельных микросервисов, которые команды могут разрабатывать и выводить в продакшн самостоятельно. Так появляется возможность четко отделить бизнес-разработку от технических платформенных задач: бизнес-разработка уходит в бизнес-стримы, а платформенный стрим сосредоточивается исключительно на задачах технического совершенствования платформы, процессах предоставления общих сервисов и инфраструктуры бизнесов-стримам.

Главная задача платформенного стрима — предоставлять командам качественный платформенный сервис, который помогает быстро, самостоятельно и параллельно друг с другом разрабатывать любые продукты.

Еще один важный результат такого подхода — неограниченные возможности масштабирования разработки: в любой момент в штате банка может появиться новая команда, которая должна быстро выполнять задачи по выпуску новых продуктов, не сталкиваясь с узкими местами — ни в ИТ-архитектуре ни в организационном управлении.

Эта задача уже решена. Ядро платформы работает на направлении интернет-банкинга для физических лиц, где обслуживается несколько миллионов клиентов.

Общая структура СЦП включает три основных компонента: кеширующий слой, информационные сервисы и платформа волеизъявления.

Кеширующий слой

Сервисы цифровой платформы реализованы как промежуточный слой между каналами взаимодействия с клиентами и слоем backend-систем. К каналам взаимодействия с клиентами относятся мобильный банк, интернет-банк, фронт-офис и кол-центр. В числе backend-систем — АБС, транзакционные и процессинговые системы.

В такой конфигурации платформа играет роль защитного слоя, который за счет кеширования данных защищает работоспособность бизнес-сервисов от высокой нагрузки: микросервисы обращаются за информацией не в backend ПО, а в кеширующий слой. Там накапливаются и хранятся относительно большие массивы данных, уже близкие по объему к терабайту.

Инфосервисы

Так мы называем единый слой интерфейсов API, которые позволяют получить данные в любой клиентский канал. Скажем, если клиент запрашивает баланс карт из мобильного приложения, этот запрос обращается к API платформы.

Причем этот слой — достаточно умный: он сам понимает, откуда надо взять информацию. Например, данные кеша в определенный момент могут оказаться неактуальными. Тогда платформа принимает решение обратиться в систему, где хранятся данные, получает их с соблюдением требований к согласованности, завершает обработку клиентского запроса и добавляет сведения в кеш.

С точки зрения практической реализации слой инфосервисов представляет собой микросервисную платформу, работающую внутри СЦП.

Платформа волеизъявления

Волеизъявлением мы называем операцию, которая требует активного действия клиента, например, сделать перевод, закрыть счет, оформить кредит. Наша обезличенная платформа может обработать любое волеизъявление пользователя. Для этого ее работа стандартизирована: новый сценарий подключается по определенному протоколу. Например, если бизнес-команда решит предложить клиентам сервис оплаты штрафов ГИБДД через личный кабинет онлайн-банка, решение будет реализовано как сценарий волеизъявления. После завершения разработки сценарий интегрируют с платформой волеизъявления по специальному протоколу — и клиент получит возможность отправлять запросы этого типа.

Приведу пример. Команда безопасного банка занимается разработкой электронной подписи. По завершении разработки они выставляют на платформе протокол, и далее система волеизъявления пользуется им, чтобы накладывать на документы электронную подпись.

Важный элемент платформы волеизъявления — поддержка продвинутого интерфейса пользователя (User Interface, UI). Он реализуется в стиле backend driven UI, то есть backend-ПО генерирует специальную мета-информацию, которую UI умеет интерпретировать и отрисовывать пользовательский интерфейс в соответствии с ней. Функция позволяет не выпускать новые релизы сервиса при каждом изменении отображаемых данных, скажем, после обновления дизайна картинки на экране, появления новой «иконки» или поля данных. Такие изменения происходят часто, но при наличии умного UI не приходится каждый раз заново пересобирать мобильное- или веб-приложение. Достаточно добавить метаинформацию на backend-уровне, и она будет отражена в клиентском ПО.