На чем написан сбербанк онлайн

Обновлено: 25.04.2024

В 2002 году Сбербанк запустил простые СМС-уведомления, которые сообщали о расходах по карте и состоянии счёта. В 2011 году появилось первое онлайн-приложение для клиентов, и теперь ему исполнилось целых 10 лет! Это самое популярное банковское приложение в России с аудиторией более 65 миллионов человек. Рассказываем, как команда работала над продуктом, через какие препятствия проходила и какие уроки вынесла. Поехали!

Предупреждение! Текст длинный, но и приложению СберБанк Онлайн 10 лет всё-таки ;)

В 2010 году на рынке вслед за iPhone появился iPad. Сбербанк хотел быть на одной волне с клиентами, которые следили за новыми технологиями, и уже в 2011 году выпустил приложение для планшета. C его помощью можно было смотреть информацию по картам, вкладам и кредитам, совершать мгновенные платежи и делать переводы между своими счетами. Для входа использовали логин и пароль — их можно было получить в банкомате или офисе Сбербанка. Помните такое?

Да, приложение простое, но все основные функции там были, и именно оно стало прототипом всех будущих версий. Развивать его взялось наше первое инновационное подразделение — «Банк XXI». Его в 2011 году создали специально для того, чтобы решать задачи клиентов не только в отделениях, но и на расстоянии — по телефону и в сети.

В январе появилось приложение «Сбербанк ОнЛ@йн» для iPhone, в мае — для смартфонов на Windows Phone, а в декабре — и для Android.

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

Решение оказалось удачным, и вход по пятизначному коду стал стандартом для банковских приложений. Но команда допустила ошибку: пользователей перевели на новый способ входа без предупреждения. Из-за этого у многих клиентов возникли сложности. Например, для подключения нового способа им нужно было подтвердить свою личность, введя код из СМС, и только потом придумать пятизначный код. Но клиенты принимали цифры из СМС за сам код — возникала путаница. За неделю порядок действий исправили, но эта история многому научила команду. Стало ясно, что к любым изменениям клиентов нужно готовить заранее.

До 2013 года работа строилась по системе заказчик — исполнитель: бизнес-подразделение составляло техническое задание и отправляло его в IT-департамент, находившийся в другом офисе. После преобразований департаменты «съехались» в одно пространство и разделились на небольшие agile-команды. В этих командах были и представители бизнес-подразделения, и разработчики. Теперь они общались каждый день и вместе генерировали решения.

Это сработало: рейтинг приложения в App Store вырос с 2,4 до 4,5 звёзд. А число активных пользователей стремительно росло. Сейчас такие числа кажутся маленькими, но для приложения в возрасте двух лет это был важный рубеж — к концу года им пользовался миллион человек.

В 2014 году на первое место вышла стратегия mobile first: раньше приложение служило дополнением к веб-версии, а теперь должно было стать полноценным продуктом.

В приложении появился «бублик»: кнопка, которая показывает траты клиента. И новый сервис «Цели», чтобы, изучив доходы и траты, человек мог поставить цель — накопить определённую сумму. Функция понравилась клиентам. Они нашли ей ещё одно применение — в качестве «конверта» для хранения денег, чтобы случайно не потратить лишнего. Сегодня в приложении ежемесячно создают более 600 тысяч целей, а сервисом «Анализ личных финансов» пользуются более 11 млн человек. В последующие годы в разделе появились возможности устанавливать лимиты на обязательные расходы, расчёт свободных средств на месяц и день, прогноз расходов по категориям трат.

Тогда же, в 2014 году, Сбербанк стал одним из первых в мире банков, который добавил идентификацию по отпечатку пальца — такая возможность появилась, когда Apple запустил поддержку Touch ID. А ещё название и логотип онлайн-банка поменялись: символ @ и заглавные буквы посреди слова к тому времени устарели.

Сбербанк окончательно превратился из «банка в шаговой доступности» в «банк с доступом в один клик». В приложении пользователи могли мгновенно получить любую услугу: перевести деньги, подать заявку на кредит, проанализировать и спланировать бюджет.

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

Среди важных нововведений года — отображение адресной книги в приложении. Переводить деньги по номеру телефона стало удобнее — и число таких операций резко выросло.

В том же году команда взяла «курс на эмоции». Все пользователи видели персональные приветствия при входе в приложение и «живые» иллюстрации, которые менялись в зависимости от времени суток. Одной из фишек стала падающая звезда: она появлялась не каждый раз, поэтому те, кто её увидел, могли загадать желание — прямо как с настоящей звездой. Позже клиенты смогли сами устанавливать имя, по которому к ним обращается система, и ставить на заставку собственную фотографию.

В России появился Apple Pay — запуск прошёл в партнёрстве со Сбербанком. На переговоры и реализацию проекта ушло два года, и в итоге выход на российский рынок стал одним из самых успешных запусков для Apple. В этом же году нашим клиентам стал доступен Samsung Pay.

В 2016 году изменилась культура тестирования обновлений приложения, и, как следствие, снизилось количество багов, которые доходили до пользователей. Новую версию стали «раскатывать» сначала на сотрудников банка, затем собирать обратную связь, при необходимости дорабатывать функционал и только после выпускать обновление для всех пользователей.

Раньше разработкой и развитием СберБанк Онлайн занималось одно подразделение, в 2017 году мы начали создавать платформу, в которую вошли команды, работающие над приложением. Сейчас в неё входят более 200 команд, которые выводят обновления каждые 3 недели, а не раз в 3 месяца, как было до изменений. В каждом обновлении — 30–40 изменений вместо прежних 5–6. Такие темпы стали возможны благодаря agile-трансформации, которая началась в банке годом ранее: команда СберБанк Онлайн была одной из первых, кто перешёл на модель гибкой работы.

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

Осенью появился единый поиск по всем элементам СберБанк Онлайн. Раньше в разных блоках приложения существовали пять поисков: по контактам, по организациям и так далее. Это было неудобно. Теперь всё легко найти в одном окне, а система самообучающихся алгоритмов предугадывает запросы каждого пользователя и выводит подсказки. В поиск интегрировали NLP-платформу: она обрабатывает запросы с неточными формулировками и исправляет опечатки.

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

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

Но сильнее всего изменилась «начинка» — в приложение добавили множество новых функций и сервисов. Теперь с помощью умных алгоритмов СберБанк Онлайн подстраивается под каждого клиента. Нейросети анализируют предпочтения человека по 1000 параметров и предлагают варианты действий, которые подходят именно ему. Чтобы воспользоваться нужной функцией было легче, на главном экране появились карточки, которые ведут к определённому действию. Например, к переводу конкретному человеку или оплате услуг ЖКХ.

А в «Диалогах» в 2019 году появились каналы: команда собрала мини-редакцию и выбрала самые интересные темы, такие как родительство, финансовая грамотность, карьера, информационная безопасность. Формат коротких постов понравился пользователям: сегодня в приложении 15 каналов с 4,6 млн подписчиков.

В 2020 году, который для всех выдался непростым, команда сфокусировались на эмоциональном взаимодействии с клиентами и красоте приложения. В мае партнёром по красоте стал Эрмитаж: в приложении появились наборы приветственных заставок и цифровых открыток с репродукциями полотен французских живописцев XIX века — Клода Моне, Поля Сезанна, Альфреда Сислея и Винсента Ван Гога.

В августе команда вместе с молодыми художниками фантазировала о том, как будет выглядеть будущее — и запустила проект «2041». Художники создали 15 работ-высказываний и показали, каким видят мир через 21 год: репродукции также можно было использовать как заставки.

Другой наш партнёр — Третьяковская галерея — поделился изображениями шедевров Виктора Васнецова, Ивана Шишкина и других классиков, а также репродукциями полотен российских авангардистов, которые сегодня тоже можно установить на приветственный экран приложения.

Кроме того, СберБанк Онлайн «заговорил» — в приложении появились виртуальные ассистенты семейства Салют. Это три персонажа с разными характерами: Джой, Афина и Сбер. Помощника можно попросить показать баланс карты, сделать перевод, рассказать о курсе валют и многое другое. А можно просто поболтать.

Всех планов мы раскрыть не можем, но кое-чем всё-таки поделимся. Мы точно будем улучшать существующие сервисы и добавлять новые, причём так, чтобы клиентам было легко и просто к ним привыкнуть.

14 мая 2022 года разработчик мобильных приложений под iOS Саид Ахмедов (Said Akhmedov) открыл исходный код приложения «Сбербанк онлайн сайт». Он не считает себя мошенником, как квалифицировали в «Сбере» его действия после создания и публикации приложения в App Store.

Сейчас в его аккаунте разработчика это приложение также не отображается. Автор самостоятельно его удалил из App Store по запросу службы безопасности «Сбера».

Размер приложения «Сбербанк онлайн сайт» составлял 391,2 КБ.

«Исходный код приложения «Сбербанк онлайн сайт». Простой и понятный, что приложение ведёт на официальный сайт Сбербанка онлайн. Никакие данные утечь не могут так как все дальнейшие действия пользователь совершает на стороне Сбербанка»,

— пояснил Саид Ахмедов.

«Создал приложение за 5 минут для друзей и знакомых, которым необходимо для удобства входа в Сбербанк онлайн, а попало в топ-10 приложений App Store, что меня удивило.

Также у меня не было никаких планов для мошеннических действий. Во время создания и публикации приложения в App Store я использовал свой аккаунт разработчика со своими паспортными данными и контактными данными»,

Отраслевой эксперт Павел Гросс-Днепров пояснил, что в этом случае «Сбер» даже может подать в суд на автора приложения за нарушение авторских прав и потерю репутации. По его мнению, суд встанет на сторону истца. Он надеется, что «Сбер» на это не пойдет.

13 мая «Сбер» предупредил пользователей о нескольких мошеннических приложениях в App Store, которые имеют логотип банка и имитируют работу, чаще всего частично и без доступа к счетам и аккаунтам клиентов, оригинального мобильного приложения «Сбербанк онлайн». В компании рассказали, что это мошенники, которые размещают вредоносные приложения под видом банковских.

6 апреля 2022 года СМИ сообщили, что Минфин США ввел полные блокирующие санкции против российского банка «Сбер» и крупнейшего в стране частного банка «Альфа-Банк». Санкции предусматривают заморозку активов банков и введение запрета для граждан и компаний из США на ведение бизнеса с ними.

«Сбер» после инцидента стал учить пользователей iOS запускать веб-версию «СберБанк Онлайн» через ярлык на домашнем экране.

5 мая «Сбер» попросил пользователей iPhone отключить опцию «Сгружать неиспользуемые», чтобы Apple не удаляла мобильное приложение «Сбербанк Онлайн» со смартфонов, если долго не пользоваться приложением.

12 апреля 2022 года «Сбер» выпустил серию слайдов, где учит пользователей iOS запускать веб-версию «СберБанк Онлайн» на iPhone или iPad через ярлык на домашнем экране.

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

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

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

Эксперты тогда пояснили, что приложения «Сбера» и «Альфа-Банка» в скором времени будут убраны из App Store и Google Play из-за ввода санкций против этих организаций. Приложения «Альфа-Банк» и «Сбербанк» тогда ещё не были убраны с этих площадок, они также были доступны в AppGallery.

7 апреля 2022 года «Сбер» сообщил, что установленные у пользователей мобильные приложения «Сбербанк Онлайн» продолжат работать на iOS и Android и далее после введения санкций против организации. Компания заранее подготовилась к возможным ограничениям в работе мобильных приложений и создала решение, которое позволит сохранить полную работоспособность мобильных приложений, уже установленных на смартфонах пользователей.

9 апреля «Сбер» назвал фейком распространяемые в сети слухи о том, что с 11 апреля установленные ранее мобильные приложения «Сбербанк Онлайн» прекратят работать на iOS и Android.

У «Сбера» есть раздел сайта, где опубликованы советы по обновлению его приложения, но еще нет ссылки на загрузку локальной версии для Android. Также у «Сбера» есть свой внутренний корпоративный магазин приложений для разработчиков и специалистов под названием SberStore. С помощью этой платформы «Сбер» создает, тестирует и распространяет между партнерами приложения для умных устройств своей экосистемы: телевизоров, ТВ-приставок, колонок и других устройств.

Также ссылки на альтернативную версию скачивания мобильного приложения нет в разделе сайте «Сбера», где сейчас указаны два варианта выбора приложения для пользовательского устройства: для Android и магазина приложений AppGallery от Huawei.

Много кто пользуется приложением Сбербанк Онлайн, но немногие знают, как оно работает. Настало время приоткрыть завесу тайны – в этой статье мы расскажем о некоторых подходах, которые используем в разработке.

Здесь не будет биг даты, блокчейна, аджайла и другого рокет-сайенса. Зато будет описано API, на котором работают наши самые популярные приложения. Ценность этой статьи не в прорывных идеях, а в подходах и практиках, которые работают в большом приложении с одной из самых требовательных аудиторий.

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

О чем пойдет речь

Мы расскажем, как в мобильном и веб приложениях Сбербанк Онлайн работают платежные сценарии, а именно про API между приложениями и сервер-сайдом.

Почему фокус на API? Все просто – это фактически единственный мостик, который соединяет клиентские приложения и бэкенд. Если проект небольшой, то мы можем легко менять API и переписывать под него приложения. Но если проект масштабный (такой, как у нас), то даже небольшие изменения API требуют вовлечения большого количества ресурсов как на фронте, так и на бэкенде, и становятся очень дорогими. И второй момент – чем раньше мы зафиксировали API, тем раньше фронтальные и бэковые команды могут начинать разработку. Им просто надо будет сойтись в одну точку.

Сначала мы немного расскажем о наших возможностях и ограничениях, чтобы было понятно, почему мы выбирали то, а не иное решение, а потом представим сам протокол API на верхнем уровне.

Специфика и мотивация

Приложения большие. Когда мы писали эту статью, приложение Сбербанк Онлайн на Android занимало около 800 000 строк кода, на iOS – 500 000 строк кода. И это только наш код, без подключаемых библиотек.

Обратная совместимость и много пользователей. MAU – 32 млн активных пользователей мобильного приложения. И если мы не сделаем обратную совместимость на уровне API, очень многим пользователям по всей стране придется качать приложения заново. Это очень нехорошо. Кстати, это одна из причин, почему у нас так много кода.

