Дрпа сбербанк что это
Обновлено: 24.04.2024
Платформа поддержки развития бизнеса (ППРБ) Сбербанка объединяет в себе процессы миддл- и бэк-офиса банка, создавая технологические компоненты и продуктовые фабрики для оказания услуг клиентам. Эта платформа является одной из ключевых и стратегических в ИТ-инфраструктуре Сбербанка.
2018: Результаты разработки
В 2018 году были обеспечены надежность и производительность платформы поддержки развития бизнеса (ППРБ), подтверждены контракты 100% приоритетных компонентов, необходимых для начала тиража продуктовых фабрик на внешних клиентов, сообщил Сбербанк отчете о своей деятельности за 2 квартал 2019 года.
Также в 2018 году были реализованы механизмы переключения платформы на работу в режиме Stand-In и Stand-In прикладных фабрик, позволяющие в случае инцидентов продолжать работу без прерывания клиентского сервиса.
Фронтальные системы всех 14 тысяч офисов банка стали работать с единым профилем клиента. Был существенно расширен перечень продуктов, подключенных к ППРБ в тестовом режиме, в том числе переводы физическим лицам, услуги эквайринга, зарплатные проекты, депозиты и конверсионные операции юридических лиц. Помимо этого, в 2018 году был начат масштабный тираж бизнес-функциональности.
Цели проекта
Старший управляющий директор Сбербанка Михаил Хасин, выступая на конференции TAdviser SummIT 31 мая 2016 года, рассказал о программе создания «Платформы поддержки развития бизнеса» (ППРБ). Она предусматривает революционную трансформацию всех приложений, входящих в контур Core Banking. В разработке применяются новейшие технологии распределенных вычислений в памяти и работы приложений с большими объемами данных в реальном времени – In-Memory Data Grid.
Цели реинжиниринга платформы, который Сбербанк рассчитывает завершить в 2018 году, - сокращение сроков вывода новых продуктов на рынок, сокращение совокупной стоимости владения автоматизированной банковской системы, повышение уровня автоматической обработки транзакций. Тиражировать новую платформу планируется на всю группу Сбербанка.
Основными предпосылками к реинжинирингу банковской платформы Михаил Хасин назвал развитие цифровых каналов связи и рост числа мобильных устройств. Последние становятся окном в мир, говорит он: клиенты хотят получать через них всевозможные услуги, в том числе и финансовые. Это заставляет банки меняться - от модели бизнеса, отталкивающейся от продуктов, переходить к модели, в центре которой потребности клиентов, а также создает для них новые технологические вызовы.
Один из ключевых вызовов для банков - огромный рост объема транзакций в пиковые нагрузки, отметил Хасин. По оценкам, которые он привел, за последние 10 лет объем транзакций у Сбербанка вырос практически в 100 раз. Отсюда вытекают и новые требования к банковским платформам, в числе которых - практически неограниченная масштабируемость, 100% доступность систем, быстрый и гибкий вывод новых продуктов на рынок.
В традиционной ИТ-архитектуре реализовывать столь высокую клиентоцентричную функциональность стоит очень дорого и занимает много времени: «Крупнейшие банки мира осознали, что если не делать принципиально нового реинжиниринга, то очень быстро их рыночная доля будет снижаться». Совершить технологический скачок позволяют технологии in-memory computing, предназначенные для распределенных вычислений на большом количестве оборудования и позволяющие работать с данными в памяти. Они позволяют обеспечить новый уровень производительности, масштабируемости, отказоустойчивости, говорит Михаил Хасин.
Реинжиниринг собственной платформы в соответствии с новыми вызовами Сбербанк планирует завершить в 2018 году. Ее целевая архитектура включает 4 слоя. Первый – это слой универсальной мультиканальной бизнес-логики, говорит Хасин. Это окно, с которым сталкивается клиент и которое позволяет выводить новую функциональность во все каналы банка – офисы, мобильный банк, контактный центр и в партнерский канал.
Второй, ключевой слой – бизнес-хаб – содержит единый профиль клиента, его данные и всю бизнес-логику работы с клиентом, с его продуктами и пакетами тарификации. Третий слой состоит из продуктовых фабрик, которые представляют собой масштабируемые движки, обрабатывающие транзакции. В их числе – фабрики по кредитам, вкладам, переводам и др. Последний слой – фабрика данных, включающая неструктурированные данные из различных источников, которые банк анализирует и использует для более эффективного предложения клиенту.
Такая архитектура дает возможность предоставлять абсолютно новые виды и сценарии обслуживания, отметил Хасин. В качестве примера он привел случай, когда человек в Twitter рассказал о желании поехать в Мексику. Эта информация из соцсети попадает в фабрику данных, вся информация, которая есть об этом клиенте у Сбербанка, поднимается в in-memory в клиентский профиль, анализируется наличие контактных данных клиента, после чего он, например, получает СМС или e-mail о том, что может взять кредит, купить турпутевку у компании-партнера и расположение ближайшего отделения Сбербанка, где это можно сделать.
Подобные сценарии начинают все больше развиваться и усложняться, и для того, чтобы их реализовывать, в бизнес-хаб встраиваются различные механизмы машинного обучения, позволяющие ему впоследствии вырабатывать персональные предложения для клиентов.
Любая платформа нового поколения, по мнению Хасина, должна иметь открытый API, поскольку банки развивают так называемые маркетплейсы или агрегаторы, когда вместе со своими партнерами начинают продавать не только финансовые, но и смежные услуги, такие как путешествия и страховки. Это особенно актуально в связи с тем, что экосистема банков разрастается и есть много желающих писать собственные приложения, связанные с банковскими сервисами.
О TAdviser SummIT
TAdviser SummIT, прошедший 31 мая 2016 года, посетили более 240 человек – руководителей и экспертов коммерческих и государственных организаций. В рамках мероприятия было представлено более 30 докладов. В числе докладчиков – представители Минкомсвязи, «Сбербанка», Пенсионного фонда, Федерального казначейства, «Вертолеты России» и др. В фойе саммита прошла выставка ИТ-компаний. В завершении мероприятия состоялся розыгрыш смартфона Tonino Lamborghini 88 Tauri стоимостью около 200 тыс. рублей.
В этой статье мы расскажем о библиотеке компонентов Единой фронтальной системы (ЕФС) и как в целом устроен фронтенд платформы.
Одной из основных задач программы ЕФС является трансформация всех фронтальных систем к единому технологическому стеку. Фронтальная система в нашем контексте это интерфейс, через который любой пользователь взаимодействует с банком. Это может быть интернет-банк — многим известны приложения Сбербанк Онлайн и Сбербанк Онлайн для бизнеса, — банкоматы, терминалы, интерфейсы операторов в отделениях и call-центрах и другие системы, которыми пользуются многие тысячи клиентов и сотрудников банка в России.
Основная проблема, которую мы решаем, это замена устаревшего кода: фронтальных систем в банке много, у каждого своя архитектура, свой дизайн.
Очевидно, что это неудобно для всех: для клиентов, сотрудников и банка в целом.
Поэтому главная миссия фронтенда ЕФС – заменить существующую сборную солянку и привести все к единой кодовой базе, к единому технологическому стеку с удобным и понятным пользовательским сценарием.
Какие задачи стоят перед разработкой?
-
Надежность и безопасность, ведь мы говорим о банковском ПО.
Как устроен фронтенд в ЕФС?
У нас есть команда разработчиков платформы ЕФС, а также прикладные разработчики, задача которых – реализовать бизнес-логику.
В качестве инструментария мы используем набор инструментов от компании Atlassian: JIRA для постановки задач, BitBucket для git-репозиториев и Confluence для документации.
Из чего состоит библиотека?
-
Различные UI-элементы: всевозможные селекты, кнопки, большой набор полей с различными типами данных, чекбоксы, радиокнопки и другие элементы формы, с которыми взаимодействует пользователь.
Поддержка браузеров
Целевыми браузерами являются IE8+. Сейчас IE8, если кто-то помнит, это как в свое время был IE6: ужасное API и ужасная отладка. Конечно, время, проведенное за дебагом в IE8, бесценно. Были случаи, когда разработчики проводили несколько дней в попытках найти, в каком месте возникала ошибка, потому что в IE8 очень скудный инструментарий для дебага и он показывает порой, что ошибка возникла совсем в другом месте.
Поддержка IE не случайна, нам приходится работать с железом из браузера: RFID-таблетки, различные принтеры, сканеры и т.д. В вебе нет единого стандарта по работе с железом: в далеком прошлом технологией для работы с ним был выбран ActiveX. Количество ПО, написанного с использованием ActiveX, колоссально, и это не дает нам в одночасье отказаться от поддержки IE и перейти в сторону современных браузеров. В планах — перевод устаревшего ActiveX на Java-апплеты и отказ от IE8.
Стек технологий
Мы своего рода стартап внутри крупной организации и наш стек технологий фронтенда не сильно отличается от большинства мировых стартапов: react, redux и PostCSS. Все эти технологии зарекомендовали себя с лучшей стороны, к тому же, они позволяют нам поддерживать IE8. Однако, мы не можем резко менять стек технологий, т.к. вокруг него завязана определенная архитектура приложений, например, именно React позволил нам разбить одно огромное приложение на сотни маленьких и подгружать их по требованию, используя SystemJS.
React
Это первая технология, которую мы выбрали по следующим причинам:
-
Позволяет разбить приложение на компоненты, тем самым организовав компонентный подход к разработке.
Как мы подружили React и IE8 ?
Во-первых, мы не обновляем версию React, потому что с какого-то момента они тоже отказались от поддержки IE8. Во-вторых, мы используем es3ify — это loader для webpack, который берет наш ES5 код и перегоняет в ES3. Он просто заменяет некоторые вещи, которые в IE8 не работают.
TypeScript
Второй технологией, которую мы выбрали, был TypeScript, вот почему:
-
Строгая типизация
По нашим стандартам тип any запрещен, однако, бывают исключения из правил, т.к. далеко не всё можно покрыть generic’ами.
Производительность
Во-первых, мы сделали компоненты «глупыми», то есть избавились от state, вынося его на прикладной уровень. Теперь прикладные разработчики решают, как менять state, а в наши компоненты только пробрасываются нужные props.
Есть библиотечный компонент Input, у него в state хранится value, в render он возвращает input и в onChange он меняет state. Не много ли кода для такого компонента? Однозначно много, давайте отрефакторим этот пример:
Код компонента стал короче, а на уровне выше есть компонент Form, который сам решает, как управлять состоянием компонента: через redux или через простейший setState. Input стал проще, и, соответственно, производительнее.
Второе, мы придерживаемся архитектуры чистых компонентов (PureComponent), т.е. все внешние свойства, внутренний state и контекст проходят проверку соответствия предыдущему состояния. Если состояние не изменилось, то нет смысла вызывать render лишний раз. Эту проверку мы осуществляем в методе shouldComponentUpdate, который добавили во все наши компоненты.
И третье, мы избавились от утечек памяти в коллбеках.
В данном примере у компонента есть коллбек onClick и в него передается стрелочная функция.
Если ее так задать, то здесь возникает утечка. В IE8 ее особенно видно, потому что при каждом повторном вызове render эта функция создается, она накапливается и возникают тормоза в компоненте. Немного изменим наш пример:
Сам код стал лаконичнее и к тому же, мы избавились от утечки, поскольку callback-функция больше не создается при каждом вызове render.
В планах на будущее — прекращение поддержки IЕ8, что позволит использовать более прогрессивные фронтенд-технологии. Кроме того, мы уже приступили к работе над масштабным проектом интеграции с мобильной платформой ЕФС, приступили к разработке гибридной библиотеки, позволяющая один и тот же код использовать и для web, и для мобильных устройств, используя React Native.
В следующий статье про фронтенд программы ЕФС мы расскажем про то, как мы используем Redux и как он стал сердцем нашей архитектуры, подписывайтесь на наш блог, чтобы не пропустить!
Идеи, предложения и пожелания – пишите, будем рады пообщаться с вами в комментариях к статье.
Вы, наверное, в последнее время часто слышите о новых продуктах Сбера, со многими из них сталкиваетесь как клиенты.
А есть в Сбере крупные и сложные технологические проекты, которые напрямую не видны для клиентов, но от их запуска сильно зависит успех клиентских продуктов. Сложность связана с необходимостью трансформировать приложения, которые каждую секунду обеспечивают непрерывность текущего бизнеса Сбера, а масштаб обусловлен большим количеством функционала, который востребован 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.
Кроме того, на платформе много специфики этой платформы. Это тоже нехорошо, так как создаёт высокий порог вхождения для новых разработчиков и способствует изоляции от внешнего мира тех, кто давно на проекте. У нас есть трек активностей, направленных на то, чтобы изменить это в лучшую сторону.
Платформа по работе с данными Сбера Sber Data Platform
Краткое описание платформы работы с данными
В состав платформы работы с данными Sber Data Platform входят следующие сервисы:
-
- сервисы загрузки и преобразования данных - сервисы работы с большими данными - сервисы анализа данных
Использование Sber Data Platform (SDP) позволяет упростить развертывание и настройку сервисов работы с данными, а также сократить время на создание решений для работы с большими данными.
Также, с Платформой интегрируется продукт «Система контроля качества данных SDP Data Quality»
Подробнее
SDP DataFlow
SDP DataFlow - сервисы для задач загрузки и трансформации данных (ETL – Extract, Transform, Load), в том числе Apache AirFlow, Apache NiFi, что позволяет использовать сервисы SDP Sandbox для различных сценариев извлечения, преобразования, загрузки, хранения, обработки и анализа больших данных.
SDP Hadoop
В состав Sber Data Platform входит сервис SDP Hadoop. Это проверенный и надёжный дистрибутив компонентов из экосистемы Apache Hadoop, который решает различные задачи в области обработки, хранения и анализа данных. SDP Hadoop интегрирован c другими сервисами SDP, что позволяет аналитикам и инженерам данных удобно переносить и обрабатывать большие объемы данных. SDP Hadoop использует лучшие технологии для защиты и надёжности хранения данных, при этом позволяет гибко использовать ресурсы и масштабируется в соответствии с потребностями.
На платформе Единой фронтальной системы (ЕФС) разрабатываются фронтальные процессы для системы «Сбербанк Онлайн» (мобильное приложение и веб-версия), а также для сотрудников отделений, специалистов по прямым продажам первого уровня. Программа по разработке этой системы является одной из ключевых и стратегических для Сбербанка.
2020: Запуск единого рабочего места операторов на базе ЕФС
26 февраля 2020 года «Сбербанк» сообщил TAdviser о запуске тиража собственной разработки — единого рабочего места (ЕРМ) операторов первых линий, обслуживающих корпоративных клиентов. Запуск ЕРМ планируется на 1 марта 2020 года.
Опытная эксплуатация разработки показала, что благодаря ей экономится 17–20 секунд (примерно 6%) среднего времени обработки контакта. В месяц это 2900 часов.
На 26 февраля 2020 года идут подготовительные работы по организации тиража и обучению операторов — пользователей ЕРМ. Увеличение численности операторов будет происходить планомерно.
Единое рабочее место (ЕРМ) операторов первых линий ЦКР («Центра корпоративных решений») для направлений «операционная поддержка УСО» и «техническая поддержка ДБО» разрабатывается на базе банковской платформы «Единая фронтальная система» (ЕФС) с использованием модульного подхода, позволяющего легко подключить (в зависимости от потребности и готовности) дополнительные инструменты или сервисы. На февраль 2020 года ЕРМ состоит из следующих модулей: идентификации клиентов, аутентификации, CTI-панели, карточки клиента, истории вопросов, интеллектуального помощника, базы знаний, регистрации обращений, уведомлений, поиска в CRM.
ЕРМ содержит консолидированную из девяти систем-источников информацию: «CRM Корпоративный», ЕКС, СББОЛ, Way4, СНУИЛ, БФС (геообъекты), ФП «Выплаты», ФП ЗД (зарплатные договора). Это позволяет сократить количество программных окон на рабочем столе оператора.
2018: Результаты разработки за год
В 2018 году были усовершенствованы архитектура ЕФС, процессы разработки и вывода функционала в промышленную среду, сообщил Сбербанк в отчете о своей деятельности за 2 квартал 2019 года. Также была внедрена возможность многоверсионности, благодаря которой технологические сервисы и клиентский функционал могут развиваться независимо и итерационно в собственных релизных циклах.
В рамках разработки ЕФС в 2018 году Сбербанк реализовал функционал дистанционного банковского обслуживания по документарным операциям (аккредитивы, инкассо) через «Сбербанк Бизнес Онлайн», который позволяет клиенту направлять заявления/запросы/письма в банк в электронном виде, отслеживать их статусы онлайн и видеть реестр своих сделок.
Этот сервис позволяет сократить время обслуживания клиентов по аккредитивам и инкассо и повысить удовлетворенность клиентов, заявляют в Сбербанке.
Еще одним ключевым событием в области ЕФС Сбербанк называет начало этапа массового тиража системы на всех клиентов в трех каналах дистанционного банковского обслуживания в 2018 году.
2017: Новая версия ЕФС
В 2017 году была разработана новая версия платформы ЕФС 7.0 с более высоким уровнем надежности и производительности за счет поддержки режима развертывания в многоблочной архитектуре и режима Stand-In, обеспечивающего повышение отказоустойчивости и бесшовное обновление функциональных подсистем платформы. Также было начато массовое внедрение нового целевого процесса разработки ЕФС с использованием «инструментальных средств разработки. В Сбербанке поясняют, что это позволит одной команде реализовывать решения для всех каналов, максимально переиспользовать уже реализованные объекты и сервисы, уменьшить число ошибок за счет авто-генерации типовых функциональных блоков, а также сократить время обучения новых сотрудников.
Ожидаемый эффект от внедрения целевого процесса разработки ЕФС – сокращение объема ручной разработки в два раза.
Практики DevOps были внедрены для всех приложений ЕФС. Использование DevOps сокращает время на обновление приложений и позволяет избежать ошибок ручной установки параметров. Покрытие кода автоматическими модульными тестами достигло 80%, что привело к снижению количества ошибок на этапе тестирования в два раза, заявляет Сбербанк.
Кроме этого, в 2017 году банк определил стандарт качества платформы ЕФС. Его выполнение контролируется по 12 метрикам. Использование стандарта вдвое сократило количество ошибок на этапе тестирования и позволило добиться того, что 50% ошибок устраняются в течение 8 часов.
Определены разработчики Единой фронтальной системы Сбербанка
В мае 2016 года Сбербанк определил подрядчиков по созданию "Единой фронтальной системы" (ЕФС), которая позиционируется как новая платформа трансформации банковского бизнеса [1] .
Компания "Техносерв Консалтинг" выбрана разработчиком фронтальной системы для блоков «Розничный бизнес» и «Управление благосостоянием», AT Consulting - для блоков «Корпоративный бизнес» и «CIB».
Максимальная цена первого лота составляла 297 млн рублей, "Техносерв Консалтинг" предложила выполнить работы за 178,2 млн рублей.
Второй лот был оценен в 198 млн рублей. Сумма, за которую согласилась выполнить работу AT Consulting, составила 131,5 млн рублей.
Единая фронтальная система позволит Сбербанку обеспечить единый клиентский опыт и ускорить вывод на рынок новых продуктов
Генеральным подрядчиком Сбербанка по созданию Единой фронтальной системы является компания "Сбербанк-Технологии".
К участию в закупке были приглашены компании, имеющие опыт реализации не менее трех проектов по разработке фронтальных систем в период с 2013 г. (при этом пользовательская аудитория проекта должна составлять не менее 10 000 пользователей). Участники конкурса должны иметь не менее 40 разработчиков со знаниями языка программирования Java, 20 системных аналитиков, 20 разработчиков со знанием языка программирования JavaScript, css, html и 5 архитекторов. Специалисты проектной команды участника должны обладать сертификатами Java Senior Specialist (не менее 10 специалистов) и Oracle Professional (не менее 1).
Отдельно в документации оговаривались максимальные ставки специалистов:
| № п/п | Роль в проекте | Стоимость оплаты чел./дня специалистов, руб. без НДС | Стоимость оплаты чел./дня специалистов, руб. с НДС |
| 1 | Главный разработчик | не более 18 980,00 | не более 22 396,40 |
| 2 | Ведущий аналитик/разработчик | не более 14 440,00 | не более 17 039,20 |
| 3 | Ведущий аналитик/Бизнес-аналитик | не более 14 440,00 | не более 17 039,20 |
| 4 | Аналитик/разработчик | не более 10 690,00 | не более 12 614,20 |
| 5 | Ведущий разработчик (Java Script) | не более 10 690,00 | не более 12 614,20 |
Общая оценка заявки участников зависела на 50% от предложенной стоимости выполнения работ и на 50% от качества выполнения тестового задания.
Задачи системы
В системе работают сотрудники отделений и колл-центра банка, клиенты мобильных приложений и интернет-банка (юр. и физлица), партнеры по продаже продуктов банка. Эта система предназначена и для управление банкоматами и терминалами самообслуживания.
Внедрение системы позволит обеспечить единый клиентский опыт за счет создания единой базы клиентов для всех каналов обслуживания. Начать взаимодействие можно будет через колл-центр банка, а продолжить, например, в интернет-банке или в отделении с того момента, на котором операция была прервана.
Еще одна задача ЕФС – ускорить вывод на рынок новых продуктов банка. В нынешних условиях, когда за управление интернет- и мобильным банком, процессингом, банкоматами, терминалами отвечают разные приложения, обновление услуг и продуктов Сбербанка (например, изменение ставки по вкладу) по всей стране может занимать несколько недель. Цель – сократить сроки до одного дня.
Также, как ожидается, ЕФС позволит сократить время проведения операций, упростить интерфейс сотрудников отделений, ускорить адаптацию к работе новичков, снизить количество ошибок.
Руководство программы ЕФС
В конце 2018 года руководителем программы «Единая фронтальная система» стал Алексей Поддубный. По информации TAdviser, он был назначен на эту должность после того, как из Сбербанка ушла Елена Батурова, которая ранее руководила проектом ЕФС, а также Вадим Шаробаев, который под ее руководством отвечал за этот проект в Сбертехе. Подробнее здесь.
Автор статьи
Читайте также: