Почему ломаются интеграции и как их сопровождать: журнал обмена, повторы, оповещения и обновления 1С

Короткий ответ: интеграция ломается не сама по себе. Её ломают изменения вокруг: обновление 1С, новая версия API у CRM, истёкший токен, новый склад или статус в справочнике, превышенный лимит запросов. Защита закладывается при разработке — журнал обмена, повторная отправка, оповещение ответственному — и поддерживается договором сопровождения с понятными зонами ответственности.

Эта статья про эксплуатацию: что происходит с работающей связкой — скажем, между CRM и 1С, — через полгода после запуска и как устроить, чтобы сбой обнаружили вы, а не ваш клиент. Как устроен обмен с 1С по технологиям, мы разбирали в статье о CommerceML, OData и HTTP-сервисах, а механику вебхуков — в разборе вебхуков простыми словами.

Почему перестаёт работать интеграция, которую никто не трогал?

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

1. Обновление 1С

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

2. Изменения на стороне CRM и сервисов

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

3. Истёкший токен или отозванный доступ

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

• В amoCRM refresh token действует 3 месяца и обменивается только один раз; если интеграция за это время ни разу не обращалась к API, доступ теряется. Долгосрочный токен пользователь создаёт сам на срок от 1 дня до 5 лет — и через выбранный срок он перестаёт работать (документация amoCRM по OAuth).
• В Битрикс24 access token живёт один час, refresh token — 180 дней (документация Битрикс24 по OAuth). Входящий вебхук выполняет запросы с правами сотрудника, который его создал, а если администратор отредактирует чужой вебхук, его секретный код обновится, а владельцем станет администратор; у вебхука можно задать срок действия, после которого запросы получают ошибку авторизации (описание локальных вебхуков).

Отсюда бытовые сценарии: уволили сотрудника, под чьей учёткой создан вебхук; администратор «навёл порядок» в выданных доступах; токен на год выпустили при запуске и забыли.

4. Новое значение в справочнике

Компания открыла второй склад, добавила организацию, ввела статус сделки «Ждём предоплату» или вид оплаты «Рассрочка». Интеграция не знает, куда отнести новое значение, и либо падает с ошибкой, либо молча кладёт запись не туда. Это не ошибка кода в привычном смысле: правило сопоставления для нового значения никто не задавал. Отдельный частый случай — дубли контрагентов и товаров; как их разбирать, описано в статье о дублях в CRM и 1С.

5. Лимиты запросов

У каждой системы есть ограничение на частоту обращений. amoCRM принимает не более 7 запросов в секунду от одной интеграции и до 50 на весь аккаунт; при превышении отвечает кодом 429, а при многократных нарушениях блокирует аккаунт: на любой запрос к API приходит код 403 (рекомендации amoCRM). В Битрикс24 на обычных тарифах счётчик убывает на 2 запроса в секунду и блокирует при пороге 50, причём приложения на одном сервере, работающие с одним порталом, делят общий лимит (лимиты Битрикс24). На запуске с тысячей товаров лимит не мешает, а через год с двадцатью тысячами и ночной выгрузкой цен — уже да.

Что вы видите	Вероятная причина	Что проверить первым	Кто обычно чинит
Обмен встал целиком на следующий день после обновления 1С	Изменились объекты, реквизиты или типовая обработка обмена	Дату установки релиза и первую ошибку в журнале после неё	Программист 1С вместе с разработчиком интеграции
Всё работало месяцами и вдруг ошибки авторизации	Истёк токен или ключ, отозван доступ, сменился секретный код вебхука	Срок токена, раздел выданных доступов в CRM, учётную запись интеграции	Владелец CRM выдаёт доступ, разработчик подключает
Часть записей проходит, часть нет	Новое значение справочника, пустое обязательное поле, новый склад или организация	Текст ошибки по конкретной записи и чем она отличается от прошедших	Тот, кто завёл значение, и разработчик — для сопоставления
Ошибки только в часы пик или при массовой загрузке	Упёрлись в лимит запросов API	Коды ответа 429 и 503 в журнале, время ошибок	Разработчик интеграции
Ошибок нет, но данных тоже нет	Процесс обмена остановлен, сервер недоступен, вебхук отключён	Время последней успешной операции	Разработчик или тот, кто отвечает за сервер