Сбербанк Онлайн разрабатывает много небольших команд. Вы, наверное, слышали про Agile в Сбербанке. Это правда, мы работаем по Agile в командах по 9 человек.

Приложение банковское: несмотря на то, что функциональность банковских приложений растет очень быстро, основное, что происходит в дистанционном банкинге – это последовательный процесс (обработка клиентских заявок). Такие процессы мы называем workflow. Заявки эти могут быть разного рода и обрабатываются они огромным количеством взаимосвязанных сервисов в периметре банка.

Два типа команд. Есть платформенные – они отвечают за разработку ядра приложения. И есть фичёвые команды – они создают прикладной функционал для конечных пользователей, используя архитектуру и инструменты, которые даёт платформа.

Омниканальность. Крайне важная история. Чтобы не разрабатывать бэк несколько раз – отдельно для мобильных приложений и отдельно, например, для веб-версии и банкоматов, нужно сделать так, чтобы API был максимально схожим для всех каналов (как минимум должна быть одинаковой структура ответа).

Мобильное приложение

Данные меняются динамически. Самые популярные операции в мобильном приложении – платёж и перевод. Реквизиты поставщиков услуг, набор полей, которые необходимо заполнить пользователю, – это динамическая информация, которая может часто меняться.

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

Лучший клиентский опыт: мы выбрали для себя основную технологию разработки мобильных приложений – разработка на нативных языках. Только так можно получить лучший клиентский опыт.

Если обобщить все эти требования – приложения должны разрабатываться на нативных языках, иметь повторно используемые компоненты внутри себя, но при этом вся бизнес-логика должна управляться со стороны сервера.

Как делать не стали

После того как мы обозначили граничные условия, расскажем, какие существующие решения мы анализировали.

Программирование на JSON

Логику проще описать императивно кодом, чем выдумывать (и изучать!) новый декларативный язык, который всегда будет ограничен сильнее, чем родной язык платформы. Кроме этого, надо предусмотреть песочницу, обработку ошибок, какой-то этап пилотирования – псевдокод должен постепенно распространяться на пользовательские устройства и при любых сбоях откатываться назад. Всё это усложняет разработку без ощутимых преимуществ.

Не используем описание стилей компонентов, поскольку они могут разниться от форм-фактора, платформы и даже режима работы (портретная/ландшафтная ориентация, responsive в web). Декларации стилей в конечной реализации всегда будут качественнее, ближе к реальности и корректнее работать с краевыми случаями. Кроме этого, бывает, что компоненты со схожей логикой принципиально по-разному работают на разных устройствах: например, ввод номера телефона – с телефонной книгой на мобильном устройстве и без неё в вебе.

Фиксация модели данных в интерфейсе приложения

Этот способ еще называется «прибить гвоздями». Смысл в том, что интерфейс приложения строится на уникальных идентификаторах объектов, которые передаются с сервера. В такой схеме любые изменения на стороне сервера приводят к переработкам клиентской части. Невозможно повторно использовать код. Сложно поддерживать.
Единственное, почему стоит выбирать такой способ на своем проекте, – уверенность на 99%, что API не будет меняться. Ну или если проект совсем небольшой и проектировать API дороже, чем быстро переделать пользовательский интерфейс под изменения в API.

Добавляем к каждому объекту признак стиля. UI приложений строим на основании этого признака. Стилей ограниченное число, поэтому появляется возможность строить интерфейс динамически. Но с увеличением функциональности UI приходится увеличивать количество стилей.
В этом варианте становится возможно управлять отображением отдельных элементов, но повышается сложность реализации связанности между разными полями. И главное – с ростом вариативности UI у вас будет постоянная необходимость расширять протокол API.

У JSON API детально описаны рекомендации по структурированию данных и описанию взаимосвязей между ними, но нет ничего, что могло бы описывать представление. Наша задача затрагивает в том числе визуальное расширение – добавление новых полей ввода, так что такой вариант нам не подходит.

Web Components / React Components API

Концепция веб-компонентов, которая в том числе значительно повлияла на API компонентов React, нам подходит уже намного лучше: с одной стороны, у нас есть контроль за отображением, с другой стороны – есть возможность привязывать данные к элементам UI.
К сожалению, всё слишком сильно завязано на HTML + CSS + JS. Напрямую не используешь, но запомним – потом пригодится.

Как решили делать

UI-контейнеры

Объекты упаковываются в контейнеры, презентационную логику приложения строим на этих контейнерах. Основное преимущество – можем группировать несколько простых объектов в один контейнер. Это дает свободу в программировании UX/UI на клиенте, например, можем управлять скрытием/отображением одного поля при заполнении данных в другом. При этом базовых типов объектов – ограниченное число, и весь бизнес-транспорт реализуется на них.

