Synapse сбербанк это что

Обновлено: 28.03.2024

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

В далеком 2015 году в рамках эксперимента мы запустили первый небанковский сервис Бизнес Аналитика в интернет-банке Сбербанк Бизнес Онлайн. Это решение для управленческого учета в малом и среднем бизнесе. Мы решились на это вместе с партнером, так как создавать такой сервис с нуля было долго и очень дорого.

Мы взяли одного из лучших провайдеров сервиса управленческого учета - Seeneco, работающего по модели SAAS, адаптировали обертку (цветовую палитру сервиса, скрипты контактного центра) под гайдлайны банка и начали рекламировать внутри нашего интернет-банка для корпоративных клиентов (СББОЛ - Сбербанк Бизнес Онлайн).

И буквально сразу, в первые дни, мы обнаружили что теряем пользователей на этапе регистрации в сервис. И этому было очень просто объяснение: так как провайдер внешний, то и сам сервис находился вне периметра нашей системы и конечно сервис ничего не знал про клиента. Мы гнали трафик на отдельно стоящий сайт, на котором пользователь должен был найти кнопку “Зарегистрироваться”, пройти все шаги регистрации юридического лица (поверьте, это не так тривиально, как регистрация физ. лица) и только после этого он мог начать работу с сервисом.

Забегая вперед, хочу сказать, что мы вскрыли ящик Пандоры. В дальнейшем мы столкнулись с целой чередой проблем. Сервис не привлекал пользователей: они видели пустой экран, так как у внешнего сервиса не было никакой транзакционной информации по клиенту и самое печальное, freemium пользователи не становились платными. Но обо всем этом по порядку.

Мы поняли, что строить digital экосистему c stand alone продуктами просто нельзя. Это не удобно клиентам и не выгодно банку. Сервисами просто-напросто не пользуются. Единственный правильный путь – это бесшовный клиентский опыт.

Для обеспечения бесшовного опыта нам было нужно найти решение… И вроде оно у нас было – API. Но, к сожалению, классические банковское API не зашло b2b провайдерам - нашим партнерам. Оно создавалось банкирами для банкиров или для крупнейших корпораций. Традиционные банковские API тяжёлые, к ним сложно подключиться и ещё сложнее использовать, и вот почему:

  • SOAP архитектура, проприетарная авторизация, исторически сложившиеся форматы для передачи финансовой информации, асинхронный режим работы, обязательный hardware-VPN для организации защищенного канала и т.д.
  • PDF документация - никто не хотел “читать 7 томов”. Всем нужен удобный Wiki формат с перекрестными ссылками
  • Отсутствие удобной среды разработки и отладки. Партнеры хотели быстро получить результат (даже без написания кода!), просили готовые примеры реализации и “песочницу”, полностью эмулирующую промышленное окружение.

Поэтому мы решили создать специализированный API - fintech API, заточенный под потребности b2b SAAS провайдеров.

Мы не хотели изобретать велосипед, и обратились за лучшим опытом к FAGMA (Facebook, Amazon, Google, Microsoft, Apple).

Изучив подход и практики bigtech’a, мы решили создать API с нуля, без оглядки на предыдущие банковские решения. Новый связующий элемент digital экосистемы мы назвали - fintech API.

Мы провели серию интервью с разработчиками потенциальных потребителей нашего API. Выявили потребности, пожелания и совместили всё это с требованиями Банка и целями направления по развитию небанковских сервисов.

Что мы заложили в основу при проектировании API:

  • Никаких тяжелых форматов, которые учитывают малейшие нюансы. Будем проще! Разработанные нами форматы простые, легко понимаемые и не имеют ничего лишнего
  • API должен подходить широкому кругу потенциальных участников digital экосистемы, вплоть до заложенной возможности интеграции в digital экосистему продуктов IOT
  • Конечно же, мы решили избавиться от многотомных описаний, чтобы разработчики могли достичь быстрого результата. С помощью песочницы для тестовых испытаний можно получить первые положительные результаты уже за час. Мы сделали Easy Steps документацию, чтобы буквально за 15 минут оценить весь масштаб работ
  • Мы собрали тестовый полигон, заточенный под работу с внешними, небанковскими разработчиками. Подготовили базовые примеры реализации, чтобы минимизировать затраты внешних разработчиков на подоготовку к кодированию, уменьшить сроки разработки и количество потенциальных ошибок
  • Отказались от проприетарных решений, привязанных к определенной платформе. Все должно быть кроссплатформенным и не ограничивать партнера в используемой инфраструктуре. Никаких сложных требований к инфраструктуре и системному ПО
  • Внешним разработчикам не должно мешать то, чем они не занимаются — внутрибанковские сложные структуры данных, механизмы компонентов банковской платформы, особенности работы большого количества внутренних legacy-систем банка. Мы должны скрыть все это от внешних разработчиков – теперь это не их головная боль