Как понять, что обмен встал, если вы не программист?

Смотрите не на ошибки, а на время последней успешной операции. Если заказы с сайта обычно приходят в 1С каждые несколько минут, а последний пришёл вчера — обмен стоит, даже если никаких сообщений об ошибках нет. Это одна цифра, и её можно вывести вам в оповещение или на страницу состояния.

Признаки, которые замечают без доступа к серверу:

• Цифры перестали сходиться. Сумма оплат за день в CRM меньше, чем в банковской выписке в 1С; остаток на сайте не совпадает со складом.
• Менеджеры начали вносить руками. Если сотрудник «на всякий случай» сам завёл заказ в 1С, спросите почему: часто он заметил сбой раньше всех и не сказал.
• Тишина там, где обычно шумно. В рабочий день ни одного уведомления о новой оплате — повод проверить, а не порадоваться.
• Повторы. Клиенту пришло два одинаковых письма или в 1С два одинаковых документа: обмен повторяет отправку, но не узнаёт уже обработанное.

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

Что заложить в интеграцию с первого дня?

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

• Журнал обмена. Каждая операция: что передавалось, откуда, куда, когда, чем закончилось. Ошибка — словами, которые поймёт бухгалтер: «Контрагент без ИНН, заказ 1452 не создан», а не код исключения.
• Повторная отправка. Упавшая запись остаётся в очереди и повторяется сама через увеличивающиеся интервалы; после исправления причины её можно отправить заново кнопкой. Каждую запись узнают по номеру, чтобы повтор не создал второй документ.
• Оповещение. Ответственный получает в Telegram или на почту сообщение с причиной и ссылкой на запись, а не «что-то сломалось». Отдельно — оповещение о тишине: долго нет ни одной успешной операции.
• Сверка по расписанию. Раз в сутки программа сравнивает количество заказов или оплат в двух системах и присылает расхождение. Она ловит то, что не поймал журнал.
• Доступы на компанию. Отдельный пользователь 1С и отдельная учётка или приложение в CRM под интеграцию, с минимальными правами и записанным сроком токена. Не личный аккаунт сотрудника.
• Описание обмена. Одна-две страницы: какие объекты и поля, какой способ, по какому расписанию, какие справочники сопоставлены. С ним новый специалист разбирается за час.

В тарифе интеграций по нашему прайсу обработка ошибок обмена, логирование операций, уведомления по событиям и инструкция «как работает обмен и что делать при сбое» входят в базовый объём. Пример автотеста обмена с 1С, который по шагам проверяет создание товара, обновление по артикулу, скрытие товара без цены до загрузки цен и защиту заказов от повторной выгрузки, — в кейсе AleksFurs.

Кто за что отвечает: подрядчик, франчайзи 1С, владелец CRM?

У работающей интеграции почти всегда три стороны: разработчик связки, специалист по 1С и сотрудник, который администрирует CRM. Сбои затягиваются, когда каждый уверен, что вопрос не его. Распределите участки письменно — хватит таблицы ниже, приложенной к договору или регламенту.

Главное правило: о любом изменении, которое затрагивает обмен, стороны предупреждают друг друга заранее. Обновление 1С, новый склад, смена тарифа CRM, увольнение администратора — повод написать разработчику интеграции до, а не после.

Участок	Подрядчик по интеграции	Франчайзи или программист 1С	Владелец CRM у заказчика
Код обмена, журнал, повторы, оповещения	Отвечает	Не участвует	Получает оповещения
Обновление конфигурации 1С	Проверяет обмен на копии после релиза	Ставит релиз, сначала на копию	Согласует дату
Доработки и расширения 1С, HTTP-сервисы	Ставит задачу и проверяет стык	Отвечает	Не участвует
Пользователи, права, токены и вебхуки CRM	Подсказывает, какие права нужны	Не участвует	Отвечает, ведёт список выданных доступов
Новые справочники: склады, организации, статусы	Добавляет сопоставление	Заводит в 1С	Заводит в CRM и предупреждает заранее
Сервер, домен, сертификат	Отвечает, если сервер его	Отвечает за сервер 1С	Продлевает подписки и оплачивает сервисы

Что делать в первый час после сбоя?

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

1. Откройте журнал: время последней успешной операции и текст первой ошибки. Скопируйте его целиком.
2. Вспомните, что менялось за последние сутки: обновление 1С, права пользователей, новые значения справочников, оплата подписок.
3. Договоритесь внутри: пока обмен стоит, менеджеры записывают заказы в отдельный список, а не дублируют их в 1С руками.
4. Поставьте задачу разработчику с текстом ошибки и временем. Чем точнее данные, тем быстрее разбор.
5. После исправления причины отправьте упавшие записи из очереди повторно и сверьте итог: число заказов или оплат за период в обеих системах.
6. Запишите, что произошло и что изменить, чтобы не повторилось: оповещение, правило сопоставления, напоминание о сроке токена.

Что покрывает гарантия, а что — поддержка?

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

Для интеграций это различие принципиально. Если обмен упал из-за ошибки в нашем обработчике — это гарантия. Если франчайзи поставил новый релиз 1С, CRM изменила API или в справочнике появился новый склад — это работа по адаптации, то есть поддержка.

• Первые 7 дней после запуска мелкие правки по тарифу интеграций бесплатны — это время, когда всплывают пограничные случаи реальных данных.
• Дальше — абонентка или разовые задачи. Поддержка стоит от 7 900 ₽ в месяц, состав считаем после брифа. Абонентка подходит, когда обмен ежедневно переносит заказы, оплаты или остатки и его остановка стоит денег.
• Разовые задачи — когда связка простая и меняется редко: платите за конкретную адаптацию.

Что прописать в договоре поддержки — время реакции, приоритеты, бэкапы, выход из договора, — разобрано в статье о договоре на поддержку и SLA. Для интеграции добавьте туда два пункта: кто следит за изменениями API сторонних систем и кто проверяет обмен после обновления 1С.

Чек-лист после обновления 1С

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

1. Разработчик интеграции знает дату обновления заранее, хотя бы за пару рабочих дней.
2. Релиз сначала ставят на копию рабочей базы, а не сразу в рабочую.
3. На копии прогоняют обмен по всем направлениям: выгрузку товаров и цен, остатки, приём заказа, оплаты, статусы.
4. Проверяют доработки: всё, что сделано в расширениях, подключилось без ошибок; всё, что сделано в самой конфигурации, перенесено.
5. Пользователь интеграции в 1С сохранил свои права и не потребовал смены пароля.
6. После установки в рабочую базу в течение первого дня смотрят журнал и время последней успешной операции.
7. Через сутки сверяют итоги: число заказов и сумму оплат в 1С и в CRM или на сайте за этот день.
8. Если что-то сломалось — записывают причину в описание обмена, чтобы в следующий раз проверить этот пункт первым.

Когда отдельное сопровождение не нужно и какие ошибки встречаются?

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

Ещё случаи, когда отдельное сопровождение не нужно:

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

Ошибки, которые встречаем чаще всего:

• Интеграция на личной учётке. Сотрудник уволился, учётку отключили — обмен встал.
• Оповещения уходят в никуда. На ящик бывшего сотрудника или в чат, который никто не читает.
• Обновление 1С без предупреждения. Франчайзи сделал свою работу, о стыке никто не подумал.
• Журнал есть, но не читается. Тысячи строк технических сообщений без поиска по номеру заказа.
• Ручная правка поверх обмена. Пока связка стояла, данные внесли руками, а после исправления обмен довёз их ещё раз.

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

Короткие ответы на частые вопросы

Почему интеграция с 1С перестала работать, если её никто не трогал?

Чаще всего трогали соседей: обновили 1С, сменили права пользователя, завели новый склад или статус, истёк токен CRM. Сама связка не меняется, меняется то, с чем она работает. Начните с даты последней успешной операции и того, что изменилось накануне.

Как узнать, что обмен 1С и CRM идёт штатно?

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

Гарантия разработчика покрывает сбой после обновления 1С?

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

Нужна ли абонентская поддержка интеграции?

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

Кто должен обновлять 1С, если есть интеграция?

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

Услуги и кейсы по теме: интеграция с 1С и CRM от 32 000 ₽ · поддержка сайта от 7 900 ₽/мес · кейс AleksFurs · цены и сроки