Мы выбрали именно этот подход. Сначала мы опишем протокол API, а потом – как устроены фрэймворки внутри мобильных и веб-приложений.

Чтобы было понятнее, рассмотрим API на примере простого процесса, например, перевод между своими счетами. Как добираемся до точки входа, не рассматриваем – это не процесс и для этого есть свой API (о нем мы тоже как-нибудь расскажем). Итого, процесс у нас начинается с точки входа:

Транспорт данных

Для начала договоримся об основных принципах – как передаём данные. За основу возьмём самый простой подход – пары «ключ-значение». Ключом пусть будет строка из букв латинского алфавита, значение – тоже строки, но уже произвольные.

Формы для заполнения бывают сложные, с вложенными элементами и подразделами, значит, надо допускать вложенность. Можно именовать ключи в формате camelCase, но они могут быть плохо читаемым (например, в логах) или даже «портиться» в системах, нечувствительных к регистру. Нужно ввести разделитель.

Самый очевидный разделитель – точка – во многих языках используется для доступа к свойствам объекта. При неаккуратном использовании ключи с таким разделителем будут создавать словари (или объекты), в которых возможны коллизии. Например, “foo.bar” = “foobar” и “foo.bar.baz” = “foobarbaz” в javascript может повлечь перезапись свойства “bar” объекта “foo” со строки на объект. В конце концов, договорились на двоеточии: с одной стороны, явное визуальное разделение и семантическое отражение вложенности, с другой стороны, достаточно безопасно для всех используемых языков.

Что делать с повторяемыми полями? Вводим дополнительное правило: между парой разделителей могут быть либо латинские буквы, либо цифры. Получаются конструкции вида: children:5:name:first.

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

Решение: значение – либо строка, либо список строк. Так решение выглядит типовым, но в то же время накладные расходы оказываются незначительными.

Шаг – это состояние процесса. Первый шаг у нас – выбор счета списания и счета зачисления и ввод суммы.

UI на этой картинке не видно, потому что шаг – это про серверную логику, а не про презентационную. Есть два подхода к работе с шагами: можно передавать с сервера только разницу (нарастающий итог в клиентском приложении) или каждый шаг целиком (нарастающий итог на сервере).

Анализ требований показал, что в ходе процесса экран может формироваться по-разному на разных шагах (ветвление процессов), поэтому вместо добавления управляющих команд для преобразования уже переданных сущностей проще каждый шаг передавать полностью таким, каким его должен увидеть пользователь.

Из дополнительных плюсов: при возврате к редактированию не нужно проигрывать весь сценарий или передавать дополнительный параметр “отдай всё”. При старте шага клиентское приложение сразу же получает всю нужную информацию для построения экранов.

Экраны

Экран – это разделение процесса на этапы в клиентском приложении. Как правило, экраны используются, чтобы форма была проще для восприятия. В нашем случае всё просто: один шаг – один экран.

Для экранов мы ввели два правила:

переход между экранами может быть только линейным, без ветвлений;
переход между экранами не требует взаимодействий с бэкэндом.

UI компоненты (блоки)

UI компонент – независимый компонент, который реализует клиентскую логику и наполняет документ данными. По сути, это ассоциация между управляющей командой в протоколе и куском кода и разметки в приложении. На первом экране три компонента:

Счет списания
Тот же компонент для счета зачисления
Сумма перевода

Поля – это атомарные компоненты, которые выступают транспортом для отдельных элементов данных и обрабатывают пользовательский ввод в случае деградации блока. Типов полей ограниченное число и все они поддерживаются на уровне фрэймворка: text, checkbox, select, multiselect.

Это значит, что любая версия приложения может отрисовать интерфейс, опираясь только на типы полей.

Поля в UI-компонентах из нашего примера:

1. Поле со ссылкой на справочник в счете списания и счете зачисления. Почему ссылка на статический справочник? Потому что счет мы выбираем из списка карт (счетов), без лишнего обращения к серверу.

2. Два отдельных поля для суммы и валюты в компоненте ввода суммы

Таким образом, формат для полей имеет такую структуру:

События

Так как приложения ничего не знают о процессе, логично, чтобы события (кнопки, которые видит пользователь) тоже были частью ответа от сервера.

События мы разделили на два типа.

1) Основные – они есть почти на каждом экране в привычных местах для пользователя. Как пример, это события «назад» и «продолжить». Первое осуществляет переход на шаг назад, а второе собирает заполненные данные с клиентской формы и отправляет их на сервер вместе с командой «Перейти на следующий шаг».

2) И специальные – для нестандартных действий, которые мы заранее спрогнозировать не можем, да и смысла закладывать их в часть движка нет, так как они редко используются.
В нашем случае на экране только основные события – «продолжить» и «назад». Они реализованы на уровне платформы.

У всех событий есть ряд атрибутов, такие как сам тип события, title и признак видимости. И никакого UI на сервер-сайде вроде размера кнопки, положения и цвета. Эта логика реализуется на фронте.

