Большинство ошибок интеграции систем закладываются в первый месяц, а проявляются через полгода: когда вырос поток заказов, обновили 1С или ушёл разработчик, который «всё знал». Первые недели обмен работает, все довольны, а потом бухгалтерия находит расхождение в оплатах, и выясняется, что данные терялись давно. Ниже — шесть архитектурных ошибок, которые мы чаще всего видим на аудите чужих интеграций, и как спроектировать обмен, который не падает молча.
Почему интеграция работает на старте и ломается потом
На запуске интеграцию проверяют на «счастливом пути»: создали тестовый заказ — он появился в 1С. Всё. Никто не проверяет, что будет, если 1С недоступна в момент заказа, если покупатель дважды нажал «Оплатить», если в справочнике появился новый склад. Эти ситуации редкие, поэтому первые недели не встречаются. Через полгода они накапливаются — и всплывают одновременно.
Вторая причина — рост. Обмен, который спокойно передавал 50 заказов в день, на 500 начинает упираться в лимиты API, таймауты и блокировки базы. Если архитектура не рассчитана на рост, сбои становятся ежедневными. Поэтому на аудите в рамках разработки API и нестандартных интеграций мы первым делом смотрим не на то, работает ли обмен сегодня, а на то, как он поведёт себя при сбое и росте.
Ошибка 1. Нет очереди и повторов
Самая частая схема в дешёвых интеграциях: сайт в момент события напрямую вызывает API другой системы. Если та ответила ошибкой или не ответила вовсе, событие потеряно. Никто об этом не узнает, пока клиент не позвонит с вопросом «где мой заказ».
Правильная схема: событие сначала записывается в очередь, отдельный обработчик отправляет его и при неудаче повторяет с нарастающим интервалом. Если принимающая система лежит час, данные копятся и уходят, когда она поднимется. Остальные системы работают, пользователь сбоя не видит.
Как проявляется
«Иногда заказы не доходят до 1С», «оплата прошла, а статус на сайте не поменялся». Слово «иногда» — верный признак отсутствующей очереди.
Как исправить
Вынести отправку из основного процесса: сайт записывает событие в очередь и сразу отвечает покупателю, а доставкой занимается отдельный обработчик. Число попыток и интервалы задаются в настройках, а событие, которое не ушло после всех повторов, попадает в отдельный список на ручной разбор и вызывает алерт. Так же решается проблема лимитов API: обработчик отправляет данные с допустимой скоростью и пакетами, а не пытается протолкнуть всё разом в час пик.
Ошибка 2. Повтор создаёт дубль
Обратная проблема: повторы добавили, а идемпотентность — нет. Связь оборвалась после того, как 1С уже создала документ, но до того, как сайт получил ответ. Сайт повторяет отправку — и в 1С появляется второй заказ. С оплатами ещё хуже: задвоенное поступление ломает сверку с банком.
Идемпотентность означает, что повторная отправка одного и того же события не создаёт второй документ. Каждое событие несёт уникальный идентификатор, и принимающая сторона проверяет, не обрабатывала ли она его раньше. Это закладывается в архитектуру сразу — добавить потом намного дороже.
Лечить дубли ночной «чисткой» скриптом. Скрипт удаляет следствия, но причина остаётся, а заодно иногда удаляет то, что дублем не было.
Ошибка 3. Нет логов: логирование обмена данными «потом»
Когда что-то пошло не так, первый вопрос — что именно ушло, когда и с каким ответом. Если журнала нет, ответа тоже нет: разработчик смотрит код и строит гипотезы. Разбор одного инцидента превращается в несколько дней переписки между подрядчиками 1С, сайта и CRM, каждый из которых уверен, что у него всё правильно.
Логирование обмена данными должно фиксировать каждое событие: время, источник, получателя, содержимое или его ключевые поля, ответ и число попыток. Тогда спор «кто виноват» решается за минуты, а откат ошибочной операции становится возможным: видно, к какому состоянию возвращаться.
Ошибка 4. Нет мониторинга интеграций и алертов
Логи без мониторинга — это архив, который никто не читает. Нужен механизм, который сам замечает аномалии: очередь растёт, ошибок больше обычного, за последний час не пришло ни одного заказа, хотя обычно приходят десятки. Уведомление уходит ответственному в Telegram или на почту.
Мониторинг интеграций особенно важен там, где сбой не виден глазами: выгрузка остатков, загрузка банковских выписок, передача данных в BI. Если отчёт собственнику строится на данных, которые перестали обновляться три дня назад, решения принимаются по устаревшим цифрам. Для этого есть отдельная услуга — контроль качества данных и сбоев: мониторинг объёма, задержек и ошибок обменов, ежедневная сверка BI с 1С и CRM и журнал сбоев.
Проведём аудит существующей интеграции: найдём точки отказа, покажем, где теряются данные, и предложим план доработки без остановки обмена.
Заказать аудит интеграцииОшибка 5. Жёсткая привязка к полям и форматам
Код интеграции знает, что статус «Отгружен» в 1С называется именно так, что склад один, а телефон хранится в поле с конкретным именем. Стоит бухгалтерии переименовать статус или добавить второй склад, и обмен ломается. Хуже, если не ломается, а начинает молча подставлять значения по умолчанию.
- Справочники соответствий — в настройках, а не в коде. Новый статус добавляется администратором, без программиста.
- Неизвестное значение — это ошибка в журнале, а не повод подставить «первое попавшееся».
- Источник правды по каждому полю описан явно. Иначе две системы перезаписывают друг друга, и конфликт разрешается молча.
- Версии API фиксируются. Когда вендор выпускает новую, мониторинг показывает сбой, а данные ждут в очереди обновления коннектора.
Ошибка 6. Зависимость от одного разработчика
Интеграцию написал фрилансер или штатный программист, документации нет, код лежит на его компьютере или на сервере, доступы к которому есть только у него. Пока он на связи — всё работает. Когда он уходит, любое изменение требует сначала разобраться, как это вообще устроено, а иногда проще написать заново.
Защита простая, но её нужно требовать с первого дня: исходный код и доступы оформлены на вашу компанию, есть схема обмена и описание правил, распространённый стек, под который легко найти специалиста. Мы, например, пишем на PHP/Laravel или Node.js и передаём код, документацию и алерты вместе с проектом. О том, как сравнивать подход «свой программист» и подрядчик, есть отдельная статья — штатный разработчик или подрядчик.
Отказоустойчивость интеграции: чек-лист для проверки вашего обмена
Пройдите по пунктам вместе с тем, кто поддерживает вашу интеграцию. Каждый пункт без ответа «да» — риск, который однажды сработает.
- Если принимающая система недоступна час, события сохраняются и уходят после восстановления.
- Повторная отправка одного события не создаёт дубль заказа, клиента или оплаты.
- Есть журнал: по любому заказу можно найти, когда и с каким ответом он ушёл.
- О сбое кто-то узнаёт автоматически в течение минут, а не от клиентов.
- Названо, кто отвечает за реакцию на алерт и в какой срок.
- Справочники статусов и складов настраиваются без изменения кода.
- Для каждого поля известно, какая система — источник правды.
- Проверено, как обмен ведёт себя при росте объёма в несколько раз.
- Код, документация и доступы оформлены на компанию.
- Есть способ откатить ошибочно переданные данные.
Если «да» меньше половины, не обязательно переписывать всё. Часто достаточно добавить очередь, журнал и алерты поверх существующего обмена — это уже снимает основную часть потерь. Если связей между системами больше двух и они построены «каждая с каждой», правильнее перейти на шину данных: 3–5 систем, единая модель данных и правила разрешения конфликтов.
Как спроектировать обмен, который не падает молча
Надёжность закладывается на этапе архитектуры, а не после первых жалоб. В наших проектах по разработке нестандартных интеграций очереди, повторы, идемпотентность, мониторинг с алертами и журнал операций входят в состав работ по умолчанию, а перед запуском мы тестируем на копиях систем обрывы связи, повторы и откаты. Перевод на боевой контур постепенный: старый канал работает, пока новый не подтвердит стабильность.
Если интеграция уже работает и вызывает сомнения, начните с аудита: какие системы, где живут данные, что уже ломалось. Если сбой не виден, но вы подозреваете, что данные теряются, поставьте мониторинг обменов — он покажет, где именно. Почему у многих магазинов «не работает» обмен с 1С и что с этим делать, мы разбирали в материале про обмен сайта с 1С.
Как понять, что интеграция теряет данные?
Сравните количество заказов или оплат в системе-источнике и в принимающей системе за неделю. Любое расхождение без объяснения — признак потерь. Регулярно это делает автоматическая сверка.
Что такое мониторинг интеграций на практике?
Это автоматическая проверка объёма, задержек и ошибок обмена с уведомлением ответственного при аномалии. Например, алерт в Telegram, если очередь растёт или за час не пришло ни одного события.
Обязательно ли логировать содержимое каждого сообщения?
Нужны как минимум время, отправитель, получатель, ключевые идентификаторы, ответ и число попыток. Полное содержимое полезно для разбора инцидентов, но персональные данные стоит хранить ограниченно и с контролем доступа.
Можно ли повысить отказоустойчивость интеграции без переписывания?
Часто да: очередь, журнал и алерты добавляются поверх существующего обмена. Переписывать имеет смысл, если связи построены «каждая с каждой» и не поддаются сопровождению.
