Привет всем! Меня зовут Александр Бардаш, я CTO интеграционной платформы MWS Octapi. Недавно я выступал с докладом на конференции True Tech Day и рассказывал, как мы строим инженерную основу для AI-агентов, которые не просто отвечают, а действительно помогают: автоматизируют процессы, принимают решения и становятся частью цифровых продуктов, а не остаются на уровне игрушек и прототипов.
Полностью посмотреть доклад можно в True Tech. А ниже — переработка для Хабра. Обсудим единый интеграционный ландшафт: зачем и для кого он нужен, как используется и почему важен для построения бизнеса и внедрения моделей. Поделюсь кейсом, как мы решили проблему сложных композитных сценариев построения и внедрили собственные ИИ-решения, которые серьезно упростили жизнь пользователям. Погнали!
Почему рушится интеграция
Когда я был разработчиком, ко мне регулярно приходили аналитики с предложением: «Давай делать интеграцию». Ок, договорились. Есть внешний продукт — идем к нему, смотрим API, быстро пишем микросервис, получаем креды, катим в прод. Если basic-авторизация, то уже хорошо, но много и интеграций вообще без нее.
Через три дня сервис в проде, бизнес доволен: все работает, time-to-market отличный. Но проходит месяц — и все ломается. Почему? Меняется контракт. Поставщик данных решил изменить ответ: кому-то понадобились новые поля, и их добавили, не предупредив. А у нас все упало.
Бизнес в панике: «Мы теряем деньги!». Готовим срочный hotfix. Появляется идея: «Нужно заключать контракт, фиксировать схему». Подписываем документы, формализуем взаимодействие — выруливаем. Но проходит еще два месяца, и снова сбой. Контракт ребята соблюдают, но на этот раз они просто переехали на другой сервер. Формально контракт тот же, но IP иной, файрвол не пускает. Итог — снова все рушится.
Таких историй масса. Каждое бизнес-подразделение решает их по-своему: поднимает свои API, покупает сторонние решения, настраивает инфраструктуру, нанимает девопсов и тестировщиков, поддерживает все это руками.
Мы в МТС пошли другим путем. Вместо дублирования усилий по всем направлениям сделали платформу Octapi — централизованное решение для управляемых интеграций. Теперь любая линия бизнеса может заказать интеграцию, быстро запустить ее по прозрачному и простому сценарию и не бояться сбоев.
Как работает Octapi
Octapi — это платформа для надежной и безопасной интеграции высоконагруженных систем в разнородных ИТ-ландшафтах. Если взглянуть на нее с высоты 10 тысяч метров, то все можно упростить до этих двух «кубиков»:
Control Plane — это по сути дизайн-слой, где проектируется интеграция;
Data Plane — это runtime, исполнительный уровень, где запускаются артефакты интеграции, реализующие саму интеграцию.
Вся внешняя активность проходит через единый API-сервер — централизованную точку входа. Через него обращаются веб-интерфейс, мобильные клиенты, SLI-утилиты, пайплайны GitLab и, если захочется, приложения со смартфонов. Все сводится к одному API.
Для удобства пользователей мы разработали Discovery-портал с поддержкой RBAC и ABAC, поисковым движком и интерфейсом low-code. За ним — Workflow Engine, гибкий движок, который подстраивается под разные бизнес-процессы. У кого-то нужно согласование с базовой авторизацией, а у кого-то это рассылка уведомлений по почте. У каждой команды — свой жизненный цикл работы с API, и движок адаптируется под него.
Теперь переходим к Delivery Plane. Как уже сказал, Data Plane — это runtime. Обычно он работает в изолированных сетевых зонах — например, с банковской тайной. Туда нельзя просто так отправить запрос: «дырок» в сеть нет. Поэтому мы реализовали безопасную доставку изменений на основе GitOps-подхода: изменения фиксируются коммитом и через CI CD автоматически доставляются в требуемую зону.
Сам runtime, то есть Data Plane, включает в себя все необходимое для гибкой и масштабируемой интеграции: поддержку Async API, Open API, Event Mesh, Service Mesh, low-code-интерфейсы и разнообразные типы интеграций под различные задачи бизнеса.
А что там с Low Code?
В отличие от классических API-менеджеров, которые обычно реализуют простую point-to-point-интеграцию, в реальных сценариях бизнеса часто требуется гораздо больше. Нужно сходить сразу в несколько endpoint, преобразовать данные из JSON в XML или наоборот, положить что-то в Kafka, вытащить из базы, объединить, отправить в 1С — и все это в рамках одного сквозного процесса. Такие сценарии мы называем композитными интеграциями, и это одна из важных фич Octapi.
Возникает логичный вопрос: как решать такие задачи? Если интеграции становятся все сложнее, значит, нужен инструмент для построения композитов.
Мы предположили, что это можно сделать с помощью low-code-подхода. Провели масштабное исследование: рассматривали готовые решения, но быстро стало ясно — ни одно из них не покрывает наши требования. В итоге стали разрабатывать собственный low-code-инструмент, заточенный под реальные сценарии интеграции внутри Octapi.
В качестве исполнительного движка выбрали Temporal. Вокруг него построили собственную систему: добавили примитивы, коннекторы и воркеры — каждый из них представляет собой отдельный low-code-«кубик», выполняющий конкретную задачу. Все это развернуто в Kubernetes с поддержкой горизонтального масштабирования.
Temporal отвечает только за исполнение pipeline: управляет порядком выполнения шагов и хранит состояние между ними. Остальное — на нашей стороне.
Здесь важно отметить одну особенность low-code-платформ. Обычно они либо очень простые, но при этом узкоспециализированные, либо универсальные, но настолько сложные, что проще написать сервис с нуля, чем в них разбираться. Это серьезная проблема — дальше расскажу, как мы ее решали.
Мы сделали систему, в которую можно входить с разных сторон. Например, графический интерфейс, код на стороне архитектора (например, C4-нотация и описание потоков) или даже генерация с помощью LLM. В любом случае есть единый исполнитель, и чтобы привести все к понятному формату, мы добавили W2LCODE-адаптер — на схеме выше он выделен красным.
W2LCODE преобразует различные форматы описания интеграций в универсальное представление, например QML или другие нотации, в JSON, понятный движку. Все централизуется, разбирается и исполняется через единую инфраструктуру.
Важно, что Temporal мы использовали как есть — без кастомизаций. Он нужен нам исключительно как исполнитель pipeline’ов. Мы сознательно не обвешивали его логикой и зависимостями, чтобы он не стал узким местом в архитектуре. Если завтра мы поймем, что Temporal нам больше не подходит, мы просто заменим его — на Camunda, собственный движок или любое другое решение. Инфраструктура это позволит: замена займет максимум месяц, и все будет работать.
Теперь вернемся к точкам входа. Помните ту «зеленую» сторону на схеме? Именно она отвечает за то, как мы решили проблему сложности входа в low-code.
Приступаем к работе: создание схемы
Допустим, я разработчик, и мне нужно получить low-code-интеграцию. Я не хочу пользоваться GUI, визуальными инструментами и прочим — и, честно говоря, на практике именно так все и происходит. Большинство наших разработчиков и архитекторов вообще не использует графический интерфейс.
Вместо этого они работают напрямую с JSON — описывают интеграционные потоки в понятном для машины формате, минуя любые визуальные редакторы.
Получается, они заходят с JSON — это и есть первый уровень входа в систему. Все выглядит прозрачно: разработчик знает аннотацию, быстро пишет нужный pipeline — и он сразу начинает работать. На такой подход уходит максимум час, даже для сложных сценариев.
Потом приходят архитекторы и говорят: «А я же нарисовал диаграмму, у меня есть интеграционный поток. Давай зайдем на более абстрактном уровне». Не вопрос — рисуем план, показываем, как мы его проходили. Обычно архитекторы очень довольны этой историей.
Дальше очередь системного аналитика, который тоже хочет создать интеграцию. Для таких случаев у нас есть третий уровень абстракции — GUI, графический интерфейс. Вытаскиваешь «кубики», настраиваешь параметры, все понятно и наглядно. Такой подход отлично работает и серьезно упрощает вход, особенно для тех, кто не пишет код напрямую.
Потом мы задались вопросом: а обязательно ли вообще все это рисовать руками? Почему бы не подключить AI-модель, которая возьмет на себя рутину? Так у нас появился AI Schema Builder — чат-бот, который помогает собрать интеграционную схему в диалоге.
Сценарий простой. Клиент пишет в чат, например: «Нужно получить сообщения из Kafka, преобразовать их в XML и отправить в REST-сервис в формате JSON». Модель понимает задачу, начинает задавать уточняющие вопросы. Например: «Укажи bootstrap-адрес для Kafka». Если пользователь не знает, что это, бот подскажет.
После короткого диалога модель собирает готовую схему: например, kafka.listener, преобразование JSON в XML, REST-запрос. Итог — системный аналитик получает рабочую интеграцию за 5–30 минут, не написав ни строчки кода и не открыв ни один редактор. Все через диалог с моделью.
Но даже этого нам показалось мало. Мы задумались: а может ли интеграция появляться уже на уровне постановки бизнес-идеи? Без системного анализа и уточнений технических деталей? Представьте: приходит CPO или бизнес-аналитик и сразу формирует интеграцию.
Оказалось, может. В первую очередь благодаря единому интеграционному ландшафту, где собираются и описываются все существующие потоки. Мы видим, как они работают, связаны между собой, и на этом уровне уже можно строить нужные сценарии.
Так появился AI Integration Builder. Его идея — упростить разработку интеграций до уровня запроса от бизнеса. Например, бизнес-аналитик говорит: «Хочу получать балансы и отправлять их в мой продукт». Он не знает, что и как работает, но это не проблема.
У нас в платформе весь интеграционный ландшафт — это не только OpenAPI-спецификации и описания потоков, но и дополнительные материалы: страницы в Confluence, внутренняя база знаний, документация. Вся эта информация доступна для AI-поиска, который умеет находить связи не только по названиям, но и по смыслу.
Допустим, пользователь ввел «баланс», а система ищет seasonBalance, getBalance и даже financeAttribute, хотя напрямую слово balance в последнем не встречается. Почему? AI понял, что в этом потоке действительно передаются данные о балансе, хотя это явно не указано. Он увидел это по API-спецификациям, по системным потокам и по трафику, проходящему через платформу.
Дальше все просто. Пользователь выбирает нужную интеграцию, и система автоматически определяет, к какому продукту он относится, какие у него есть права, какие интерфейсы доступны. На основе этого предлагаются релевантные интеграции, и одна из них выбирается. Все готово.
При этом бизнес-аналитик не знает, REST это или Kafka, какие нужны листенеры или коннекторы. Все за него делает платформа и единый ландшафт. Результат — полностью готовая интеграция, собранная по его запросу.
Low Code — зачем и для чего?
Low-code значительно сокращает time-to-market. Если раньше для вывода интеграции в прод нужно было пройти полный цикл «аналитик — разработчик — тестировщик — производственные процессы», то теперь все стало проще.
Бизнес формирует идею, сам собирает интеграцию — и она напрямую доезжает до фронта. Множество промежуточных ролей и этапов просто исчезает из процесса. Это ускоряет доставку, снижает нагрузку на команды и дает бизнесу реальный контроль над тем, как и что интегрируется.
Логичный вопрос: а как все это эксплуатировать? Наверное, сложно? На самом деле нет. Все довольно просто, потому что в основе low-code лежит Temporal, зрелое и проверенное решение.
У Temporal уже есть все необходимое для эксплуатации: готовый GUI, отлаженные механизмы мониторинга и работы со стейтами. Мы лишь добавили то, чего не хватало под собственные задачи — и получили полноценную систему наблюдения, с которой удобно работать в проде.
Показатели платформы
По нашим расчетам, платформа позволяет ускорить запуск интеграций на 36%, а также выдерживает нагрузку свыше 300 000 RPS. Фактически — и больше. Платформа может держать и до миллиона транзакций в секунду.
Закладываемый потолок в 300 000 RPS покрывает потребности 99% систем, где применяется это решение. Надежность достигает 99,95%–99,99%, что стало возможным благодаря использованию cloud-native-подхода: архитектура георезервирована, работает через несколько ЦОД-ов, построена на HA- или DR-решениях и полностью соответствует современным требованиям к устойчивым распределенным системам.
Где границы и как все это работает в реальной жизни
А закончу публикацию я так: отвечу на вопросы, которые мне задают чаще всего. Так будет проще понять, о чем я говорил выше.
— А есть кейсы, где low-code не сработал?
Да, конечно. Low-code не всегда оправдан. Например, если речь идет о сложной кастомной интеграции, где проще сразу написать микросервис. Это может быть длинная цепочка вызовов, сильно нестандартная логика или очень высокая нагрузка — условно 10 миллионов транзакций в секунду. В таких случаях мы не пытаемся «впихнуть» все в low-code. Но 95% интеграций в промышленной эксплуатации спокойно укладываются в рамки платформы.
— Бывали случаи, когда бизнес-аналитик задал ерунду и получилось что-то бесполезное?
Да, но это не проблема low-code, а общая реальность любого IT-процесса. Если бизнес-аналитик формулирует неполные или ошибочные требования, системный аналитик не уточняет, а разработчик не задает вопросов, то в итоге получаем «ерунду», просто дольше и дороже. Low-code тут помогает быстрее это обнаружить.
— Как устроено тестирование и окружения? Вдруг кто-то случайно отправит все в прод?
Каждый pipeline проходит через последовательные среды: DevProd, TestProd, UATProd, LoadProd и только затем — ProdProd. Пользователь может сам выбрать, на какой стадии запускать. Хотите сразу в прод? Это возможно, но по умолчанию действует защита — все управляется правами и политиками. Настраиваемость под конкретные процессы есть.
— За счет чего обеспечивается высокая нагрузка — 300k RPS и выше?
За счет Kubernetes-архитектуры и горизонтального масштабирования. Каждый «кубик» интеграции работает как изолированный pod. Хотите миллион RPS — пожалуйста, если ваш backend выдержит. Если нет, срабатывают ограничения по контракту: например, подписчик указывает, что может принимать не больше 10k RPS, и мы отсекаем лишнее. Есть механизмы retry, rate limit — все как положено.
— Как переиспользуются интеграции и решается вопрос с разными адресами на стендах?
Каждая интеграция — это готовый «кубик» со всеми настройками: адресами, авторизацией, токенами. Эти элементы публикуются в единый ландшафт и могут переиспользоваться многократно. Когда юзер собирает новый процесс, он просто подключает уже готовую интеграцию. Это особенно ценно в крупных компаниях, где одну и ту же логику могут реализовать десятки команд заново — вместо этого можно просто применять существующую интеграцию.