Микросервисный интеграционный шлюз

1. Увеличить скорость обмена данных между системами.

2. Снизить число ошибок и сбоев в обменах.

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

1. Переведено более 50 обменов на интеграционную шину.

2. Создан и запущен проактивный мониторинг обменов. Выстроена проактивная реакция технической поддержки на возникающие задержки и ошибки в обменах.

3. Более чем в 5 раз увеличена скорость обменов между системами. Пиковые задержки в обменах снижены на порядок.

4. Выполнено первое развертывание рабочей среды в облаке, подтверждена работоспособность без потерей в производительности между облаком и решениями в локальных ЦОД.

5. Изменена культура работы ИТ: метрики по скорости вынесены в KPI ИТ. Работа по контролю метрик, анализу отклонений и ошибок стала постоянной и органичной ИТ активностью.

   Документы доступны к печати менее чем через 10 минут после завершения работы в складской системе. Документы доступны для обработки в системе получателя менее чем через 10 минут после завершения обработки в системе отправителя.

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

Kafka, NiFi, Grafana, PostgreSQL.

Микросервисная интеграционная шина развернута в облачном ЦОД ВКонтакте.

В рамках цифровой трансформации в 2022-2055 годах планируется поменять 90% всех ИТ систем в Компании. Понимая данный объем работ в рамках стратегии, одной из ключевых архитектурных задач было реализация замены систем на одной стороне шлюза таким образом, чтобы системы на другой стороне шлюза не замечали этого.

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

На стратегических сессиях, на ежегодных конференциях все руководители Компании говорили о том, что скорость обменов и постоянные ошибки в обменах не дают бизнесу нормально работать, не то что развиваться и двигаться вперед. Как пример - машина могла ждать печати документов до 1 часа (время пока документы передадутся из складской системы в систему ERP). Расхожая фраза: люди на складе комплектуют и грузят, быстрее чем системы передают данные между собой. Анекдотичная ситуация по состоянию на 2022 год.

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

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

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

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

Проект был завершен в обозначенные сроки, но он не был простым и по ходу реализации обрастал подпроектами внутри:

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

• Запуск проактивного мониторинга потребовал полной перестройки команды технической поддержки, изменения работы системы Service Desk и части внутренних ИТ процессов.

Основные склады в Тольятти. В рамках интеграции с логистическим оператором к интеграционному шлюзу были подключены региональные склады в Твери, Краснодаре, Дмитрове, Екатеринбурге.