Мы выбрали уже доказавшие свою полезность при построении Open API промышленные технические решения:

Аутентификация на базе протокола OAUTH 2.0

Тестовая песочница с развернутым SWAGGER. С помощью этой среды отладки разработчик партнера может смоделировать бизнес-процесс работы и получить результат без написания кода

Для обеспечения высокого уровня безопасности мы стали использовать ФПСУ (это такой “железный VPN”) между банком и партнером, а если партнер не использует платежные API мы разрешили работу через SSL.

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

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

Но самое интересное, что в рамках интеграции fintech API с b2b провайдерами у нас из host 2 hostметодов родились новые платежные механизмы.

Один из ключевых шагов любой воронки продаж - это оплата :) и к сожалению, на российском корпоративном рынке этот процесс крайне несовершенен. Одно юридическое лицо должно выставить счет другому юр. лицу. Бухгалтер покупателя создает черновик платежного поручения, которое должен подписать генеральный директор, и все ждут, когда деньги дойдут до продавца. Если платеж был отправлен в пятницу вечером, то продавец увидит поступление только в понедельник. Этот рудиментарный процесс очень плохо влиял на воронку продаж. Часть клиентов мы просто теряли, часть клиентов задерживала оплату, мы пропускали месяц (ы) абонентской платы. И мы решили сделать процесс взаиморасчетов между юр. лицами, таким же удобным как привычный нам онлайн-шопинг. Теперь наши клиенты могут добавить на свой сайт кнопку “Оплатить через Сбербанк Бизнес Онлайн”, которая отправляет пользователя на предзаполненное платежное поручение. Клиенту надо лишь вести СМС код и продавец в эту же минуту (не надо ждать сутки) узнает о факте оплаты - все точно так же, как и в карточном эквайринге. Просто, быстро и удобно. Это позволило значительно увеличить конверсию в первую оплату, но полностью проблему не решило.

Мы хотели увеличить количество клиентов, которые стабильно ежемесячно оплачивают абонентскую плату, но к сожалению, в b2b мире не было для этого решений. И мы вновь решили не изобретать велосипед и повторили b2c опыт. Мы создали решение, которое позволяет нашим партнерам безакцептно списывать денежные средства по факту оказания услуг. Для этого мы добавили в SberBusiness ID на шаг согласия клиента (мы называем это офертой) создание документа ЗДА - заранее данный акцепт, который легализует безакцептные списания между провайдером сервиса и конечным клиентом. Таким образом наш партнер через fintech API отправляет платежные требования (специальный банковский документ) в адрес клиента и эти требования безакцептно списывают указанную сумму в пользу партнера. Это позволило нашим партнерам увеличить количество платных клиентов. Часть партнеров даже изменили свои модели монетизации - отказались от годовых тарифов в пользу ежемесячных микро-транзакций.

Как и обещали в первой части кейса, рассказываем о том, какой стек использовала IT-команда Сбера при работе над проектом с большими данными. Для тех, кто её не читал: благодаря этому проекту разработчики научились эффективно взаимодействовать с «бизнесом», пройдя через кризисные точки. Но в этой части речь пойдёт не об оптимизации работы IT-отдела, а о технической изнанке проекта.

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


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

В проекте используется всего один инстанс БД PostgreSQL. А именно: Postgres Sber Edition (разработка Сбера), которую команда решила использовать в рамках импортозамещения. Заодно нужно было посмотреть, как эта БД будет работать с высоконагруженными данными и сможет ли заменить Spark, Hadoop, Kafka Streams и другие инструменты, которые обычно компании используют для работы с большими данными. Плюс это решение позволяло команде быстро выкатить MVP системы, которая, напомним, должна была стать первой на рынке — а значит работать надо быстро.

Из чего состоит система онлайн-мониторинга и в чём основной принцип её работы

Система состоит из двух частей:

Рабочее место сотрудника службы мониторинга

Рабочее место сотрудника службы мониторинга

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

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

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

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

Ядро системы

Ядро приложения построено на микросервисной архитектуре. Оно интегрируется с разными системами банка:

Телефонией Avaya для отслеживания телефонных диалогов между клиентами и операторами.

Интеграционной платформой Synapse (событийный сегмент, разработка SberTech) для получения данных через Kafka.

К базе данных подключается инстанс приложения, который ищет необходимые данные и отправляет их на Python-модули с AI-моделями. Модели обрабатывают данные, затем снова кладут их в БД.

