Всем привет! Многие IT-компании, да и мы в Сбере пытаемся принять на работу лучших сотрудников. Часто наши HR-специалисты отмечают, что у кандидата возникают дополнительные вопросы в части задач и технического стека платформенной команды в SBI (Sberbank International). Так вот, данная статья раскрывает немного деталей о SBI Platform Team, чтобы у кандидата сразу было представление о том, над чем мы работаем.

Я Артём Соковец, руковожу платформенной командой в Sberbank International. До этого был TeachLead&ProductOwner продукта Platform V Studio. Прошёл путь от специалиста по автоматизации тестирования до лидера SDETs, а в 2018 году сменил профиль на разработку и двигаюсь в этом направлении дальше с заплывом в смежные области — DevOps и MobileDev.  

Давайте погрузимся в нашу специализацию. Сейчас есть три основных направления, о которых далее пойдёт речь:

1. Адаптация Platform V под дочерние банки в других странах.

2. Разработка новых бизнес-приложений с использованием Platform V.

3. Разработка интеграционного слоя с использованием Synapse.

Кому интересно узнать детали, прошу под <cut>.

1. Platform V в другие страны

Чтобы стандартизировать процесс разработки и уменьшить T2M (time to market) вывода новых продуктов и их TCO (total cost of ownership), в Сбере используется технологическая платформа Platform V. А что такое, собственно, платформа? Это готовая среда разработки, компоненты, инструменты и набор паттернов для создания и исполнения приложений любой сложности в облаке. Компоненты образуют 4 основных слоя платформы: фронтальные сервисы, сервисы аналитической платформы (т. н. «фабрика данных»), сервисы интеграционной платформы, сервисы для построения бэкенда. В плане функционала компоненты можно поделить на 8 основных групп:

На первый взгляд может показаться, что компонентный состав платформы Сбера повторяет те же Google App Engine или Cloud Foundry, предлагая инструменты автоматизации пайплайна CI/CD, журналирования, мониторинга, AI, работы с реляционными БД, вычислениями в памяти и интеграций. 

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

Если кратко пробежаться, то, пожалуй, отмечу:

• платформа позволяет строить вычисления на виртуалках, по модели container-as-a-service, в k8s, serverless, через оркестрацию процессов или систему бизнес-правил в BRMS;

• из коробки доступен service mesh, управляемые событийные кластеры, поддерживается потоковая обработка событий через Flink;

• есть готовый фреймворк для горизонтального масштабирования приклада по паттерну application sharding;

• с данными можно работать и в реляционной, и в NoSQL-модели. Для удобства есть готовый сервис построения масштабируемой отказоустойчивой модели данных со встроенной скоростной репликацией, авторизацией доступа к данным, интеграции со слоем аналитики и другими свистелками;

• в аналитической платформе можно решать любые задачи современного BI, DW, рассказ о ней заслуживает отдельной статьи;

• есть полноценный набор инструментов для организации CI + CDL + CDP, тестирования, своих репозиториев кода, докер-контейнеров и pro-шная IDE для разработки;

• есть готовые сервисы для решения типовых задач — PIM, документооборот, справочники и т.п.

Более детальное описание продуктов вы можете найти здесь.

А для чего нужна платформа? В среднем, по нашей оценке, на продуктивную разработку специалист тратит не более 15% своего времени. В остальную часть дня он выполняет важные вспомогательные задачи: развернуть, настроить системное ПО, развернуть, настроить БД, средства мониторинга, логирования, аудита, передачу сообщений и многое другое. Platform V позволяет забрать у разработчика всю рутину, дать ему возможность сфокусироваться на бизнес-логике и сделать его работу более продуктивной. 

Взять и установить платформу, как она есть, в дочерний банк невозможно. У каждой организации есть свой IT-ландшафт, с которым необходимо выполнить интеграцию, свои бизнес-процессы и другие бизнес- и технические заморочки. Здесь вступаем в игру мы как платформенная команда. Требуется адаптировать платформу: заменить определённые сервисы/продукты, дополнить новыми сервисами, протестировать новый функционал, провести нагрузочное тестирование, убедиться, что мы ничего не сломали, разработать скрипты деплоя и итогом вывести всё в промышленную эксплуатацию.