Справочники

Со справочниками все стандартно. Если он небольшой, то мы его присылаем полностью в ответе от сервера и называем статическим. Сделано это для того, чтобы минимизировать количество запросов к сервер-сайду и время отклика на действие пользователя в интерфейсе. Чтобы его отобразить в форме на экране, добавляем поле с типом – selectList, одно из свойств которого – ссылка на статический справочник.

Если справочник большой, то он реализуется в виде отдельного rest-сервиса. В интерфейсе это выглядит как текстовое поле, по мере заполнения которого возвращается список возможных вариантов из справочника.

Ошибки валидации на клиенте и сервере

Примерно так выглядит структура ответа:

Фрэймворки

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

Workflow engine

Движок внутри приложений (веб и мобильного) знает, что начался процесс работы с документом и что согласно протоколу ему придёт ряд атрибутов: шаги, экраны, UI-контейнеры и типы полей. На этих данных рисуется базовый интерфейс – нижнее и верхнее меню, основные кнопки, UI на простых типах полей, если они используются.

При этом движок не знает, сколько именно в сценарии будет шагов процесса, как шаги будут разбиты по экранам и какие там будут поля.

Если сценарий изменится, например, потребуется отобразить новое поле, то его будет достаточно добавить в ответ сервера, и клиентское приложение его отобразит. Для этого выпускать релиз фронтального приложения не потребуется.

Как работают UI-контейнеры?

Анализ потребностей дизайнеров и бизнес-заказчиков показал, что все потребности не получится удовлетворить простым расширением атрибутивного состава полей.

Поэтому нужны были точки расширения. Этими точками расширения стали UI-компоненты – это нативная реализация кода в самих приложениях, который идентифицируется движком по названию. По сути, это группировка поля/нескольких полей в логический блок, который может отображать кастомный UI. При этом модель данных протокола используются только для транспорта данных на бэкенд, весь UX и UI реализуется на стороне приложения.

Два режима работы фрэймворка

Когда движок парсит модель данных, он сравнивает список имен UI-контейнеров с реестром, который хранится внутри приложения. Если приложение не находит имени компоненты, то интерфейс строится на простых типах полей. Процесс будет полностью рабочим, но на стандартных UI-элементах.

Слева – как может отображаться контейнер для ввода суммы на списке из простых типов полей. Справа – если в сборке приложения есть UI-контейнер. Несмотря на то, что в режиме списка простых полей нет слайдера и есть отдельное поле вместо иконки с выбором валюты, – мы можем передать все данные с PL и процесс будет рабочим.

И тут мы получаем одно из основных преимуществ движка – доставить пользователю изменения без обновления приложения. В сборке есть маппинг имен компонентов на классы, в которых запрограммирован UI этих компонентов и пользовательский интерфейс строится на нем.

Каких правил мы стараемся придерживаться при работе с UI-компонентами:

Поддерживать работу функционала в режиме списка простых типов полей. У любого прикладного проекта есть соблазн превратить динамический протокол в статический. Поэтому мы всех просим сначала разработать функционал на типовом UI-контейнере, а потом обогащать UX/UI добавлением кастомных контейнеров на этой модели данных. Это не только позволит в будущем обновлять процессы на старых сборках, но и автоматически поддерживает логическую целостность API.
Не менять модель данных (JSON) для UI-контейнера, если он уже готов (проходит финальное тестирование или уже в продакшене). Так как логика на PL жестко связана с моделью данных, её изменение сломает функционал на версиях мобильного приложения, которые не обновляются. Тем не менее, модель можно расширять при условии сохранения обратной совместимости.
Называть свой UI-компонент системным именем. Так как имя UI-компонента – обязательный атрибут протокола и должен быть минимум один на каждом экране, мы ввели специальное системное имя, которые реализует простой список полей.
Не реализовывать бизнес-логику на UI-компонентах. Логику необходимо реализовывать на сервере, почему – писали выше.

Coming soon…

Мы очень старались писать лаконично, но это первая техническая статья про платформу Сбербанк Онлайн и она должна была многое охватить.

Пишите в комментариях, что непонятно, что интересно – постараемся писать меньше, но чаще и в цель. У нас много интересных вызовов, и поэтому много материала.

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

А есть в Сбере крупные и сложные технологические проекты, которые напрямую не видны для клиентов, но от их запуска сильно зависит успех клиентских продуктов. Сложность связана с необходимостью трансформировать приложения, которые каждую секунду обеспечивают непрерывность текущего бизнеса Сбера, а масштаб обусловлен большим количеством функционала, который востребован 68 млн клиентов. В статье я расскажу об одном из таких очень больших изменений — запуске новой платформы для СберБанк Онлайн.

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