Как происходит транскрибация телефонных переговоров

Интеграционный модуль AES (Application Enablement Services) по специальному интерфейсу GET ip подсоединяется к телефонии Avaya и собирает всю информацию о телефонном звонке в самом его начале. В этот же момент модуль отправляет метаданные звонка в транскрибатор SmartSpeech, который также подключён к Avaya. Здесь стартует процесс транскрибации текста: транскрибатор получает от Avaya RTP-трафик в виде звука и специальным инструментом для анализа преобразует его в печатный текст. После этого SmartSpeech отправляет текст в корпоративную сервисную шину Сбера, откуда он попадает в компиляционный модуль нашей системы, который сохраняет данные в базу. Всё это происходит в реальном времени, что накладывает определённые сложности.

Чем интересна и одновременно сложна работа на этом проекте

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

Знаете, пожалуй, пора перестать скромничать и сказать, что в проекте применяются самые передовые технологии и программы из сегодняшнего мира IT: микросервисы, контейнеры, ИИ, Big Data, речевые технологии, OpenShift, Kafka, Java Spring и другие. Полноценно используются эффективные мировые методологии разработки (DevOps, Agile, Git-flow), а команда старается использовать подход объединения разных путей с одной целью.

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

В заключение хочется дать небольшое пояснение насчёт особенностей работы в IT-команде Сбера. Некоторое время назад в Департаменте корпоративной архитектуры Сбера произошли кардинальные изменения, которые поддерживают новые цели всей экосистемы: внедрение передовых IT-продуктов и сервисов, масштабные инновации, конкурирование с глобальными технологическими компаниями. Благодаря этому вектору, у разработчиков в Сбере есть возможность использовать почти любые технологии, пробовать любые методы. Что ж, это и делает работу над подобными сложными проектами в Сбере интересной и по-настоящему творческой!

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

Frontend — Redux, React, TypeScript;

DB — Apache Ignite, PostgresSQL, Oracle;

MQ — IMB MQ, Kafka;

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

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

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

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

В четверг 4 февраля в 16:00 Сбер проведёт онлайн-митап, посвящённый SberSynapse. Участники расскажут, как прошли путь от первого знакомства с технологиями service mesh, понимания, что это такое и зачем оно нужно до промышленного решения в Сбере.

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

Нам хочется показать себя не только подкованными теоретиками, но и суровыми практиками и дать вам возможность «потрогать» SberSynapse самим. Подробная программа — под катом.

На онлайн мероприятии наши спикеры обсудят:

  • Как изменились интеграционные паттерны и почему большим компаниям важно не отставать от этих изменений?
  • Как развиваются технологические коммьюнити и как стать их участником (на примере Istio)?
  • Как встроить service mesh в свой интеграционный ландшафт и осуществить миграцию с legacy технологий?
  • Что делать, если что-то пошло не так и нужно найти корень проблемы в решении с Istio?

В докладе я расскажу, почему сейчас Service Mesh является архитектурным трендом при развитии интеграционных платформ мирового уровня, какие преимущества он несет и почему нужна адаптация применения данной технологии для задач класса Enterprise.

image

Lin Sun. IBM, Senior Technical Staff Member and Master Inventor, Istio, IBM Cloud.
Service mesh & Istio Community

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

image


Сергей Горьков. Сбер, отвечает за интеграционную архитектуру.
Как устроен SberSynapse и чем он лучше Istio?

Компании уровня enterprise предъявляют высокие требования к производительности и надежности интеграции и, зачастую, open source-решения не дотягивают до требуемого уровня. О том, как сделатьservice meshподходящим для использования в больших корпорациях и какие доработки для этого нужны, я расскажу в своем докладе. А еще расскажу что было сложнее всего в новой интеграционном шаблоне и об изменении архитектуры интеграции: перехода с esb на service mesh.

image


Евгений Лукин. Сбер, отвечает за миграцию на SberSynapse.
Миграция на Sber Synapse. Уроки промышленной эксплуатации

Все знают правило разработчиков: «Работает? Не трогай!». Как инициировать миграцию на новую технологию внутри компании. Что важно учесть при планировании миграции. Какие уроки мы прошли внутри и чего уже добились. Поговорим о том как перейти от разговоров о «теории» к практической реализации.

image

Максим Чудновский. IBM Россия, ведущий системный архитектор по открытому ПО.
IBM — Troubleshouting & monitoring. Deep dive

