Эта статья о том, как вывести 1С из роли центра Вселенной и почему это хорошо для всех, включая саму 1С.
Я начинал как обычный разработчик в далеком 2004 году и прошел практически все этапы: начиная от простых доработок на 1С 7.7, заканчивая сложными проектами на УПП и ERP. Я много дорабатывал, внедрял и интегрировал. Именно на интеграциях в какой-то момент я понял, что что-то идет не так. Когда количество регламентных заданий, которые бы обрабатывали входящие и исходящие сообщения стало неприлично много, а бизнес-процессы становились сложнее – это был первый звоночек. А когда я провёл ночь, разбираясь, почему заказ с сайта "потерялся" где-то между сайтом и 1С – это был второй звоночек.
И я пошел искать пути решения и нашел их в мире за пределами 1С. Эти подходы используются во многих крупных компаниях и позволяют закрывать ту проблематику, с которой я столкнулся. И небольшой спойлер: они работают даже в нашей экосистеме 1С.
В своей статье я как раз хотел рассказать о таких подходах.
Были ли у вас крупные и объемные ночные обмены, которые неожиданно падали по той или иной причине, а утром к вам разъяренные менеджеры или обрывают линию недовольные клиенты?
Или другой кейс: у вас внутри 1С висят HTTP-сервисы, к ним начинают стучаться CRM, личные кабинеты, различные WMS и другие внешние сервисы. А потом приходят пользователи и говорят: «Ребята, мы не можем работать, у нас 1С просто висит».
Если вы были в ситуации, как в одном из кейсов, то эта статья точно для вас.
Во-первых, я расскажу, почему встроенный в конфигурацию объект «Бизнес-процесс» не помогает. Причем не только в рамках интеграции с внешними системами, но и внутри самой базы 1С.
Во-вторых, расскажу о паттерне, который используется во многих крупных корпорациях, таких как Uber, Netflix, Facebook. Эти компании осуществляют миллионы транзакций в день, и этот паттерн у них прекрасно работает.
В-третьих, расскажу о Kafka: как она здесь внезапно появляется, о способах ее интеграции с 1С и о том, какие проблемы она позволяет решить.
В-четвертых, будет живой кейс-пример: заказ с сайта, который попадает в 1С. Там происходит стадия резервирования, потом списание бонусов в другой системе и назначение доставки. И все – в событийной модели. Разберем как успешный кейс, так и кейс, когда что-то пошло не так.
В конце я дам рекомендацию, небольшой чек-лист, как это все можно опробовать у себя на каком-либо пилотном проекте, пощупать событийную интеграцию и ощутить эффект практически сразу.
Бизнес-процесс
Начнем с того, что идет в 1С прямо из коробки. Объект метаданных "Бизнес-процесс". Красивая вещь! Вы рисуете карту маршрута прямо в конфигураторе. Точки, условия, адресация. Визуально понятно, даже бизнес-аналитику можно показать. Этот инструмент действительно эффективен. Но в чём тогда проблема?
Проблемы начинаются тогда, когда бизнес-процесс выходит за рамки одной информационной базы. Как только он начинает взаимодействовать с внешним миром – например, появляется неожиданно сайт, мобильное приложение, CRM, WMS, – красивая карта маршрута сразу же превращается в тыкву.
Адресация задач, скажете вы? Да, она сделана регистром сведений, справочником пользователей. Но что, если исполнителем задач является внешняя система? Проблема.
Масштабирование? Скорее всего, вертикальное. То есть хотите, чтобы бизнес-процесс зашевелился побыстрее, – перенесите 1С на более мощный сервер.
И самый страшный, момент: если 1С упала, у вас упал весь процесс. И все остальные системы тоже упали, потому что они зависят от 1С. Тем самым мы имеем единую точку отказа в чистом виде.
Хорошо, говорите вы, мы поступим по-модному, по-молодежному – внутри 1С реализуем HTTP-сервисы и во внешних системах у нас тоже будут HTTP-сервисы. Мы начнем обмениваться, построим «микросервисную» архитектуру.
И знаете, что вы построили таким образом? Распределенный монолит. Это худшее из двух миров.
У вас все недостатки монолита: жёсткая связность, хрупкость. И все недостатки распределённой системы: сетевые сбои, частичные отказы, сложность отладки.
Хорошо, допустим, вы так сделали. И чтобы все хоть как-то заработало, вы начинаете все обвешивать очередями, регламентными заданиями. Количество этих заданий растет.
Это пример того, что я пару лет назад увидел у одного из клиентов. Думаю, знакомая картинкаИ это не микросервисная архитектура. Это ад, замаскированный под интеграции.
Оркестрация и хореография
Давайте я попробую объяснить проблему небольшой метафорой.
Представьте оркестр. В нем стоит важный, напыщенный дирижер, машет палочкой, командует и говорит: «Скрипки, вступайте. Трубы, громче. Ударные, тише». Все великолепно. Все подчиняются этому дирижеру.
Но что произойдет, если дирижер заболеет? В этом случае концерт отменят.
А что будет, если темп музыки, темп партии достаточно высок? В этом случае дирижер может просто не успевать махать палочкой. Музыка будет тормозить, все будут тормозить, и это заметят слушатели.
Давайте разберем другой подход.
Балет или современная хореография. Здесь нет дирижера. Здесь есть музыка и есть танцоры, которые танцуют под эту музыку. Они, можно сказать, независимы друг от друга, но подчиняются одной музыке.
Если один танцор сделал движение, второй может синхронно ему что-то сделать в ответ. И вместе они создают интересную партию, танец.
Этот подход называется хореография.
Что будет, если танцор упадет во время танца? На самом деле ничего страшного. Другие продолжат танцевать, помогут ему подняться, и он будет дальше танцевать вместе со всеми. Шоу не остановится.
А что будет, если нам необходимо ввести нового танцора в команду? В этом случае человек потратит некоторое время: изучит музыку, изучит танец, движения и постепенно интегрируется в команду, не меняя хореографию других.
Если говорить про оркестрацию, это наша классическая 1С, или BPM-система, или, допустим, та же Camunda или ее форки.
Оркестрация – это жесткая связанность, единая точка отказа. Но зато у нас есть транзакции – возможность легко и непринужденно откатиться в случае проблемы, простота отладки.
У хореографии нет какого-либо оркестратора. Все сервисы изолированы друг от друга. Они ничего не знают друг о друге, и нет единой точки отказа. Тем самым повышается стабильность. Из недостатков - это очень сложно отлаживать. Чем больше сервисов, тем проблематичнее найти проблему и провести отладку. Зато гибкость изменений выше, чем в оркестрации.
Kafka – это не RabbitMQ
И здесь неожиданно появляется Kafka.
Вы спросите: что она здесь делает? Как она завязана в нашей хореографии?
На самом деле все просто. Kafka – это та самая музыка, которая объединяет всех танцоров. Если говорить более простым техническим языком, это распределенный лог событий, сообщения которого не теряются после прочтения. Они могут храниться неделю, день, месяц, хоть бесконечное количество времени. Вы сами задаете период хранения данных.
В то же время из лога могут читать события и сообщения параллельно другие консьюмеры, не прерывая работу друг друга и никак не влияя на работу других. И читать они могут в своем темпе. То есть один может дочитать до сотой позиции, второй – до пятидесятой. Каждый идет в своем темпе и не зависит от другого.
Самое главное: мы можем для каждого консьюмера отмотать чекпоинт и перечитать сообщение заново. Тем самым восстановить хронологию событий. И это очень крутая фича.
Почему это важно для 1С?
Во-первых, 1С бывает медленная. Мы все прекрасно знаем, что есть процедуры закрытия месяца, расчета себестоимости, сложные регламентные операции. И 1С просто начинает быть медленной. Она не может по-другому.
Kafka подождёт. Сообщения никуда не денутся. Как только 1С оживет, все сообщения снова полетят из 1С. И также она начнет забирать сообщения. Это вообще не проблема.
Во-вторых, гарантирован порядок доставки событий именно в том виде, как они происходят в 1С. Например: заказ проведен, отгрузка произведена, оплата получена, товар отгружен клиенту. Именно в той хронологии, в которой события прошли в 1С, они запишутся в лог. И все сервисы, которые подписаны на эти события, получат их в строгой хронологии и смогут на своей стороне применить конкретную бизнес-логику.
Третье, очень важное: на те же топики, на которые подписана 1С и из которых она считывает данные, может быть подписана BI-система. Например, ClickHouse. Тем самым BI-система не стучится в 1С, а читает из тех же топиков и, по сути, не создает паразитной нагрузки на саму 1С. Так мы получаем real-time-аналитику без пинания 1С.
Вот так должна выглядеть современная архитектура, в которой 1С – это один из танцоров, один из сервисов, который работает со всеми в группе, в танце. И работает равноправно, так же как сервисы на Go, C#, Python.
1С – это такой же сервис, который не является единой точкой отказа. Все эти сервисы объединены единой музыкой – Kafka, которая хранит все события и является источником правды для всех сервисов.
Как связать 1С и Kafka
Теперь небольшая техническая часть: как связать 1С и Kafka. Думаю, многие пробовали и знают. Но я вижу четыре основных ключевых подхода.
Первый способ – Шина. Вариант хорош тем – что это решение от вендора, которое включает из коробки различные коннекторы и абстрагирует техническую сложность протокола Kafka от 1С разработчика, позволяя управлять потоками сообщений в привычном low-code интерфейсе и автоматически решая задачи буферизации и гарантированной доставки в базы 1С. Но поддержка протокола в Kafka в шине ограничена.
Второй вариант, который я рекомендую для пилотных проектов, чтобы просто пощупать, что такое Kafka, – использование HTTP Proxy.
На рынке есть Confluent, есть Karapace, open source-решения. Можно развернуть у себя, попробовать поиграться и посмотреть, Kafka подходит вам или не подходит. Но в этом случае также сильно ограничивается возможность применения протокола Kafka. Просто исчезает возможность работы с гарантиями доставки. То есть вы отправите сообщение – и не факт, что оно дойдет. Тем не менее вариант тоже рабочий.
Третий вариант – Sidecar-приложение. Его можно написать на любом языке. Это приложение, которое ставится между 1С и Kafka и, по сути, проксирует все запросы из 1С и перенаправляет их в Kafka.
Вариант удобен тем, что, если нужно дорабатывать приложение, не надо останавливать ни 1С, ни Kafka. Мы доработали, выкатили приложение – оно работает. Но это опять же единая точка отказа. Это еще один элемент инфраструктуры, за которым надо следить.
Четвертый вариант, который я всем настоятельно рекомендую, – использование внешней компоненты Simple Kafka Adapter. Это open source-продукт, разработкой которого я занимаюсь достаточно давно. Это зрелое production-решение, которое применяется во многих компаниях.
Эта компонента позволяет обращаться к Kafka прямо из кода 1С и обеспечивает полную поддержку протокола Kafka. Кроме этого, она позволяет работать с бинарными форматами AVRO и Protobuf и поддерживает интеграцию с реестрами схем, что в наше время весьма актуально.
Максимальная производительность – и нет каких-либо промежуточных звеньев.
Практический пример
Теперь, как я обещал, небольшой пример. Можно сказать, это классика электронной коммерции.
Пользователь заходит на сайт и оформляет заказ. С сайта событие улетает в Kafka. Кто подписан на это событие? По сути, это событие слушают три системы:
-
1С, которая должна поставить товар в резерв;
-
сервис лояльности, который должен проверить и списать бонусы клиента, если клиент оплачивает бонусами;
-
сервис логистики и доставки, который должен проверить и назначить доставку клиенту.
Если этот кейс пробовать делать в 1С с помощью объекта «Бизнес-процесс», мы неминуемо столкнемся со сложностью имплементации, адресации, ожидания выполнения задач от внешних систем.
Клиент оформляет заказ. Сообщение попадает на сайт. Backend-часть сайта формирует событие в Kafka о том, что сформирован заказ, и кидает это сообщение в определенный топик.
Дальше на это сообщение в топике Kafka подписана 1С. Она забирает событие, формирует у себя заказ, проверяет остатки и резервирует товар.
Если все хорошо, она отправляет событие уже в другой топик Kafka: о том, что резерв проведен на таком-то складе. По сути, товар зарезервирован.
На это событие подписан сервис лояльности. Он видит: «Ага, все, в резерв поставлено. Значит, я могу попробовать списать бонусы клиента».
Он забирает это событие, проверяет, есть ли у клиента бонусы. Если все нормально, списывает их и публикует следующее событие уже в другой топик: о том, что проведено списание бонусов.
На это событие подписан сервис доставки и логистики. Он забирает это событие и смотрит: «Все круто, заказ поставлен в резерв, бонусы списались, давайте назначать доставку». Проверяет, что все есть: свободные ресурсы в части доставки, свободные слоты по времени. И назначает доставку.
Эту информацию он скидывает в Kafka. И здесь, в финале, на последний топик подписан Backend сайта. Сайт ловит это сообщение, генерирует push-уведомление, которое показывает клиенту. И клиент видит push, в котором говорится: «Уважаемый клиент, вам назначена доставка с 10:00 до 14:00».
Негативный сценарий и паттерн Saga
А теперь негативный кейс. Что будет, если на каком-то этапе что-то пойдет не так?
Прежде чем его разобрать, я немного расскажу о паттерне, который позволяет решать такие негативные кейсы. Этот паттерн называется Saga.
Его придумали еще в далеком 1987 году, но широкое распространение он получил только в последнее время, с развитием микросервисов.
Его основная ключевая идея заключается в том, что в рамках распределенных систем нет единой большой транзакции. Она просто невозможна. Допустим, в рамках наших четырех сервисов.
Как быть тогда? В этом случае каждый сервис просто выполняет компенсирующее действие, если что-то пошло не так на определенных этапах. Это не откат транзакции, это именно операция undo.
Давайте разберем, как это выглядит в событийной архитектуре.
Клиент оформляет заказ, и все великолепно ровно до того момента, пока мы не доходим до сервиса лояльности – до списания бонусов.
Сервис лояльности видит, что у клиента бонусов недостаточно, и формирует событие. Говорит: «Слушайте, не могу списать бонусы, все плохо».
В этом случае он публикует событие в топик Kafka. На это событие, на этот топик, также подписана 1С. Она видит: «Ага, бонусы списать не удалось», – и выполняет у себя компенсирующее действие. Она снимает резерв.
После снятия резерва 1С публикует событие в ту же Kafka о том, что резерв снят. В этом случае сайт забирает это событие и генерирует уведомление клиенту: «У вас недостаточно бонусов. Давайте попробуем оплатить как-нибудь по-другому».
Так выглядит разбор этого кейса при паттерне Saga.
Конечно, можно было сделать немного по-другому: сразу все проверять. Есть ли вообще бонусы у клиента? Есть ли возможность списать резерв? Но в этом случае клиент бы ждал, потому что любая система могла находиться на обслуживании, могла быть загруженной. Клиент подумает: «У них что-то сервис тормозной» или «Мне опять интернет заблокировали».
Зачем нам это надо? Он быстренько пройдет цепочку. Если что-то пошло не так, ему быстро вернется результат, и он просто переиграет все.
Хореография внутри одной базы 1С
Вернемся немного назад.
Хореография и Saga идеально работают в распределенных системах. А как быть, если весь процесс происходит внутри одной базы 1С? Работает ли она там? На самом деле да.
Паттерн Saga и хореографию можно применять, когда у вас бизнес-процессы меняются достаточно часто. К вам приходит бизнес и просит изменить какие-то определенные условия согласования, добавить новые этапы ознакомления, рассмотрения. В этом случае лезть каждый раз в конфигуратор достаточно накладно. И здесь как раз может прийти на помощь подход с хореографией и использованием топиков.
Думаю, многие из вас встречали ситуацию, когда раз в квартал приходит финансовый директор и говорит: «А теперь согласование всех заявок на бюджет, все, что свыше 150 000, должно проходить через меня». И уходит.
Вы только садитесь за то, чтобы доработать карту маршрута или что-то гибко настроить в документообороте, как к вам приходит HR-директор и говорит: «Слушайте, если будут расходы или заявки по HR, по персоналу, заруливайте на меня».
Вы такие: «Да е-мое. Окей, ладно». И снова начинаете что-то делать.
Потом к вам приходит служба безопасности. Они обычно приходят в курилке, но прийти могут в любой момент. И говорят: «Слушайте, а почему тут заявки больше пяти миллионов мимо нас проходят? А ну-ка давайте на нас тоже заруливайте».
И все это превращается в мощную головную боль.
Вы можете, конечно, попросить все это описать в ТЗ. Но обычно бизнес не ждет.
В этом случае я рекомендую использовать паттерн хореографии.
Вы не лезете в конфигуратор, не редактируете карту маршрута. Вы заводите расширение, делаете справочник подписчиков, прописываете в нем кодом программную логику: какие топики слушать, как реагировать на те или иные события и кому дальше отдавать сообщения, в какие топики.
На первый взгляд может показаться, что это немного нагромождено, что там много кода. Этот подход называется бизнес-процессом, управляемым кодом.
Но в наше время я считаю, что идти именно от кода, а не от визуализации в бизнес-процессе и карте маршрута, – это более правильный вариант.
Сейчас же эра агентской разработки, vibe coding. Вы можете свою задачу по процессу вместе прогнать в ChatGPT, придумать стандарты наименования топиков Kafka, разбить все это на подзадачи, подключить MCP-сервер с контекстом вашей конфигурации. И за несколько итераций он вам сделает структуру этих подписчиков и напишет код на языке 1С.
Все. Вам можно в пользовательском режиме этот код вставить в элементы справочника подписчиков, сделать регламентное задание, которое будет запускать подписчиков, и вся цепочка будет работать.
А дальше, если вдруг придет бизнес и скажет: «Ребята, а давайте визуализацию, как это все работает? Мы не понимаем, у вас все кодом сделано», – вы берете трассировку, собираете ее, отдаете тому же ChatGPT или Claude code и говорите: «Нарисуй мне PlantUML-диаграмму последовательности для негативного, позитивного сценария и сценария, который я, возможно, не учел».
Буквально 5–10 минут – и у вас готовая PlantUML-диаграмма. Вы можете положить ее в GitHub-репозиторий или GitLab-репозиторий своей компании, связанный с этим проектом.
Тем самым у вас будет версионирование, у вас начнут появляться наконец-то артефакты вашей разработки и процессов. И на самом деле это очень круто.
Exactly-Once: сообщение обработано ровно один раз
Несколько подходов и моментов, чтобы все работало как швейцарские часы.
В мире распределенных систем возможны частые сбои, отказы. Одно и то же сообщение может либо не прийти вообще никуда, либо прийти два раза.
Например, продюсер отправил событие в брокер. Оно вроде дошло, но брокер не дал ответа. И продюсер еще раз отправляет. Соответственно, сообщение может продублироваться.
Kafka решает такие вопросы, используя семантику Exactly-Once. Она строится на трех ключевых моментах.
Первое – идемпотентный продюсер. Задачу дедубликации сообщения на себя берет Kafka. При отправке вы просто указываете параметр enable.idempotence=true. И даже если у вас повторно произойдет отправка, брокер внутри топика запишет сообщение один раз. То есть задачу дедупликации он берет на себя.
Второй момент – использование Transactional API. Если у вас есть пакет сообщений, который должен попасть в несколько топиков, и все это должно пройти в рамках одной транзакции, то есть все должно записаться во все топики либо не записаться никаким образом, вы можете использовать транзакционного продюсера.
Третий момент – работа с уровнями изоляции. У подписчиков, у консьюмеров, можно играть с уровнями изоляции, как в СУБД. Можно считывать только подтвержденные события, которые зафиксированы внутри брокера.
Хорошая новость: моя компонента Simple-Kafka-Adapter все эти моменты поддерживает из коробки.
Второй момент: как сделать так, чтобы сообщения не потерялись при отправке?
Например, заказ у вас провелся, полетело сообщение, но случился сетевой сбой, и сообщение не зафиксировалось никуда. То есть другие системы не знают о том, что заказ проведен.
Какой обычно подход? Регистр сведений исходящих сообщений. То есть классический Transactional Outbox Pattern. Как только у вас зафиксировалась транзакция, вы можете включить механизм истории данных и при обработке истории версии писать события в этот регистр. Отдельным регламентным заданием, которое раз в 5 секунд выполняется, отправлять эти сообщения. Либо можно в рамках транзакции записывать в регистр. Но это уже будет увеличивать время транзакции.
И хорошая новость: если вы используете 1С:Шину и сервисы интеграции - Transactional Outbox Pattern идет уже архитектурно из коробки. Поэтому это самый простой вариант.
Преимущества и цена
Чем приходится платить, если мы связываемся с хореографией? И какие у нас есть преимущества?
Во-первых, как я уже говорил, на те же события, которые читает 1С и другие системы, может быть легко подписана BI-аналитика: StarRocks, ClickHouse. У них прямо из коробки уже в комплекте идут коннекторы Kafka. Подключайте, забирайте сообщения, сырые данные и обрабатывайте их на стороне BI-систем. Не нагружайте 1С.
Второй момент – слабая связанность. Сервисы ничего не знают друг о друге, им все равно друг на друга. Сервис лояльности не знает об 1С, 1С не знает о сервисе логистики. Никто не знает друг о друге. Они просто выполняют свои операции, публикуют события и считывают события. Они живут внутри своего мира и занимаются теми делами, которыми должны заниматься.
Есть и негативные моменты.
Как я уже говорил, первый – перестройка мышления команды. Здесь придется перестроить мышление от транзакции, которая все делает либо откатывает, к событиям, которые текут.
Второй момент – инфраструктура. Kafka – это не просто игрушка из коробки. Это кластер, KRaft, ZooKeeper. Здесь нужна экспертиза.
Но опять же, в наше время есть managed-сервисы, например у того же Яндекса или у других облачных провайдеров. Разворачиваете двумя кликами мышки, закидываете денег – и все, у вас кластер высокой доступности из нескольких брокеров Kafka.
Самое печальное, наверное, – это сложность отладки. Это прямо болезнь. Но, слава богу, от нее есть таблетка.
Распределенная трассировка
Речь об использовании распределенной трассировки – OpenTelemetry.
По сути, мы создаем единый trace ID для нашей операции и протягиваем его по всем сервисам. У каждого сервиса есть свой идентификатор операции, восьмибитный хеш-идентификатор. Он добавляется внутри каждой операции и также перекидывается следующим сообщением в другие сервисы.
И как это все смотреть?
Jaeger – это визуализатор. По сути, это визуальный timeline нашего процесса: какие сервисы участвовали, в какое время они вступили, сколько длилась операция.
И самое главное – мы видим ошибки сразу. Проблемные сервисы выделяются красным. То есть мы видим, что в сервисе лояльности произошла ошибка, и дальше пошел откат. А в целом операция заняла около семи-восьми секунд, включая компенсирующие действия, вплоть до уведомления клиенту.
Бонус: Чек-лист для внедрения
Если хотите у себя попробовать все это дело, выберите небольшой пилотный процесс. Возможно, это какое-то уведомление или микросогласование, например заявки на расход.
Разверните у себя Kafka. Если есть шина – уже замечательно. Если нет – используйте внешнюю компоненту.
Попробуйте поиграть с отправкой, получением, настройкой. Сделайте процесс живым через хореографию. Посмотрите, как это работает, и постепенно портируйте на другие участки.
Главное – не забывайте о мониторинге. Сообщения могут складываться в топик, но сервис может быть недоступен. Он не будет читать сообщения, и будет копиться лаг. То есть количество непрочитанных сообщений сервисом. Это важный параметр, его нужно мониторить.
Полезные ресурсы
Есть официальная книга от компании, которая взяла Kafka под свое крыло. Она переведена на русский язык.
И есть моя книга про первые шаги использования 1С и Kafka https://github.com/NuclearAPK/Simple-Kafka-Start-Book.
Моя внешняя компонента за последнее время очень сильно технически развилась, у нее появилось много нового функционала. Начинающему разработчику очень сложно разобраться в технической документации, которая тоже выросла.
Поэтому я сделал небольшую книгу. Она с самых простых первых шагов показывает, как развернуть Kafka, как поставить внешнюю компоненту, как ее подключить, как попробовать отправить сообщение, получить его и дальше перейти уже к более серьезным сценариям: пакетной отправке, пакетному получению либо серьезным транзакционным вещам.
Заключение
В завершении я хочу сказать, что 1С должна и может стать равноправным участником современной микросервисной архитектуры. Не бутылочным горлышком, не центром Вселенной, а одним из равноправных танцоров.
Важно, что хореография – это не только про интеграции с внешним миром. Это также про гибкость процессов внутри компании.
А еще это возможность выйти за пределы монолита. Вы также пишете на языке 1С, ваши документы проводятся, регистры двигаются, но система начинает жить. Она не зависит от других сервисов. Она подождет, когда что-то у других упало. И сама может находиться на обслуживании – другие сервисы ее подождут.
Также это возможность подготовиться к AI-подходам и использованию данных, потому что любые события содержат данные. Данные – это ценность для компании. На данных можно обучать модели, они используются в RAG, используются агентами корпоративной поддержки, агентами искусственного интеллекта.
И как раз Kafka – это возможность подключать такие механизмы, не залезая в саму 1С.
В следующий раз, когда будет какая-то проблема, когда что-то потеряется, вы легко сможете использовать все эти подходы с помощью трассировки: взять ID заказа, вбить его в Jaeger и спокойно за две-три секунды найти проблему. Без подхода, когда мы залезаем в логи, ищем и копаемся в них до поздней ночи.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
Вступайте в нашу телеграмм-группу Инфостарт