Почему интеграции между системами ломаются

Где начинаются проблемы

На простом сценарии всё выглядит безобидно: клиент оформил заказ на сайте, заказ попал в CRM, затем передался в учётную систему. В каждой системе операция прошла успешно — но это ещё не означает, что вся цепочка отработала правильно.

Например, сайт может передать сумму заказа в одном формате, а учётная система ожидать другой. CRM может использовать один идентификатор клиента, а ERP — другой. Или заказ действительно создастся в первой системе, но ответ о результате не дойдёт обратно из-за временного сбоя сети.

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

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

API не решает всю задачу

API — это способ, которым одна система обращается к другой. Оно определяет, как отправить запрос, какие данные передать и какой ответ получить.

Но API не отвечает за то, правильно ли компания построила сам обмен данными.

Можно иметь хорошо документированный API, стабильное соединение и корректные запросы — и всё равно получить ненадёжную интеграцию. Если системы по-разному понимают статусы заказа, используют разные идентификаторы или не умеют восстанавливаться после ошибки, проблема появится уже на уровне логики.

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

Данные не всегда означают одно и то же

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

Допустим, сайт передаёт в CRM статус заказа paid. Для сайта это может означать, что клиент успешно оплатил заказ. Для ERP аналогичный статус может означать уже подтверждённую оплату, по которой можно запускать отгрузку. А складская система вообще может использовать отдельный статус, который появляется только после проверки платежа.

Технически данные передались правильно. Ошибки API нет. Но системы получили разное представление об одном и том же событии.

Такая же ситуация возникает с товарами, клиентами и документами. В одной системе товар определяется по артикулу, в другой — по внутреннему идентификатору. Где-то цена хранится с НДС, где-то без него. Одна система передаёт дату и время, другая ожидает только дату. Для человека эти различия могут показаться незначительными, но для автоматического обмена они становятся отдельными правилами, которые необходимо учитывать.

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

Если при следующей синхронизации интеграция не умеет сопоставлять этих клиентов, вместо обновления существующей записи может появиться ещё один клиент.

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

И здесь появляется ещё один важный вопрос: что должна сделать система, если одна и та же информация приходит повторно?

Это уже не вопрос API. Это вопрос архитектуры и логики самой интеграции.

Повторный запрос — не всегда ошибка

Повторная передача данных сама по себе не означает, что интеграция сломалась.

Например, сайт отправил заказ в CRM, но не получил ответ от сервера. Через несколько секунд он отправляет тот же запрос ещё раз. Для сайта это нормальная попытка убедиться, что операция выполнена. Для CRM это уже два одинаковых запроса.

Если интеграция не умеет распознавать такие ситуации, один заказ может превратиться в два.

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

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

Если тот же заказ придёт повторно, система сможет проверить идентификатор и понять, что запись уже существует.

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

А если система вообще не ответила?

Вот здесь начинается другая распространённая проблема.

Интеграция отправляет данные в ERP, но ERP временно недоступна. Запрос не выполнен. Что делать дальше?

Можно просто показать ошибку и ждать сотрудника. Можно потерять операцию. А можно сохранить её и автоматически повторить отправку позже.

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

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

Ошибка не должна останавливать весь процесс

Представим, что сайт работает нормально, CRM доступна, а ERP неожиданно перестала отвечать. В этот момент заказ уже существует, клиент его оформил, но передать информацию дальше не получилось.

Плохой сценарий — просто показать ошибку и забыть о заказе.

Сотрудник может даже не узнать о проблеме, а спустя несколько часов обнаружить, что в ERP нет части заказов. Затем начинается ручная проверка: что было отправлено, что дошло, что нужно провести повторно и какие записи уже существуют.

Надёжная интеграция должна вести себя иначе.

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

Так временная проблема одного сервиса не превращается в потерю данных и не требует постоянного ручного контроля.

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

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

Статусы тоже могут рассинхронизироваться

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

Например, клиент оплатил заказ на сайте. Сайт изменил статус на Оплачен и отправил событие в CRM. CRM обновила карточку клиента, но ERP в этот момент была недоступна.

В результате некоторое время три системы будут показывать разное:

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

Особенно сложно это становится, когда статус может изменяться из нескольких мест. Например, заказ создаётся на сайте, менеджер меняет его в CRM, а отгрузка переводит его в новый статус уже в WMS.

В такой архитектуре недостаточно просто передавать поле status. Нужно заранее определить правила:

• Какая система отвечает за конкретное состояние;
• Какие изменения разрешены;
• Какие события должны передаваться дальше;
• Что происходит при возникновении конфликта;
• Какая система имеет приоритет, если значения отличаются.

Без этих правил интеграция постепенно превращается в набор исключений, которые приходится исправлять вручную.

Именно поэтому синхронизация статусов — это не просто копирование данных между системами. Это согласование бизнес-логики между ними.

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

Когда систем становится больше

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

Например:

Затем появляется 1С:

Потом подключается склад:

А после этого добавляются маркетплейсы, телефония, сервис рассылок, аналитика и другие системы.

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

Например, если поменять структуру заказа на сайте, может потребоваться изменить обмен с CRM, 1С и складом. Если каждая система связана с каждой напрямую, одно изменение постепенно превращается в цепочку доработок.

Поэтому при развитии инфраструктуры важно заранее определить, где должна находиться интеграционная логика.

Иногда прямой обмен вполне оправдан:

Но для более сложной системы может понадобиться отдельный слой:

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

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

Мониторинг нужен не меньше, чем сама интеграция

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

Проблема в том, что пользователь далеко не всегда увидит такую ошибку.

Сайт продолжит открываться. CRM продолжит работать. Сотрудники будут создавать заказы. Но данные между системами перестанут передаваться.

Это позволяет не просто узнать, что «что-то сломалось», а понять, на каком именно участке возникла проблема.

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

При этом логирование и мониторинг решают разные задачи.

Логи помогают разобраться в том, что уже произошло.

Мониторинг помогает вовремя заметить, что что-то происходит сейчас.

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

Что происходит, когда интеграция меняется

Интеграция редко остаётся неизменной на протяжении всего срока работы системы.

Сайт обновляется. В CRM появляются новые поля. В 1С меняется структура справочника. Компания подключает ещё один склад или добавляет новый канал продаж.

На этапе разработки всё это может выглядеть как небольшая доработка. Но изменение одного поля иногда затрагивает сразу несколько связанных процессов.

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

Поэтому при развитии интеграций важно учитывать совместимость изменений. Новая версия интерфейса обмена не должна неожиданно ломать уже работающие процессы.

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

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

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

Что важно продумать до интеграции

До начала разработки полезно ответить хотя бы на несколько вопросов:

• Какая система является источником данных;
• Какие данные и в каком формате передаются;
• Как системы идентифицируют одни и те же объекты;
• Что происходит при ошибке или недоступности сервиса;
• Можно ли безопасно повторить операцию;
• Как обрабатываются дубликаты;
• Кто отвечает за изменение статусов;
• Как команда узнает о сбое;
• Что произойдёт после изменения одной из систем.

Чем раньше эти вопросы определены, тем меньше вероятность, что интеграция постепенно превратится в набор отдельных исправлений и ручных операций.

Вместо вывода

Надёжная интеграция — это не просто рабочий API между двумя системами.

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

Поэтому при проектировании интеграции полезно начинать не с вопроса «какой API использовать?», а с более простого:

«Что должно произойти с данными от момента их появления до конечного результата — и что произойдёт, если на любом этапе что-то пойдёт не так?»

И уже после этого выбирать API, webhooks, очереди сообщений, интеграционный слой и другие технические инструменты.