С каждым днем ландшафт для запуска контейнеризованных приложений усложняется, появляются новые компоненты, а значит новые возможности и, как это обычно бывает, новые проблемы. В таких условиях очень важно владеть своей инфраструктурой и понимать, что происходит «под капотом» тех или иных решений в ее составе. Istio, как один из центральных компонентов современного кластера Kubernetes, здесь не исключение, а значит имеет смысл погрузиться в это решение поглубже. Этим мы и займемся в рамках доклада — разберем основы конфигурации Istio Proxy, а чтобы было интереснее, сделаем это на примере одной из практических задач и решим небольшой ребус: два ServiceEntry на два tcp-хоста по одному порту. Что произойдет в Istio, а главное, почему?

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

Тендеры ПАО Сбербанк | госзакупки и коммерческие тендеры России

В бесплатном поиске максимальная длина запроса – 100 символов. Зарегистрируйтесь в Синапс.Про, чтобы получить доступ ко всем возможностям.

У вас будет 5 дней бесплатного доступа, чтобы оценить наш сервис.

Найдено в документах | Право на заключение договора аренды нежилого помещения площадью 156,1 кв.м, расположенного по адресу: Кемеровская область, г. Новокузнецк, ул. Циолковского, д. 50, пом.140 — 1 усл ед

Найдено в документах | Право заключения договора купли-продажи нежилого помещения (на 0 этаже здания) площадью 204,7 кв.м., расположенного по адресу: Ставропольский край, г. Ставрополь, ул. Бурмистрова 65 б. — 1 усл ед

Найдено в документах | Право на заключение договора аренды субаренды нежилого помещения общей площадью 24,0 кв.м., расположенного по адресу: Кировская область, Омутнинский район, г. Омутнинск, ул. Свободы, дом 11. — 1 усл ед

Найдено в документах | Право заключения договора купли-продажи, нежилых помещений площадью 533,8 кв.м, находящихся на первом этаже и в подвале многоэтажного здания общей площадью 1624,8 кв.м. по адресу: Вологодская область, г. Череповец, ул. Первомайская, д. 25. — 1 усл ед

Найдено в документах | Право на заключение договора аренды нежилого помещения, площадью 43,8 кв.м, расположенного по адресу: Пермский край, г. Краснокамск, ул. Ленина, д. 8 — 1 усл ед

Найдено в документах | Право на заключение договора купли-продажи нежилого помещения, площадью 43,8 кв.м, расположенного по адресу: Пермский край, г. Краснокамск, ул. Ленина, д. 8 — 1 усл ед

Найдено в документах | Право на заключение договора купли-продажи нежилого помещения площадью 42,5 кв.м, расположенного по адресу: Пермский край, г. Кунгур, ул. Бачурина, д. 45а — 1 усл ед

Найдено в документах | Право на заключение договора аренды нежилого помещения площадью 42,5 кв.м, расположенного по адресу: Пермский край, г. Кунгур, ул. Бачурина, д. 45а — 1 усл ед

Найдено в документах | Право заключения договора купли-продажи нежилого здания площадью 1025,20 кв. м. земельного участка площадью 972 кв.м.(включая трехфазный ДГУ, необходимый для бесперебойной работы ВСП8619\0687), и права аренды земельного участка площадью 182,0 кв. м. расположенных по адресу: Краснодарский край, г. Апшеронск, ул. Клубная, д. 25 — 1 усл ед

Найдено в документах | Право на заключение договора аренды нежилых помещений общей площадью 6 416,7 кв.м., расположенных по адресу: г. Москва, ул. Новослободская, д. 16. — 1 усл ед

Найдено в документах | Право на заключение договора купли-продажи нежилого помещения площадью 885,4 кв.м, 145/231 доли в праве общей долевой собственности на земельный участок общей площадью 1680,0 кв.м, располженных по адресу: Иркутская область, г. Братск, ж.р. Энергетик, ул. Мечтателей, д. 1 — 1 усл ед

Найдено в документах | Право на заключение договора купли-продажи нежилого здания площадью 516,5 кв.м и земельного участка площадью 373,0 кв.м. расположенных по адресу: Пермский край, Берёзовский район, с. Берёзовка, ул. Октябрьская, 18а — 1 усл ед

Найдено в документах | Право заключения договора купли-продажи нежилого помещения (1 этаж) площадью 150,6 кв.м. и 4/30 доли в праве на земельный участок, расположенные по адресу: Красноярский край, г. Канск, ул. 40 лет Октября, д. 60/2, пом. 1. — 1 усл ед

Найдено в документах | Право заключения договора купли-продажи, нежилого двухэтажного нежилого здания с подвалом, площадью 662,3 кв.м. и земельного участка (на праве собственности) площадью 488,0 кв.м. расположенных по адресу: Курская область, г. Льгов, ул. Карла Маркса, д. 42/2. — 1 усл ед

Автор статьи

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

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

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

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

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