В какой-то момент, когда Сбер ещё был Сбербанком, а технологическая трансформация только начиналась, появилась идея, что флагманское приложение СберБанк Онлайн может разрабатывать не одно подразделение, а весь банк, а впоследствии и вся Группа Сбер. А у команды, которая раньше разрабатывала это приложение самостоятельно, появилась задача создать платформу, которая построит параллельную и независимую разработку в СберБанк Онлайн.

Уточним вводные, с которыми предстояло работать:

продуктовых команд будет много (несколько сотен — в ближайшей перспективе и тысячи — в перспективе). Размер одной команды — около 10 человек, возможность разрабатывать функционал end-to-end;

T2M по бизнес-функционалу — 2‒3 недели. Разумеется, срочные фиксы должны выходить на клиентов в течение часов;

приложения должны иметь лучший клиентский опыт и высокие оценки в App Store и Google Play;

текущий сервер-сайд и фронтальные приложения — монолиты с многолетней историей;

менять колёса надо на ускоряющемся ходу. Пользователей уже перевалило за 45 млн, нагрузка каждый день растёт. Речь и о количестве TPS, и о количестве новых фич, которые нужны бизнесу;

большинство операций — банковские. Это к тому, что платёжные транзакции, в отличие от, например, развлекательного контента, нельзя терять ни в коем случае. А если мы не отразим корректный остаток по картам в момент входа, сразу положим контакт-центры высоким количеством обращений клиентов;

надёжность и безопасность — высшие приоритеты.

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

Когда мы говорим «сервер-сайд приложений СберБанк Онлайн», имеем в виду именно мидл-слой, который отвечает за следующий функционал:

бизнес-приложения (прикладные), которые реализуют конечный функционал для пользователей приложений;

аутентификацию пользователя в приложении;

наполнение распределённого кэша в памяти серверов приложений при установке клиентской сессии, который обеспечивает доступность, низкое время отклика и надёжность при большом количестве запросов от приложений;

общие страницы приложения (главный экран, история операций и т. д.);

логирование, мониторинг, авторизацию и другой функционал для надёжности и безопасности.

Список на этом не заканчивается, но должен дать общее представление. Явно ещё раз подчеркну, что бэкенд не входил в объём поставленной задачи.

Зачем новая платформа

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

Достичь низкой связанности можно было двумя способами. Первый — глубокий рефакторинг текущего Legacy с целью разделить прикладной и платформенный функционалы на отдельные компоненты, которые взаимодействуют по зафиксированным контрактам. И второй — создание платформы с нуля с последующей миграцией прикладного функционала и пользователей. По совокупности причин выбрали второй вариант.

Ключевые моменты

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

Разделили сервисы на две группы — платформенные и прикладные

Как бы мы ни старались делать микросервисы максимально независимыми, всегда будут те, от которых зависят все. Появляются общие сервисы из-за необходимости централизованного управления платформой. Например, логирование у нас общее, потому что логи зачастую собираются в результате проблемы клиента, а не отдельного сервиса

Для таких сервисов невозможно обеспечить T2M в пару недель, потому что все пользуются логированием, и, если мы не протестируем потребителей во время нового релиза, есть риск потерять в качестве.

Поэтому платформенные и прикладные сервисы мы условно разделили по количеству зависимостей. Если от сервиса зависит множество других, то мы помещаем его в платформенный слой. Если от сервиса не зависят другие сервисы, то мы помещаем его в прикладной. При этом стараемся минимизировать количество зависимостей, а, следовательно, и количество платформенных сервисов.

Почему мы акцентируем внимание на количестве связей? Если грубо, то каждая зависимость — это дополнительный тестовый кейс или несколько кейсов. Кроме того, при росте количества связей мы получаем высокую спутанность и, как следствие, циклические зависимости. И неутешительные сроки по исправлению дефектов. Всё это напрямую влияет на T2M.

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

В нашем случае получилось порядка 40 платформенных и около 10 пилотных бизнес-сервисов на старте. На данный момент количество платформенных сервисов почти не изменилось, а число прикладных проектов превысило 250.

Создали отдельные релизные процессы

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

Если мы начнём тестирование и платформы, и прикладных сервисов на одном общем стенде, то длительный процесс отладки платформенного сервиса приведёт к такому же времени отладки прикладных сервисов + времени на их собственное тестирование. Поэтому мы выделили отдельные тестовые контуры для платформы и прикладов.

Так как основных слоя два, то и контуров достаточно двух. На платформенном контуре производится сборка и отладка платформенного релиза. В зависимости от зрелости инструментов DevOps и процессов производства, на контуре может быть разное количество стендов. Но главное, чтобы в итоге мы получили стабильную версию платформы.

После этого её можно передавать на контур с бизнес-потребителями, где они производят тестирование в своём быстром релизном цикле.

Ввели контроль платформенного API

Понятная вещь, о которой все говорят, но которая не всегда случается. Обязательные правила, которые мы применили:

на старте проекта попросили всех владельцев платформенных сервисов опубликовать свои контракты как можно раньше, ещё до того, как началась разработка. После чего они не должны были меняться. Здесь многое упирается в профессионализм людей, которые проектируют API. Мы доверили это самым опытным сотрудникам внутри команд, отвечающих за разработку сервисов;

создали инструмент, который осуществляет контроль этого API. У нас для этого есть отдельный компонент — синтетическое приложение. О нём чуть позже;

сделали процесс согласования изменения API максимально дорогим:

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

согласование со всеми потребителями API;

согласование с руководителями. Инициатор изменений должен был получить ОК от двух ключевых людей — владельца СберБанк Онлайн и руководителя программы внедрения новой платформы. Да, им лично приходилось объяснять, почему API всё-таки нужно поменять и как так случилось, что делать это нужно после того, как началась разработка. И да, такие кейсы были, но штучные. По сравнению с потоком изменений, которые были до введения контроля, — ничтожное количество.

Важно отметить, что мы строго контролируем API в рамках минорных релизов платформы и не строго (изменения возможны, но согласуются с архитектурой) — в рамках мажорных релизов.

Следим за удобством разработки на платформе

Случается так, что платформу сделали, а пользоваться ей неудобно. Вроде как клиент платформы — внутренний, поэтому может потерпеть. Это большая ошибка, особенно когда потребителей платформы много. И мы создали независимый орган, который следит за клиентским опытом потребителей платформы и отстаивает их интересы — «Синтетическое приложение».

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

выпуск POM/BOM. Большая часть платформенного API предоставляется в виде клиентских библиотек. Ребята из «Синтетического приложения» собирают их вместе, разрешают конфликты зависимостей и публикуют для потребителей POM- и BOM-файлы;

контроль обратной совместимости API. Кроме проверки на конфликт зависимостей, все библиотеки проходят тестирование на бинарную совместимость с предыдущими версиями;

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

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

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

сообщество разработчиков. Разработка на платформе становится легче и результативнее, если есть инструменты прямого взаимодействия с её разработчиками и можно пообщаться с коллегами, которые раньше вас пришли на платформу. У нас основным инструментом такого взаимодействия выступает сообщество разработчиков. У них есть чаты, где они могут задать любые вопросы по разработке на платформе, митапы и воркшопы, на которых можно получить новые и обменяться своими знаниями. Основная польза от этой истории для прикладного разработчика — помощь сообщества. Главная польза для ребят из платформы — прямое взаимодействие со своими потребителями.

Архитектурный контроль

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

Где мы сейчас и что делаем дальше

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

Мы существенно сократили T2M для прикладных проектов относительно Legacy, где релизный процесс предполагал включение в релиз за шесть месяцев до полной раскатки. Точные цифры назвать сложно, так как они зависят от доработок смежных систем, но мы уменьшили время от подачи заявки в релиз до прома до трёх недель.

Тем не менее мы ещё в начале пути и ещё много задач, которые предстоит решить:

миграция профиля и сессии. Мы обеспечили запуск проектов, но Legacy продолжает оставаться источником основных данных по профилю клиента. В отличие от запуска атомарных клиентских сценариев, это то, что нельзя разработать рядом и потом плавно переключиться. Приходится много дорабатывать одновременно: и Legacy, и новое приложение. Всё это — под огромной пользовательской нагрузкой. Весьма сложная история, достойная отдельной статьи;

нормальный технологический стек и удобство разработки. Если вы обратили внимание, в цели проекта не входило внедрение нового стека. Даже больше: мы сознательно от него отказались. Основной аргумент — не увеличивать сложность на и так сложном проекте. Если смена стека с точки зрения разработки несёт приемлемые риски, то с точки зрения эксплуатации и внедрения риски очень высокие. Так как надёжность, доступность и безопасность — самые важные критерии, которым мы следуем при любой разработке в СберБанк Онлайн, то и требования к инфраструктуре и эксплуатации очень высокие. Поэтому смена стека в run-time требует большой аккуратности, что неизбежно сказалось бы на сроках.

Так что наши разработчики счастливо программируют на Java 8. А деплоится это всё на вендорском JDK. Многие, кто слышит об этом на наших собеседованиях, расплываются в улыбке от счастья. Или не от счастья, мы точно не знаем. Если серьёзно, то это надо менять, и одна из текущих задач на платформе сейчас — смена стека. А для прикладных команд мы обсуждаем возможность разработки на Kotlin.

Кроме того, на платформе много специфики этой платформы. Это тоже нехорошо, так как создаёт высокий порог вхождения для новых разработчиков и способствует изоляции от внешнего мира тех, кто давно на проекте. У нас есть трек активностей, направленных на то, чтобы изменить это в лучшую сторону.

Автор статьи

Куприянов Денис Юрьевич

Юрист частного права

Страница автора

Читайте также: