Техническая поддержка ESB-шин

Обеспечим техподдержку ESB-шин для бесперебойной передачи данных.

Мы готовы предоставить техническую поддержку в использовании ESB-шин, гарантируя надежную и эффективную интеграцию ваших бизнес-процессов.

Мы поддерживаем:

Интернет-магазины

Производственные компании

Дистрибьюторы

Логистические операторы

Галина Лазарева

CEO STILT

Для нас важно соблюдать гарантии по SLA. Минимальная цена ошибки интернет-магазина от 300 тысяч руб/час.

ESB (Enterprise Service Bus) — это система, которая связывает приложения и сервисы, обеспечивая легкий и эффективный обмен информации между ними.

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

Основные компоненты и архитектура ESB

Шина данных

Центральный канал для передачи сообщений и их маршрутизации.

Маршрутизатор

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

Преобразователь сообщений

Адаптирует формат сообщений для совместимости с целевой системой.

Брокер сервисов

Управляет доступом к сервисам и гарантирует безопасность взаимодействия.

Адаптеры

Создают соединение с приложениями, адаптируя их интерфейсы.

Мониторинг и управление

Инструменты для отслеживания работы ESB и управления производительностью.

Проблемы в работе ESB-шин

(01)

Низкая производительность

(02)

Сложности конфигурации и управления

(03)

Совместимость и управление версиями

(04)

Адаптация к изменяющимся требованиям

(05)

Проблемы маршрутизации и транзакций

(06)

Отказ в обслуживании и системные сбои

(07)

Архитектурные сложности

Как мы поддерживаем ESB-шины

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

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

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

Обеспечиваем правильную работу API и взаимодействие ESB с другими интеграционными решениями.

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

Бесперебойная работа
бизнеса на высоких скоростях

3 мин.

Среднее время
реакции на инцидент

15 мин.

Среднее время
решение инцидента

*Данные предоставлены за 2024 год

Наиболее часто возникающие инциденты

1. Продолжительность обхода alert

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

2. Размер пачки alert

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

3. Записано в выходящую точку alert

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

4. Старость заказов alert

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

5. Время работы коннектора в целом alert

Аналогично проблемам с продолжительностью обхода.

6. Старость полученных сообщений alert

Аналогично «Старость заказов alert», но касается всех сущностей, которые долго не обрабатываются коннектором, а не только заказы.

7. Количество ошибок/предупреждений

Ошибки, связанные с сетевой доступностью ресурсов. Зачастую, это ошибки доступности серверов розниц.

8. Возраст заказов для DWH и backgw

Аналогично «Старость заказов alert», отличие что заказы загружаются в хранилище.

9. Время между приёмом сообщения и завершённой записью в хранилище заказов

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

10. Список коннекторов с зависшим обходом alert

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

Почему стоит выбрать
именно нас?

(01)

Отвечаем деньгами за соблюдение SLA

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

(02)

Проактивная ИТ-команда с глубоким погружением в проект

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

(03)

Снижаем риски, действуя на опережение

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

(04)

Поддержка доступна 24/7/365 дней в году

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

(05)

Многоуровневая техническая поддержка

Команда STILT состоит из инженеров двух уровней: L1 и L2. Такой подход позволяет заранее реагировать на возможные сбои или нарушения, тем самым достигается стабильность в работе IT-систем и сокращается время простоя.

(06)

Многоканальная связь

Для оперативного обмена информацией со смежными подразделениями мы используем различные каналы коммуникации: чаты WhatsApp, Telegram, Service Desk, телефония, email и др. По запросу клиента подключаем единое окно обращений в службу поддержки.

(07)

База знаний на языке пользователей

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

(08)

100% безопасность данных

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

(09)

Взаимодействие с другими отделами

Кросс-функциональная работа нашей службы поддержки включает в себя плотное сотрудничество со всеми подразделениями бизнеса.