Так, например, в связи с локальными особенностями авторизации и аутентификации в одном из дочерних банков нашей платформенной команде потребовалось создать отдельный сервис, который отвечает за управление сессиями клиента и интегрирован с существующими системами дочерних банков. Для сбора продуктового профиля клиента потребовалось полностью переработать существующий платформенный сервис, т. к. интеграционное взаимодействие с IT-системами и логика работы кардинально отличаются от реализации в головном Сбере. 

Процесс адаптации платформы для использования в дочерних банках выстроен следующим образом: сначала мы проводим презентационную встречу, выявляем потребности заказчика, доносим ценность каждого платформенного дистрибутива (solutions), определяем состав сервисов для адаптации — и отправляемся в путь. IT-команда заказчика обычно обращается уже со сформированными потребностями и требованиями, включая юридические особенности работы.

Но наши задачи не заканчиваются только работой с Platform V, перейдём к следующему направлению.

2. Разработка новых бизнес-приложений с использованием Platform V

Кроме адаптации платформенных сервисов, есть и разработка бизнес-приложений с нуля. Например, продукт «Кобраузинг», когда клиенты могут продемонстрировать сотруднику контакт-центра экран своего устройства, то есть оператор дистанционно подключается и видит экран клиента в интернет-банке СберБизнес, СберБанке Онлайн и в других приложениях. Сервис не требует дополнительной установки программного обеспечения. Благодаря этому инструменту сотрудники банка своими глазами видят проблему клиента и сразу же приступают к устранению технических ошибок, помогают в навигации по приложению. Мы такой продукт разработали для коллег из Беларуси на базе нашей платформы. Ниже приведена краткая архитектурная схема.

Суть такая: на странице (WEB) уже встроен JS Bundle, который реализует логику обращения и помощи клиента. В части бэка есть два сервиса — клиент и оператор (разбили на два микросервиса для легковесности и чтобы не перегружать лишней логикой). Оба реализованы на Java 11. Они хранят в себе всю бизнес-логику (создание и управление сессиями, координация обмена сообщениями между клиентом и оператором, логирование и т. д.). Для доставки сообщений между клиентом и оператором используется брокер сообщений Kafka в двух имплементациях — основной и резервной. Для хранения кросс-сессий клиента и оператора используется база данных PostgresSQL. Ignite используется для хранения файлов ресурсов, которые передаются с фронта клиента на фронт оператора для корректного отображения страницы клиента. Необходимо это из-за того, что довольно много ресурсов автоматизированных систем СберБанк Онлайн (СБОЛ) и СберБанк Бизнес Онлайн (СББОЛ) хранится на сервере статики во внешней сети, а оператор работает из внутренней сети банка, откуда нет доступа к внешним серверам. Platform V IAM (Identity & Access Management) хранит пользователей и их привилегии (ролёвки), а стартовый менеджер используется для создания сессии оператора в платформе. Фронт оператора реализован на React, Redux, TypeScript и имплементируется в CRM Siebel.

Для наглядности процесса приведём схему последовательности вызовов сервисов для клиента:

Вначале скачиваются настройки — правила маскирования, правила работы с DOM-моделью и пр. Далее создаётся клиентская сессия (в БД сохраняется кросс-сессия) или возвращаются данные уже созданной сессии, если сеанс был прерван. В дальнейшем для каждого сообщения генерится уникальный токен. Он содержит ряд параметров, по которым будет осуществляться верификация пользователя. Затем, чтобы оператор видел полную картину, ему передаются ресурсы с сервера статики фронт-приложения клиента, которые бэк кладёт в Ignite. После осуществляется регулярный (несколько раз в секунду) обмен сообщениями, в которых отправляются действия клиента и приходят действия оператора, если они были. При этом происходит маскирование личной информации клиента — то есть оператору не передаются и не отображаются личные данные клиента: номера карт, остатки на счетах и пр. Обмен сообщениями происходит до тех пор, пока клиент или оператор не завершит работу, после чего сессия клиента и кросс-сессия закрываются.

