Вероятно, в последнее время вы много слышали о новых продуктах Сбера и со многими из них сталкивались в качестве клиентов.
У Сбера также есть большие и сложные технологические проекты, которые не видны клиентам напрямую, но от их запуска во многом зависит успех клиентских продуктов.
Сложность связана с необходимостью трансформировать приложения, которые ежесекундно обеспечивают непрерывность текущего бизнеса Сбера, а масштаб – с большим количеством функционала, который востребован 68 млн клиентов.
В этой статье я расскажу об одном из таких очень больших изменений – запуске новой платформы СберБанк Онлайн.
Это вводный текст о новой платформе, поэтому мы не будем углубляться в практические детали, а попытаемся дать общее представление.
В какой-то момент, когда Сбер еще был Сбербанком, а технологическая трансформация только начиналась, возникла идея, что флагманское приложение «СберБанк Онлайн» может разрабатываться не одним подразделением, а всем банком, а впоследствии и всей Группой Сбер.
И перед командой, которая ранее самостоятельно разрабатывала это приложение, теперь стоит задача создать платформу, которая будет строить параллельную и независимую разработку в СберБанке Онлайн.
Давайте уточним входные данные, с которыми нам пришлось работать:
- Будет много продуктовых команд (несколько сотен в ближайшем будущем и тысяч в будущем).
Размер одной команды около 10 человек, возможность разработки сквозного функционала;
- T2M для бизнес-функционала – 2‒3 недели.
Конечно, срочные исправления должны быть доставлены клиентам в течение нескольких часов;
- приложения должны иметь лучший клиентский опыт и высокие рейтинги в App Store и Google Play;
- текущие серверные и интерфейсные приложения представляют собой монолиты с долгой историей;
- Менять колеса нужно с ускоряющейся скоростью.
Число пользователей уже превысило 45 миллионов, а нагрузка растёт с каждым днём.
Мы говорим о количестве TPS и количестве новых функций, которые нужны бизнесу;
- Большинство транзакций являются банковскими.
Это означает, что платежные транзакции, в отличие, например, от развлекательного контента, не могут быть потеряны ни при каких обстоятельствах.
И если мы не отразим правильный баланс карты на момент входа, мы сразу же разместим большое количество обращений клиентов в контакт-центры;
- Надежность и безопасность являются высшими приоритетами.
Как правило, серверную часть в крупной организации можно разделить на два основных уровня — средний, обеспечивающий надежность, доступность и хороший UX клиентских приложений, и бэкэнд, хранящий и обрабатывающий основные данные для разных систем (например , карточный процессинг, депозиты или «Кредитная фабрика»).
Когда мы говорим «серверная часть приложений СберБанк Онлайн», мы имеем в виду средний уровень, отвечающий за следующий функционал:
- бизнес-приложения (приложения), реализующие конечный функционал для пользователей приложения;
- аутентификация пользователя в приложении;
- заполнение распределенного кэша в памяти серверов приложений при настройке клиентской сессии, что обеспечивает доступность, малое время отклика и надежность при большом количестве запросов от приложений;
- общие страницы приложения (главный экран, история транзакций и т. д.);
- регистрация, мониторинг, авторизация и другие функции для надежности и безопасности.
Еще раз четко подчеркну, что бэкенд не входил в объем задачи.
Почему новая платформа
СберБанк Онлайн недавно отметил свое десятилетие, и на протяжении всей этой истории монолит служил средним слоем.Надо отдать должное, активный этап роста пользовательской и функциональной нагрузки он пережил достойно.
Но он все время разрастался и по большей части состоял из тесно связанного кода, где функциональность приложения была тесно переплетена с тем, что обеспечивало надежность и доступность.
Поэтому продолжать повышать интенсивность разработки при сокращении Т2М не представлялось возможным.
Очевидным решением является уменьшение связанности кода, чтобы он проходил все этапы производства без сильного влияния одной функциональности на другую.
Низкая связанность может быть достигнута двумя способами.
Первый — это глубокий рефакторинг текущего Legacy с целью разделения функционала приложения и платформы на отдельные компоненты, взаимодействующие по фиксированным контрактам.
И второе — создание платформы с нуля с последующей миграцией функционала приложения и пользователей.
По совокупности причин мы выбрали второй вариант.
Ключевые моменты
Итак, мы примерно определились, зачем делаем новую платформу, дальше самое главное добиться результата.И опыт подсказывал, что добиться этого в таких масштабах непросто.
Поэтому мы заранее спланировали ключевые моменты, на которых нам в первую очередь необходимо сосредоточиться.
Сервисы были разделены на две группы — платформы и приложения.
Как бы мы ни старались сделать микросервисы максимально независимыми, всегда найдутся те, от которых зависят все.
Общие сервисы появляются из-за необходимости централизованного управления платформой.
Например, у нас общее логирование, потому что логи часто собираются в результате проблемы клиента, а не отдельного сервиса.
Для таких сервисов невозможно обеспечить Т2М за пару недель, потому что все используют логирование, и если мы не протестируем потребителей во время нового релиза, есть риск потери качества.
Поэтому мы разделили сервисы платформы и приложения по количеству зависимостей.
Если от сервиса зависит множество других, мы помещаем его на уровень платформы.
Если от сервиса не зависят другие сервисы, то размещаем его в прикладном.
При этом мы стараемся минимизировать количество зависимостей, а, следовательно, и количество сервисов платформы.
Почему мы акцентируем внимание на количестве связей? Грубо говоря, каждая зависимость — это дополнительный тест-кейс или несколько кейсов.
Кроме того, по мере увеличения количества связей мы получаем высокую путаницу и, как следствие, циклические зависимости.
И неутешительные сроки исправления дефектов.
Все это напрямую влияет на Т2М.
Таким образом, мы имеем горизонтальные связи внутри одного слоя и вертикальные связи между слоями.
На уровне платформы мы разрешаем горизонтальные зависимости, на уровне приложения стараемся их избегать (исключения возможны, но это исключения, и мы за этим следим).
В нашем случае на старте мы получили около 40 платформ и около 10 пилотных бизнес-сервисов.
На данный момент количество сервисов платформы осталось практически неизменным, а количество проектов приложений превысило 250.
Созданы отдельные процессы выпуска
Платформа и сервисы приложений отвечают различным требованиям и свойствам.
Платформа – максимальная стабильность и отказоустойчивость.
На основе приложений — лучший клиентский опыт, минимальное влияние на другие сервисы и максимальная скорость разработки.
Если мы начнем тестировать и платформу, и сервисы приложений на одном общем стенде, то длительный процесс отладки сервиса платформы приведет к одинаковым затратам времени на отладку сервисов приложений + время на их собственное тестирование.
Поэтому мы выделили отдельные тестовые схемы для платформы и акций.
Так как основных слоев два, то и двух контуров вполне достаточно.
На схеме платформы собирается и отлаживается выпуск платформы.
В зависимости от зрелости инструментов DevOps и производственных процессов на схеме может быть разное количество стендов.
Но главное, что в итоге мы получим стабильную версию платформы.
После этого его можно передать в цикл работы с бизнес-потребителями, где они проводят тестирование в рамках цикла быстрого выпуска.
Представлено управление API платформы
Понятное дело, о котором все говорят, но которое не всегда происходит. Обязательные правила, которые мы применили:- на старте проекта мы просили всех владельцев платформенных сервисов публиковать свои контракты как можно раньше, еще до начала разработки.
После чего они не должны были измениться.
Здесь многое зависит от профессионализма людей, проектирующих API. Мы доверили это самым опытным сотрудникам команд, отвечающих за разработку сервисов;
- создал инструмент, который отслеживает этот API. У нас для этого есть отдельный компонент — синтетическое приложение.
Подробнее о нем позже;
- сделали процесс одобрения изменения API максимально дорогим:
- согласование изменений с архитектурой платформы;
- соглашение со всеми потребителями API;
- согласование с менеджерами.
Инициатор изменений должен был получить добро от двух ключевых людей — владельца «СберБанк Онлайн» и руководителя программы внедрения новой платформы.
Да, им лично пришлось объяснять, почему API всё-таки нужно изменить и как так получилось, что это нужно сделать уже после начала разработки.
И да, такие случаи были, но они были разрозненными.
По сравнению с потоком изменений, существовавшим до введения контроля, объем незначителен.
Следим за легкостью разработки на платформе
Бывает, что платформа сделана, но ею неудобно пользоваться.Вроде клиент платформы внутренний, так что можно потерпеть.
Это большая ошибка, особенно когда пользователей платформы много.
И мы создали независимый орган, который следит за клиентским опытом потребителей платформы и защищает их интересы — «Синтетическое приложение».
Эта команда играет ключевую роль — она собирает отдельные сервисы платформы в единый продукт. У ребят много задач:
- выпуск POM/BOM. Большая часть API платформы предоставляется в виде клиентских библиотек.
Ребята из Synthetic App объединяют их, разрешают конфликты зависимостей и публикуют файлы POM и BOM для потребителей;
- Контроль обратной совместимости API. Помимо проверки на конфликты зависимостей, все библиотеки проверяются на бинарную совместимость с предыдущими версиями;
- тестирование платформы в качестве бизнес-потребителя.
После того как каждый компонент платформы прошел тестирование, важно убедиться, что собранная конфигурация платформы стабильна.
Вы можете сделать это с помощью бизнес-потребителя.
Но тогда бизнес-проект будет нести все риски по отладке дефектов платформы.
Более того, один бизнес-проект может не выявить проблемы, характерные для другого.
Поэтому мы делаем это с помощью специального приложения, которое похоже на настоящее бизнес-приложение, но содержит максимальное количество вариантов использования сервисов платформы и покрыто кучей тестов.
Таким образом, бизнес-потребители уже приходят на стабильную версию платформы, и риски ребилдов из-за дефектов платформы значительно меньше;
- контроль над документацией.
Идеальный сервис не нуждается в документации.
Но услуги не идеальны.
Кроме того, как бы вы ни старались сделать компоненты платформы универсальными, требования клиентов будут различаться.
Эти различия можно компенсировать опциями конфигурации, которые также необходимо документировать и описывать.
Опять же, если сервисов платформы много и в продакшене уже есть несколько версий платформы, то даже навигация по документации становится сложной задачей;
- CSI и обратная связь.
Продукт не может быть хорошим, если нет механизма обратной связи с клиентом.
Мы проводим регулярные оценки CSI и сеансы обратной связи с потребителями платформы.
После этого мы отправляем обратную связь командам разработчиков сервисов платформы и следим за тем, чтобы «боли» клиентов не остались незамеченными;
- сообщество разработчиков.
Разработка на платформе становится проще и эффективнее, если есть инструменты прямого взаимодействия с ее разработчиками и вы можете общаться с коллегами, пришедшими на платформу до вас.
Наш главный инструмент такого взаимодействия — сообщество разработчиков.
У них есть чаты, где можно задать любые вопросы о разработке на платформе, митапы и мастер-классы, где можно узнать что-то новое и поделиться своими знаниями.
Основная польза этой истории для разработчика приложений — помощь сообщества.
Основная польза для ребят от платформы — прямое взаимодействие со своими потребителями.
Архитектурный контроль
Для всех сервисов приложений мы ввели требование пройти проверку архитектуры.Основная цель данного обзора — исключить влияние прикладной составляющей на другие и на платформу в целом.
Ошибка в проектировании сервиса приложения может привести к тому, что повышенная нагрузка на один из сервисов платформы сделает недоступной всю платформу, а, следовательно, и весь СберБанк Онлайн.
Кроме того, во время проверки архитектуры мы отслеживаем горизонтальные вызовы между службами приложений.
Где мы сейчас находимся и что будем делать дальше?
Платформа была представлена около двух лет назад, и сейчас можно с уверенностью сказать, что она успешно решила основные задачи, которые перед ней ставились.
На данный момент у нас более 250 проектов, число которых постоянно растёт. 
Мы значительно сократили T2M для проектов приложений по сравнению с Legacy, где процесс выпуска включал в себя включение в выпуск за шесть месяцев до полного развертывания.
Точные цифры назвать сложно, так как они зависят от доработок сопутствующих систем, но мы сократили время от подачи заявки на выпуск в производство до трёх недель.
Тем не менее, мы еще в начале пути и впереди еще много задач:
- миграция профиля и сеанса.
Мы добились запуска проектов, но Legacy продолжает оставаться источником ключевых данных о профилях клиентов.
В отличие от запуска атомарных клиентских сценариев, это то, что вы не можете разрабатывать параллельно, а затем плавно переключаться.
Нам предстоит многое дорабатывать одновременно: и Legacy, и новое приложение.
Все это находится под огромной пользовательской нагрузкой.
Очень сложная история, достойная отдельной статьи;
- нормальный стек технологий и простота разработки.
Если вы заметили, в цели проекта не входило введение нового стека.
Более того: мы сознательно от него отказались.
Главный аргумент — не усложнять и без того сложный проект. Если изменение стека с точки зрения разработки несет в себе приемлемые риски, то с точки зрения эксплуатации и реализации риски очень высоки.
Поскольку надежность, доступность и безопасность — важнейшие критерии, которыми мы руководствуемся при любом развитии в СберБанк Онлайн, требования к инфраструктуре и эксплуатации очень высоки.
Поэтому изменение стека во время выполнения требует большой осторожности, что неизбежно скажется на сроках.
Многие, кто слышат об этом на наших интервью, расплываются в счастливой улыбке.
Или не от счастья, мы точно не знаем.
Серьезно, это необходимо изменить, и одна из текущих задач платформы сейчас — изменение стека.
А для команд приложений обсуждаем возможность разработки на Kotlin. Кроме того, существует множество специфических особенностей платформы.
Это тоже нехорошо, так как создает высокий барьер входа для новых разработчиков и способствует изоляции от внешнего мира тех, кто уже давно на проекте.
У нас есть трек мероприятий, направленных на то, чтобы изменить это к лучшему.
Спасибо за внимание, жду ваших вопросов в комментариях.
Теги: #Микросервисы #Сбербанк Онлайн #Платформа разработки
-
Охлаждение
19 Oct, 24 -
Apple Macbook – Обновление Линейки...
19 Oct, 24 -
Опенфлоу В Москве
19 Oct, 24 -
Просыпайся Правильно
19 Oct, 24
