На связи Анна Астахова, директор по развитию ИТ-интегратора «Белый код». Расскажу, как мы перенесли 197 интеграционных потоков крупного девелопера на DATAREON Platform без остановки рабочих систем — и почему за задачей «перенести работающие обмены» скрывалась ревизия дублирующегося кода, забытых механизмов синхронизации и накопленной бизнес-логики.
Заказчик: девелопер федерального уровня.
Задачи:
Централизовать обмен между многочисленными базами 1С, чтобы снизить нагрузку на системы, и уйти от логики интеграций «точка-точка».
Упростить сопровождение и доработки интеграций.
Повысить управляемость и прозрачность интеграционного ландшафта.
О компании: комплексно развивает территории в центральной России: строит жилые кварталы, детские сады, школы, поликлиники, спортивные и коммерческие объекты. Это надежный застройщик федерального уровня.
С чем обратился заказчик
У клиента было большое количество баз 1С: ERP, БИТ.Строительство и другие конфигурации. Обмен между ними шел через RabbitMQ, формально брокер сообщений в ландшафте был, но по сути интеграция оставалась схемой «точка-точка»: каждая система сама формировала отдельное сообщение для каждого конечного получателя и знала обо всех своих адресатах. Брокер только доставлял сообщения, а вся логика маршрутизации и подготовки данных жила внутри баз.
Хуже того, выгрузка для баз с идентичной конфигурацией была реализована в отдельных процедурах: один и тот же объект для нескольких одинаковых баз формировали разные участки кода. Это приводило к колоссальному дублированию кода и усложняло поддержку. Любая доработка одного потока требовала изменений сразу в нескольких местах, риски ошибок росли, а сопровождение становилось неоправдано дорогим.
Клиенту требовалось не точечное улучшение, а системное решение. Мы предложили перейти к архитектуре «звезда» с DATAREON Platform в центре: логику маршрутизации и трансформации вынести в единый управляемый контур, чтобы каждая система взаимодействовала только с шиной и ничего не знала о своих получателях.
Проект включал реализацию 197 интеграционных потоков с различной бизнес-логикой и форматами данных. Срок 3-4 месяца, при этом системы продолжали работать без остановки и обмен нельзя было прерывать.
Что сделали
Провели ревизию существующих интеграций.
По условиям контракта отдельного аналитического этапа в проекте не было: предполагалось, что мы переносим уже работающие обмены на новый инструмент. Реальная архитектура с дублирующимися процедурами стала для нашей команды большим сюрпризом, поэтому разбор пришлось встраивать в ход проекта.
Начали с изучения тел сообщений, которые уходили в разные базы. Быстро выяснилось, что сообщения для одинаковых конфигураций отличаются по составу и структуре, и никто на стороне заказчика не мог объяснить, почему так сложилось. Пришлось тратить время на разборы: как все-таки должно быть правильно, какие расхождения являются осознанной бизнес-логикой, а какие накопились случайно. Задача «перенести интеграцию на другой инструмент» превратилась в большую ревизию существующих интеграций.
Параллельно фиксировали фактическую картину: какие базы участвуют во взаимодействии, какие потоки реализованы, где дублируется логика, какие данные критичны для операционной деятельности, какие интеграции работают под высокой нагрузкой, где есть исторические доработки и нестандартная логика. На основе этого сформировали целевую архитектуру и поэтапный план переноса потоков, чтобы не останавливать рабочие процессы компании.
Автоматизировали разбор интеграционного кода.
Чтобы не тратить дорогое время разработчиков и аналитиков на ручное хождение по конфигураторам, написали парсер на Python. Он выгружал модули исходников конфигураций, связанные с обменом. Помогло то, что интеграция с RabbitMQ во всех базах была реализована по единой архитектуре: расширения имели общую структуру и набор типовых модулей, а специфика каждой конфигурации была вынесена в отдельные частные модули. Благодаря этому расположение и назначение нужного кода были достаточно предсказуемыми для автоматического разбора.
Выгруженный интеграционный код собрали в документацию на MkDocs и разместили на внутреннем портале. В результате аналитик или разработячик мог, не открывая конфигураторы, быстро пройтись по всем процедурам, связанным с конкретным выгружаемым или загружаемым объектом, и сравнить, как один и тот же объект обрабатывается в разных базах.
Каждый поток имел свою бизнес-логику, формат данных и требования к обработке. Часть сценариев в процессе была уточнена, часть оптимизирована, некоторые добавлены по итогам ревизии. Перенос выполняли поэтапно, без остановки рабочих систем.
Запустили обмен серией контролируемых переключений.
Поскольку переход шел поэтапно, DATAREON и старые механизмы обмена какое-то время работали одновременно. Уже на первых потоках поймали дублирование контактной информации физических лиц. Причина оказалась в одновременной работе двух механизмов: старого обмена через RabbitMQ и типовой синхронизации 1С. По всей видимости, при переходе с типовой синхронизации 1С на обмен через RabbitMQ типовой механизм не отключили. В результате оба обмена годами работали параллельно и фактически дважды передавали одни и те же данные.
Отдельная сложность возникла из-за отсутствия актуального описания существующей схемы обмена. В ряде случаев объект, поступивший в принимающую базу через DATAREON, после записи автоматически регистрировался к отправке уже типовым механизмом обмена 1С. Это создавало риск зацикливания: данные могли уйти обратно в исходную систему, снова попасть в интеграционный контур и начать циркулировать между базами. Такие зависимости приходилось выявлять уже в процессе перевода конкретных потоков.
Перед миграцией мы сразу предусмотрели порядок отката на старый механизм, и это себя оправдало. После переключения команда следила за архивом сообщений DATAREON и поведением систем-получателей. Если возникала существенная проблема, отдельные потоки возвращались на старую механику, устранялась причина, проводилось повторное тестирование и предпринималась новая попытка перехода.
В результате промышленный запуск был не одной датой, а серией управляемых переключений без простоя в работе.
Решили вопрос с «пропущенными» сообщениями.
После первых переносов выяснилась еще одна эксплуатационная особенность. В старой системе часть сообщений считалась пропущенными по бизнес-логике: например, данные связанные с физлицом не передавались, если связанного физического лица не должно было быть в принимающей базе. При этом нужно было сохранить возможность анализировать такие неотправленные сообщения. Решили отправлять их в архив DATAREON.
Заказчик запросил хранение таких сообщений в течение 30 дней, и оказалось, что их очень много. Никто ранее не хранил такие объемы в архиве DATAREON, и у продукта начались технические проблемы. Спасибо поддержке вендора, быстро разобрали инцидент и прислали патч, после чего проект пошел дальше.
Построили мониторинг под службу сопровождения.
По мере роста числа перенесенных потоков возник следующий вопрос: как всем этим пользоваться службе сопровождения? Нужно было отвечать на прикладной вопрос: «Что произошло вот с этим договором, физическим лицом или банковским счетом?». Сервиса аналитики DATAREON на тот момент еще не было, а стандартных средств центра мониторинга для этого не хватало.
Сначала мы построили централизованную систему сбора логов на стеке Loki + Grafana. Но у Grafana есть порог входа для тех, кто с ней не знаком, и команда сопровождения 1С отказалась ей пользоваться. Для них мы сделали отдельную обработку мониторинга DATAREON прямо в привычном интерфейсе 1С, она взаимодействовала с логами в Loki, центром мониторинга DATAREON и с базой 1С. Из нее специалист может просматривать сообщения, переходить к объекту 1С по типу данных и идентификатору либо MDM-ключу, смотреть связанные события журнала регистрации за время обработки сообщения и анализировать отмененные сообщения.
Таким образом, к концу проекта речь шла уже не просто о внедрении интеграционной платформы: вокруг нее сформировался полноценный эксплуатационный инструментарий.
Автоматизировали подготовку документации.
В конце проекта стояла задача задокументировать все 197 потоков. Здесь нас снова выручил Python. DATAREON хранит весь интеграционный код и настройки внутри своей конфигурации, а конфигурация лежит в Git. Поэтому ее можно взять из репозитория, распарсить и получить все настройки маршрутов, трансформаций и подключений в структурированном виде.
Мы заранее заложили это в процесс разработки: комментарии, отражающие особенности реализации, разработчики помечали тройным слэшем «///». Парсер собирал такие комментарии и вставлял их в документацию рядом с соответствующими настройками.
В итоге около 80% документации мы получили напрямую из конфигурации DATAREON. Это документация, которая точно соответствует тому, что работает в продуктиве, а не тому, что помнят разработчики: достоверная, актуальная, с перекрестными ссылками между потоками, объектами и правилами. Вручную писали только концептуальную часть и описание эксплуатационных процедур.
Передали компетенцию заказчику.
Требование передать знания внутренней команде стояло с самого начала. 197 потоков были только первой очередью: общее количество потоков в ландшафте оценивалось в 600-800. Делать такой объем силами подрядчика очень дорого, поэтому единственный разумный путь для заказчика: развивать собственную компетенцию по платформе.
Договорились так: на все время проекта заказчик выделяет своего разработчика, и он работает у нас как удаленный сотрудник. Ходит на внутренние проектные встречи, коммитит в наш Git, пользуется нашими внутренними инструментами и наработками и выполняет задачи, которые ему ставит наш ведущий разработчик. То есть не «сидит рядом и смотрит», а делает реальные потоки по нашей проектной технологии.
Здесь нам повезло: специалиста выделили сильного, и получилась настоящая win-win синергия. Он получил от нас экспертизу по интеграционному продукту, инструменты, подходы и проектную технологию. Мы получили опытного разработчика, который знает интегрируемые системы изнутри. А если какую-то систему он не знал, то знал, к кому обратиться и как найти концы. В крупной компании это отдельная непростая задача, и наличие «своего» человека внутри заметно экономило время на согласованиях и поиске ответственных.
В результате заказчик получил не просто обученного администратора, а разработчика, который прошел вместе с нами весь цикл: от ревизии старых обменов до промышленного запуска и мониторинга. Компания снизила зависимость от внешнего подрядчика и готова развивать интеграционный контур своими силами.
Результат:
Интеграции перевели со схемы «точка-точка» на централизованную архитектуру. Каждая система работает через шину и ничего не знает о своих получателях.
Нагрузка на базы 1С снизилась: вместо множества параллельных выгрузок данные отправляются один раз, а дальше шина распределяет их по нужным системам.
Изменения больше не требуют правок в нескольких местах. Логику обмена можно корректировать централизованно, без лишних рисков.
Убрали дублирование кода и бизнес-правил. Поддержка стала проще и предсказуемее.
Появился прозрачный мониторинг на двух уровнях: Loki + Grafana для инженеров и обработка в 1С для службы сопровождения. Аналитики видят статусы потоков, ошибки и очереди в режиме реального времени и могут отследить судьбу конкретного объекта. Если возникает инцидент, его можно быстро локализовать и устранить.
Запуск новых интеграций занимает меньше времени, так как есть единая архитектура и отработанные механизмы.
На все потоки есть достоверная документация, сгенерированная из конфигурации DATAREON, а значит, не расходящаяся с тем, что работает в продуктиве.
У компании есть собственный разработчик, прошедший весь проект вместе с нашей командой, и компетенция для сопровождения и развития интеграционного контура внутри.
Этот проект показал, что интеграционная архитектура напрямую влияет на устойчивость бизнеса. Когда обмены строятся по принципу «быстро подключили и работает», рано или поздно система упирается в предел по масштабируемости: количество связей растет, сложность увеличивается, поддержка начинает стоить дороже развития. И наличие брокера сообщений само по себе от этого не спасает, если логика маршрутизации остается внутри каждой системы. Теперь подключение новых систем или изменение логики обмена не отдельный проект с непредсказуемыми последствиями, а рабочий процесс в рамках единой платформы.
Комментарии (3)
ToxaBes
01.10.2026 12:28Спасибо за комментарий.
Кажется вы смотрите из мира микросервисов, а в мире учетных систем исходные условия другие.
Я понимаю, что вы имеете ввиду, выглядит как будто ML-щик из веба рассуждает о ESB в тех терминах, к которым привык не зная нюансов интеграций 1С. Это не так.
Я отдал внедрению 1С 10 лет своей молодости, и конфигурации писал, и обмены данных, и интегрировал. Т. е. я понимаю, почему 1С была сделана монолитом. Так исторически сложилось и тогда это было полностью оправдано. 1С вообще один из самых продуманных и качественных монолитов за счет толстого слоя собственных абстракций под бизнес-сущности.
При этом я уже 6й год в мире ML, и наблюдаю огромную ML волну, которая накрывает все сферы ИТ систем включая ESB. Современный ML позволяет автоматизировать те места и стыки систем, которые еще 2 года назад было экономически нецелесообразно или просто невозможно автоматизировать. Более того, теперь он позволяет менять сами основы устоявшихся архитектур. Процесс только начался и и при взгляде изнутри разных отраслей может быть еще не так очевиден.
Микросервис без интеграций бесполезен
Вот об этом я и пишу, сейчас сама интеграция становится микросервисом, т. е. происходит немыслимое ранее, архитектура системы буквально станвится с ног на голову и выворачивается наизнанку. Благодаря ML в ESB начинается процесс, который прошел в eCommerce и вебе 10 лет назад. Я не ярый адепт микросервисов, скорее сторонник подхода "каждой задаче свой инструмент", просто озвучиваю наблюдаемый мною процесс.
ИИ это скорее усиливает: модели лучше работают с одной декларативной конфигурацией в Git, чем с логикой, размазанной по десяткам конфигураторов.
Уже нет, instruct, MCP, skills и мультиагентность закрыли этот вопрос. Еще два года назад это было не возможно, но взрывной рост ML отрасли сделал свое дело.
Мое мнение, кадровый голод уже уходит, и вряд ли вернется. Те кто освоят ИИ будут работать один за пятерых, а те кто не освоил, уйдут из профессии или пойдут на завод, где еще лет 20 никаких изменений не будет.
Спасибо за мнение. Я пока что склоняюсь к мысли, что в итоге будет парадоксальная ситуация: кадровый голод при наличии хороших специалистов в конкретных отраслях. Работа же будет у специалистов на стыке двух или трех отраслей, например, ML + ESB + Web. Т. е. будет требоваться не столько скорость, сколько широта покрытия так сказать.
ToxaBes
Статья хорошая, видно, что к ее созданию привлекали тех, кто систему создавал. Предлагаю обсудить вывод, который она подразумевает, хотя явно он не прописан: централизованная шина (ESB) на крупных проектах является финальной точкой эволюции интеграций.
Из-за взрывного роста доступности ИИ-моделей для бизнеса сейчас идет беспрецедентный слом устоявшихся решений, и он дотягивается даже до шин данных уровня предприятия. По моей оценке, через несколько лет шина как центральный “умный” узел, где живут маршрутизация, трансформация и бизнес-логика обмена, станет нишевым решением для махрового легаси.
Термин, скорее всего, останется, но шина утончится до инфраструктуры доставки и безопасности, а смысл, преобразования и логика уйдут к владельцам данных и в слой, где их будет помогать строить и сопровождать ML. Попробую объяснить, что я имею ввиду.
Главное преимущество ESB и low-code платформ было в том, что трансформации и маршруты проще и дешевле сопровождать в визуальной среде, чем кодом. Это было так, пока код писали руками.
Сегодняшние LLM хорошо делают то, что в проекте решали самописным парсером: читают незнакомый код, сравнивают реализации, находят расхождения, пишут маппинги, генерируют тесты и документацию. Стоимость создания и поддержки интеграционного кода падает быстрее, чем стоимость лицензий и компетенций под конкретную платформу, и баланс “платформа или код” смещается к коду.
Шина построена вокруг модели “сообщение пришло, преобразовали, доставили, архивировали”. ML и аналитике нужны полная история изменений, возможность перечитать поток с нуля и единый доступ к данным без очередной выгрузки.
Источником правды становится не канал доставки, а лог событий и общее хранилище (CDC, Kafka-подобные системы, lakehouse): данные публикуются один раз, а подписчиков может быть сколько угодно, включая модели и витрины. Тот же архив на 30 дней пропущенных сообщений, который в статье вызвал проблемы у продукта, при таком подходе был бы штатным режимом хранения.
Ядро (проводки, договоры, платежи) останется примерно прежним, но на него приходится малая часть обменов. Остальное изменится, потому что ML хорошо решает то, что шина решает плохо: смысл данных. Шина преобразует по правилам, но смысла не понимает, а в ML распознавание сущностей и поиск аномалий уже сегодня справляются лучше ручных правил.
Меняется и масштабируемость. Вы пишете, что 600-800 потоков силами подрядчика делать дорого, и решение в том, чтобы вырастить внутреннего разработчика. Но правильно ли, чтобы одна команда и одна платформа владели всеми обменами между всеми доменами?
Практика последних лет (владение данными по доменам, контракты вместо центральных моделей) движется в обратную сторону: каждая область публикует события с понятным контрактом, а потребители подключаются сами, не ожидая очереди в центральную команду. ML ускоряет это.
Но главная проблема во всей этой трансфрмации в другом. Специалистов, которые одновременно понимают ESB и ML, на рынке крайне мало. Разработчика комплексной автоматизации быстро ML не научить т.к. там не просто чат или RAG добавить сбоку, а ML-инженер так же быстро не вникнет в тонкости интеграции.
По моей оценке это займет примерно год на обучение и еще год на доработку шины поэтому начинать готовить таких специалистов нужно было еще вчера.
SergeySkirdin
Спасибо за развернутый комментарий, со многим согласен: ИИ удешевляет интеграционный код, для ML нужен лог а не доставил и забыл.
Кажется вы смотрите из мира микросервисов, а в мире учетных систем исходные условия другие. Без оценок «хорошо» или «плохо», 1С это самодостаточный монолит, такова данность. Микросервис без интеграций бесполезен, поэтому у его разработчиков работа с контрактами и событиями в крови. 1С-разработчик сосредоточен на функциях внутри системы, интеграция для него задача периферийная. Знакомый архитектор 1С на вопрос о главной проблеме интеграций ответил: отучить думать через конвертацию 2, технология начала 2000 годов, а может и более старая.
Поэтому модель «каждый домен публикует события с контрактом» здесь не работает сама по себе: в доменах нет носителей этой культуры. Шина в таком ландшафте концентрирует интеграционную компетенцию там, где она реально есть.
ИИ это скорее усиливает: модели лучше работают с одной декларативной конфигурацией в Git, чем с логикой, размазанной по десяткам конфигураторов. 80% документации мы получили автоматически именно поэтому. А Kafka и lakehouse нужны для КХД и ML, но это соседний слой: шина не хранит данные, а перечитывать поток из источника (1с ERP к примеру) не лучшая идея.
Вывод про кадры у меня другой. ИИ усиливает хороших специалистов, они закрывают задачи быстрее и качественнее. Мое мнение, кадровый голод уже уходит, и вряд ли вернется. Те кто освоят ИИ будут работать один за пятерых, а те кто не освоил, уйдут из профессии или пойдут на завод, где еще лет 20 никаких изменений не будет.