Для оператора схему приводить не будем, она аналогичная.

Ещё одним примером бизнес-приложения с нуля является микросервис «Платежи», который реализует логику создания платежа более чем по 5600 видам услуг. При этом при добавлении нового вида платежа модификация исходного кода не требуется. За основу был взят микросервис, разработанный в Сбере. Он доработан с учётом новых программных сценариев и локальной специфики страны. Сервис развёрнут для мобильной и web-платформ и является для дочернего банка высокодоходным и business-critical. Мастер-система дочернего банка представляет собой собственный биллинговый модуль, поддерживающий интеграции как с основными государственными сервисами, рынком платёжных операторов, так и с конечными поставщиками услуг. Поиск платежа проводится пользователем через каталог, QR-код, штрих-код и по диплинк. Для пользователя доступны подписки на получение счетов по повторяющимся платежам с уведомлением, а также создание и управление автоплатежами. Реализован сервис оплаты административных штрафов с просмотром оригинальных протоколов в формате pdf и налоговых начислений с упрощённым для пользователя UI при оформлении платёжного поручения. Оплата мобильной связи реализована с использованием интеграции с MNP базой данных операторов СНГ, что позволяет снизить риск ошибки при оплате мобильной связи.

Мы гибко подходим к выбору методологии производства, широко используем и Scrum и Kanban. Проводим кросс-командное Code Review. Используем quality gates для проверки выпускаемых дистрибутивов. Стоить отметить, что помимо разработки бэка и фронта (web), также есть и мобильная разработка под Android и iOS, где мы используем модульный подход и мобильную платформу, в которую включены фреймворки дизайн-системы, сетевого слоя, утилит и backend driven UI-механизма, позволяющего безрелизно доставлять фичи до пользователей. Это всё позволяет нам максимально переиспользовать кодовую базу, создавать новые экраны и фичи, словно из кубиков лего.

Когда сервисы и приложения реализованы, приходит время подумать над маршрутизацией и оптимизацией коммуникаций. С этим нам поможет Service Mesh.

3. Разработка интеграционного слоя с использованием Synapse

В части интеграционного слоя мы используем продукт Platform V Synapse Service Mesh (далее — SSM). SSM является частью интеграционной платформы Synapse и обеспечивает интеграцию приложений с использованием подхода service mesh, или «сервисная сетка». Данный подход предполагает реализацию интеграционной логики на выделенных проксирующих компонентах (service proxy или сервисный прокси), развёрнутых в непосредственной близости от прикладного кода в режиме sidecar (контейнеры с проксирующим компонентом и прикладным кодом разворачиваются в одном pod). Подробное описание подхода service mesh можно найти по ссылке.

В целом Synapse — интеграционная платформа. Это решение на базе технологии service mesh уровня enterprise, то есть подходящее для больших корпораций. Для банка оно обеспечивает возможность отказа от решений вендоров и перехода на продукты, построенные с использованием open-source технологий. Synapse строится на базе Istio-решения, которое является одной из имплементаций архитектуры service mesh.

А ещё он поддерживает EDA (event-driven architecture).

Из преимуществ Synapse, пожалуй, отмечу:

• по-человечески сопровождаемый дистрибутив istio без завязки на фичи от RedHat;

• из коробки доступны инструменты предиктивного скейлинга и фейловера;

• готовые компоненты для событийной обработки, в том числе с возможностью репликации событий между кластерами kafka и потоковой обработки через Flink;

• при необходимости для всех интеграций можно активировать авторизацию взаимодействий.

Далее вы найдёте «простенькие» примеры блоков кода из интеграционных адаптеров, которые мы разрабатываем. В примере ниже приведён Java-код адаптера, реализованного на SpringBoot, отвечающий за run-time-реконфигурацию логирующего HTTP прокси-сервера.

List<RouteDescriptor> newRoutes = routes.stream()
            .map(routeConfig -> {
                    try {
                        String metricSuffix = routeConfig.getDownstream().replace('/', '_');
                        return RouteDescriptor.builder()
                            .downstream(routeConfig.getDownstream())
                            .upstream(new URI(routeConfig.getUpstream()))
                            .methods(splitMethodsString(routeConfig.getMethods()))
                            .messageParts(logProcessor.splitMessageFormat(routeConfig.getLogMessage()))
                            .downstreamMessageType(routeConfig.getDownstreamMessageType())
                            .upstreamMessageType(routeConfig.getUpstreamMessageType())
                            .callCounter(Counter.build(String.format("%s%s", COUNTER_PREFIX, metricSuffix), "Call counter").create())
                            .failedCallCounter(Counter.build(String.format("%s%s", FAIL_COUNTER_PREFIX, metricSuffix), "Failed call counter")
                               .create())
                            .callDuration(Histogram.build(String.format("%s%s", LATENCY_PREFIX, metricSuffix), "Call latency").create())
                            .build();
                    } catch (Exception error) {
                        log.warn("Error parsing route '{} - {} - {}':", routeConfig.getDownstream(), routeConfig.getUpstream(),
                            routeConfig.getMethods(), error);
                        return null;
                    }
                }
            ).filter(Objects::nonNull)
            .collect(Collectors.toList());

Этот пример, написанный на Go (да, на нём мы тоже разрабатываем адаптеры), предназначен для перекладки определённых параметров из тела сообщения в заголовок.

var extracted_value string
var extract_result int

path := config.Paths[path_index]

if path.BodyType == "json" {
    extracted_value, extract_result = extractFromJson(data, path.CompiledExtractExpression)
} else { // "xml"
    extracted_value, extract_result = extractFromXml(data, path.CompiledExtractExpression)
}

upstream_request, err := http.NewRequest(request.Method, config.UpstreamUrl, bytes.NewReader(data))
if err != nil {
    response.WriteHeader(500);
    fmt.Fprintf(response, "error creating upstream request: %s\n", err)
    fmt.Println("error creating upstream request: %s\n", err)
    return

}

upstream_request.Header = request.Header.Clone()
if extract_result == 0 {
    current := upstream_request.Header.Get(path.HeaderName)
    if current == "" || path.Replace {
        upstream_request.Header.Set(path.HeaderName, extracted_value)
    }
}

upstream_reply, err := client.Do(upstream_request)
if err != nil {
    response.WriteHeader(502);
    fmt.Fprintf(response, "error reading upstream reply (exchange): %s\n", err)
    fmt.Println("error reading upstream reply (exchange): %s\n", err)
    return
}

Итого мы с вами рассмотрели три основных направления, над которыми работаем в платформенной команде. Наш стек:

• Backend — SpringBoot, Java 8-11/Kotlin/Go, Maven/Gradle, Istio;

• Frontend — Redux, React, TypeScript;

• DB — Apache Ignite, PostgresSQL, Oracle;

• MQ — IMB MQ, Kafka;

• CI/CD — Jenkins, Ansible, Docker, OpenShift, Kubernetes;

• Environment — Jira, Adaptavista для тестирования, Nexus, Bitbucket.

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

// Необходимо реализовать функцию, которая удалит в строке
//все повторяющиеся подряд символы таким образом,
//чтобы на выходе получилось: "Кошка запрыгнула на забор"
 
const sentence = "Кккоооошккаааа Зззапрыыгнулаа   наааа зааабоооррррр";
 
function removeRepeats(value) {
  // your code here
  return "Кошка запрыгнула на забор";
}

Кому интересно попробовать себя в международном блоке Сбера в качестве разработчика, системного аналитика, DevOps-инженера и специалиста по функциональному тестированию — приходите к нам.