стду сбербанк что это
Внедрение СТДУ в отделениях Сбербанка
Внедрить системы телеметрии и дистанционного управления в отделениях банка
Компания ITBOX реализовала комплексный проект по внедрению системы телеметрии и дистанционного управления (далее – СТДУ) в отделениях Уральского Сбербанка и в городах Омск и Тюмень.
До внедрения СТДУ в филиалах отсутствовала возможность управления и удаленного контроля состояния работы инженерных систем.
Например, было невозможно:
Централизованно контролировать и управлять параметрами среды (температура, влажность, уровень шума, уровень CO2) в зале обслуживания.
Дистанционно или по расписанию включать/выключать электрооборудование, что приводило к излишним затратам на электроэнергию.
Своевременно обнаруживать возникновение аварийных ситуаций (пропадание электропитания, возникновение протечек и т.д.) и реагировать на них.
Обслуживанием инженерных систем в отделениях занимались разъездные инженеры или внешние подрядчики. Проблемы обнаруживались и устранялись только во время очередного визита инженера, а не в момент их возникновения.
Заказчика не устраивали высокие затраты на эксплуатацию инженерных систем и сложность их контроля. А также – снижение качества обслуживания клиентов в следствии длительной реакции на возникающие нештатные ситуации.
Основными задачами, которые нужно было решить специалистам ITBOX, были:
Снизить расходы на энергопотребление.
Повысить уровень комфорта посетителей.
Оптимизировать затраты на обслуживание и ремонт инженерных систем.
В силу большого количества отделений, стоимость оснащения каждого была невысокой, в противном случае проект был бы экономически не оправдан. По этой же причине работу необходимо было завершить в очень сжатые сроки – 3-5 дней на отделение.
Описание решения:
Для реализации проекта использовалась комплексное решение от компании Inspark.
В помещении были установлены климатические датчики, в электрощите и на инженерном оборудовании – управляющие модули. Замена существующего на объекте оборудования не требовалась.
Получаемая от датчиков и модулей управления информация обрабатывается универсальным контроллером СЭМ Про 5.
Контроллер обеспечивает сбор и передачу данных от инженерных систем в единую облачную систему управления, а также выполняет локальные задачи управления.
В единой облачной системе управления данные по всем объектам хранятся и обрабатываются централизованно. В результате чего удается значительно сократить расходы на обслуживание объектов и устранение неисправностей, а также выявить отделения с аномальным потреблением электроэнергии и обнаружить посторонние подключения к электросетям.
В результате в течение полугода заказчик получил систему телеметрии и дистанционного управления в 120 отделениях банка, имеющую следующий функционал:
Регистрация и хранение ключевых параметров инженерных систем (как при аварии, так и в штатном режиме).
Получение оперативной информации о состоянии и параметрах работы оборудования отделения, обработка этой информации и формирование тревожной сигнализации о критичном состоянии оборудования.
Мониторинг показателей внутренней среды помещений.
Контроль доступа в специализированные помещения.
Оптимизация режимов потребления энергетических ресурсов для снижения затрат необходимых для эффективного функционирования отделений.
Сбербанк заявил о катастрофическом несоответствии «Эльбрусов» своим требованиям
Провальные тесты «Эльбрусов»
Специалисты Сбербанка провели оценку применимости в экосистеме своей организации серверов на базе российских процессоров «Эльбрус» и по ее итогам на сегодняшний день исключили такую возможность. Об этом рассказал представитель лаборатории новых технологических решений Сбербанка Антон Жбанков.
«Технические выводы достаточно простые: очень слабо для сравнения с Intel Xeon — мало памяти, медленная память, мало ядер, мало частоты. Функциональные требования катастрофически не выполнены», — сообщил он. По его словам, даже близко не может идти речи об эксплуатации в банке предоставленных на тестирование серверов.
Сбербанк проводил изучение серверов по различным методикам. Приведенные критические оценки в первую очередь относятся к итогам функционального тестирования по методике Sberinfra на соответствие корпоративным эксплуатационным требованиям банка.
В результате тестирования, как отметил Жбанков, «чуда не произошло» — серверы показали соответствие семи из 44 параметров («наличие лапки кабель-менеджмента, наличие рельсов, наличие индикации каждого элемента, наличие удаленного управления» и пр.) — 16%.
«Тесты в принципе вполне выполнимые. Мы так понимаем, что МЦСТ просто раньше с ними никогда не встречались, не работая с коммерческими компаниями, — сказал специалист. — Все понимаем, все принимаем; результаты переданы в МЦСТ».
В предположении Жбанкова, чтобы соблюсти большую часть требований нужно просто переупаковать сервер, не трогая сам процессор и ОС. «Надеемся, в МЦСТ нас услышат, и в будущем серверы будут в более доступном варианте для применения в таких компаниях как Сбербанк. Такие серверы сейчас в эксплуатацию взять не можем».
В тестах, которые вместе с оценкой результатов заняли четыре месяца, участвовали два различных типа серверов ( двух- и четырехпроцессорные) на восьмиядерных процессорах «Эльбрус 8С». Отметим, что МЦСТ уже подготовила массовое появление на рынке следующей серверной модели своих чипов — «Эльбрус-8СВ». На сайте компании говорится, что они серийно выпускаются с 2020 г., но рынок с ними пока знаком ограниченно. В то же время CNews известны отзывы производителей вычислительной техники, в соответствии с которыми эти новые изделия заметно превосходят своих младших братьев.
Как еще испытывались серверы на «Эльбрусах»
В отношении серверов на российских чипах Сбербанк применил свою стандартную многоуровневую систему тестов. В обычном случае, после провала первого уровня, рассмотренного выше, остальные этапы уже не проводятся. Для «Эльбрусов» Сбербанк сделал исключение.
На других этапах было проведено синтетическое тестирование на основе известных бенчмарков PGbench из пакета PostgreSQL и SPEC CPU 2017, а также прикладное тестирование на основе Java-приложения, реализующего бизнес-логику.
Сравнение проводилось по отношению к серверу на базе 20-ядерного чипа с частотой в 2,1 ГГц — Intel Xeon Gold 6230. В Сбербанке такую технику называют классической (не топовой); она тысячами закупается этой организацией.
Изделия на российских чипах уступили зарубежному конкуренту по всем параметрам, однако полученные результаты сотрудников Сбербанка все же «неожиданно и очень приятно» удивили.
«Мы ожидали, что разница будет не в разы, а в 20-30 раз, — отмечает Жбанков. — Для нас это реально удивительно». Вторым фактором удивления для тестировщиков стал вывод о том, что перед ними оказался законченный продукт. По словам специалиста, обычно российские разработчики приходят к ним с предложениями об использовании своих решений, имея на руках просто чертеж.
«На данный момент “Сбер” говорит нет, но мы приятно удивлены, что это вообще работает, — резюмирует Жбанков.
Рекомендации Сбербанка
По итогам тестирования в Сбербанке делают вывод, что процессоры семейства «Эльбрус» имеют теоретический потенциал роста производительности: увеличение тактовой частоты, увеличение количества ядер, увеличение объема и ускорение памяти (в т. ч. числа контроллеров памяти).
«Рекомендуем перейти на более современный техпроцесс и использовать современные стандарты оперативной памяти, — говорится в справке банка. — Необходимо провести тестирование серверов «Эльбрус» под управлением сертифицированных ФСТЭК операционных систем по профилю не ниже ОС.А4 (для применения в проектах, связанных с персональными данными и ГИС). Для конкуренции с лидирующими зарубежными решениями необходимо разработать новый процессор, сопоставимый с ними по характеристикам и производительности на момент его выхода».
Комментарии МЦСТ
К выступлению Жбанкова с описанными заявлениями на партнерском мероприятии МЦСТ (разработчик «Эльбрусов») специалисты компании подготовили свои комментарии, слайд с которыми был включен в его презентацию.
В этих комментариях сообщается, что стоимостные показатели «железа» МЦСТ планируется улучшить для поколения серверов на базе «Эльбрус-8СВ», с оптимизацией конфигурации под требования Сбербанка.
«За время тестирования улучшили время старта Java-приложений на 30%, — указывают специалисты МЦСТ. — Над ускорением troughput не работали. Запланирована работа по дальнейшему улучшению характеристик Java-машины. Часть функциональных требований невозможно выполнить на не-х86 платформах в принципе».
Также планируется доработка системы менеджмента и конструкции серверов для новой платформы «Эльбрус-8СВ». В МЦСТ полагают, что необходим диалог со службой эксплуатации Сбербанка для выявления первостепенных и второстепенных функциональных требований.
«В будущих версиях платформы “Эльбрус” планируется увеличение объема ОЗУ: сервер “Эльбрус-8СВ” до 1 ТБ, сервер “Эльбрус-16С” до 4 ТБ на сервер, — заверяют в компании. — В будущих версиях платформы “Эльбрус” планируется поддержка стандартов ОЗУ: сервер “Эльбрус-8СВ” до DDR4-2400, “Эльбрус-16С” до DDR4-3200. Для поддержки Enterprise-сред для контейнеризации и виртуализации для использования в облачных платформах заложены технические возможности в процессор “Эльбрус-16С”».
Уже вне презентации Жбанкова МЦСТ представила некоторые дополнительные комментарии.
«Java-приложение: это сложный ПАК, включает Java-application и СУБД, МЦСТ не имело доступа к приложению, что не позволило провести полноценный анализ, — говорится в них. — Удалось вслепую улучшить время старта Java-приложения и задержку отклика в три раза только подбором опций запуска Java-машины».
Для цели тестирования Сбербанком было разработано и передано макетное приложение, — продолжают сотрудники МЦСТ. — Для этого макетного приложения за счет доработки Java-машины и подбора опций улучшили среднее время отклика на процессоре “Эльбрус-8С” с исходных 24 мс до 4 мс (в шесть раз), при этом на X86 (Соге i7-9700 CPU 3 GHz) оно получилось 3 мс».
«При запуске Java-приложения на сервере загружались не более четырех ядер, что позволило платформе х86 поднимать частоту до 3,9 ГГц, что, скорее всего, не соответствует частоте ядер полностью загруженного сервера (2,1 ГГц)», — добавляют в МЦСТ.
Я обнаружил, что разработчики «Сбербанка» использовали реальные данные на тестовых серверах, и поплатился за это
Осенью прошлого года я устроился в «Сбербанк» и в качестве iOS разработчика делал iPad-версию ИСУ (Интеллектуальная Система Управления Сбербанка).
Чтобы не “ждать полгода бюрократии и согласований” для вывода приложения на продуктовые сервера и реализовать побыстрее MVP проекта, чтобы получить хорошие оценки за квартал и, соответственно, годовые премии, backend разработчики по распоряжению руководства использовали тестовые сервера с реальными данными сотрудников.
Моим функциональным руководителем был один менеджер из трайба Банк Рядом. Я указал ему на то, что в моем iOS приложении мы используем реальные данные, запрашивая их на тестовых серверах, и получим за это все «по шапке». Вот так у нас произошло начало конфликта.
Лучшим способом избавиться от “некомфортного” разработчика, который нашли, оказался переписать проект с Swift на ReactNative (что является крайне сомнительным решением).
Я понял, что нужно двигаться дальше и искать новый проект, начал искать работу, ездить по собеседованиями. Когда уже было понятно, что надо выбирать, я написал заявление по собственному. В одно утро я сильно задержался на собеседовании и руководитель подошел ко мне, начал угрожать, предложил написать заявление по сообственному, а когда я ему сказал что оно уже написано, он побежал в HR отдел, попросил их решить со мной вопрос за день, чтобы не ждать две недели, а меня: “как только тебя уволят, пригласи меня на улицу, я с тобой встречусь, поговорю и объясню тебе все что я хотел сказать”.
Радостный, получив трудовую книжку, я все таки написал ему, как она просил, чтобы встретиться со мной, но он как и положено мужчине, так со мной и не встретился.
А через полгода от знакомой HR я узнал, что они добавили меня в “черный список”, и захотел рассказать вам эту историю. Неудивительно, что с таким подходом на vc регулярно появляются новости про Сбер.
Если среди читателей есть юристы, буду очень признателен, если кто нибудь подскажет, как в судебном порядке можно решить вопрос с черным списком. Хочется не в Сбер, а справедливости.
Дописал: у меня нет претензий к Сбербанку как к компании, желаю ему процветания и надеюсь, что компания обратит внимание на проблему и разберется с тем, что происходит в ней.
Автоматизированные системы Сбербанка
Содержание
Сбербанк
На июнь 2015 года «Сбербанк» делит свои автоматизированные системы по 11 основным направлениям:
Core banking
Данные системы предназначены для обслуживания розничного сектора клиентов «Сбербанка» и ориентированы, в первую очередь, на обслуживание физических лиц. В числе операций, которые выполняются с их помощью – обеспечение хранения счетов по вкладам физических лиц и данных о клиентах, обслуживание запросов структурных подразделений отделений о состоянии счетов по вкладам физических лиц, прием банковских транзакций от функциональных подсистем операционного уровня и др.
Системы FrontEnd
Одной из центральных систем данного блока является АС ФС, позволяющая выполнять функции администрирования офисом, приема платежей и переводов, погашения кредита физлиц, работы со счетами и вкладами, банковскими картами, сберегательными сертификатами и лотерейными билетами, денежными знаками и ценными бланками, валютными операциями, монетами и слитками из драгметаллов, кассовыми операциями.
Также к FrontEnd системам относятся:
Процессинговые системы
Фабрика данных
BI-системы
В «Сбербанке» существует Центр компетенции развития BI. По данным одного из выпусков корпоративной газеты для сотрудников «Сбербанк Технологии», в ведении центра находятся: программно-аппаратный комплекс Teradata, включающий аналитическое хранилище данных, оперативное хранилище данных Oracle Exadata и еще одна система – витрины MIS.
Управление метаданными
Основной целью создания единой базы метаданных является автоматизация и повышение качества бизнес-процессов [2] :
Подробнее о практическом применении управления метаданными в Сбербанке в отдельной статье.
Кредитные АС
АС по управлению рисками
АС по управлению инвестициями
АС по управлению внутрихозяйственной деятельностью и персоналом
АС платформы BPM
Создание BPM-системы полного цикла в сбербанке
Единая модель процесса
Система связанных процессов
E2E-процессы вместо Продуктовых процессов Разделение процессов на 2 уровня:
Концентрация на E2E-процессах для повышения ценности для клиентов:
Непрерывное совершенствование & трансформация процесса
Интеграция с корпоративной архитектурой (КА)
Из презентации Бутыркин Вячеслав Алексеевич, 15.02.2018 на конференции CNews BPM-системы
Как мы переписывали сервер-сайд СберБанк Онлайн на микросервисы
Вы, наверное, в последнее время часто слышите о новых продуктах Сбера, со многими из них сталкиваетесь как клиенты.
А есть в Сбере крупные и сложные технологические проекты, которые напрямую не видны для клиентов, но от их запуска сильно зависит успех клиентских продуктов. Сложность связана с необходимостью трансформировать приложения, которые каждую секунду обеспечивают непрерывность текущего бизнеса Сбера, а масштаб обусловлен большим количеством функционала, который востребован 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.
Кроме того, на платформе много специфики этой платформы. Это тоже нехорошо, так как создаёт высокий порог вхождения для новых разработчиков и способствует изоляции от внешнего мира тех, кто давно на проекте. У нас есть трек активностей, направленных на то, чтобы изменить это в лучшую сторону.
Спасибо за внимание, жду вопросы в комментариях.