Пятница, 18:40. Сайт работает, формы отправляются, «Спасибо, заявка принята» показывается честно. Но в CRM за сегодня ни одной новой сделки. Кто-то замечает это в понедельник, когда клиент звонит второй раз и говорит, что «вчера писал».
Интеграция почти никогда не ломается в день запуска. Она работает месяц, два, три, а потом «внезапно» перестаёт — точнее, перестаёт быть заметной. Ниже: как именно это происходит, по каким признакам увидеть поломку раньше клиента и что закрепить в договоре, чтобы починка не превращалась в переговоры.
Интеграция — это не функция, а процесс
Функцию написали, проверили, сдали. Процесс живёт во времени: у него есть сроки жизни токенов, лимиты запросов, обновления на другой стороне и растущий объём данных. Всё это меняется без вашего участия.
Поэтому «мы же её внедрили» — не аргумент, а описание старта. Живучесть интеграции определяется не тем, как её написали, а тем, что происходит, когда что-то пошло не так: кто узнал, через сколько и что сделал.
| Как ломается | Что видно снаружи | Что видно в журнале |
|---|---|---|
| Истёк токен | Обмен стоит, ошибок на экране нет | Отказ авторизации на каждом запросе |
| Упёрлись в лимит | Часть заявок есть, часть нет | Серия отказов в пиковые часы |
| Потерян вебхук | Отдельные записи «пропали» | Тишина: события просто не приходили |
| Изменилось API | Записи есть, но с пустыми полями | Ошибок нет — поля приходят пустыми |
| Повтор запроса | Дубли сделок и счетов | Две записи на один идентификатор |
| Обновление системы | Обмен отвалился после апдейта | Ошибки в коде, которого «не трогали» |
Семь причин, по которым обмен умирает через полгода
1. Истёк срок жизни токена
Любая интеграция работает по ключу или токену, и у него есть срок. У локальных приложений Битрикс24 access-токен живёт час, а refresh-токен — 180 дней: если автообновление не реализовано или упало, обмен останавливается, как только refresh-токен истекает или теряется при ротации, — без ошибок на экране.
Признак: обмен замер, но система считает, что всё хорошо. Что делать: автообновление плюс проверка «токен обновился?» с уведомлением ответственному.
2. Лимиты на количество запросов
Пока заявок десять в час, всё нормально. В день распродажи их двести — и часть запросов получает отказ. Интеграция без очереди теряет данные молча, а «потерянные» заявки ищут потом в почте.
Признак: провалы в пиковые дни. Что делать: очередь с повторами и задержкой, а не «отправить и надеяться».
3. Вебхуки — уведомление, а не гарантия
Вебхук стучится в другую систему: «у меня новая заявка». Если принимающая сторона в этот момент недоступна, событие теряется навсегда. Поэтому рядом с вебхуком всегда должна быть сверка: «а что у вас изменилось с прошлого раза».
Признак: единичные пропуски без общих ошибок. Что делать: периодический обмен по расписанию в дополнение к событиям.
4. Изменилось API на другой стороне
Сервис выпустил новую версию, старую отключил, поле переименовал, формат даты поменял. Ваша интеграция продолжает работать — только с пустыми полями. Ошибки нет, данные есть, смысла нет.
Признак: карточки создаются, но без суммы и адреса. Что делать: сверка количества и обязательных полей раз в сутки.
5. Дубли из-за повторов
Запрос ушёл, ответ не пришёл, интеграция повторила — на той стороне появились две сделки или два счёта. Особенно неприятно, когда речь про оплату: клиент платит дважды и звонит с вопросом, на который у поддержки нет ответа.
Признак: дубли с одинаковыми суммами и датами. Что делать: передавать уникальный идентификатор и проверять его перед созданием записи.
6. Никто не смотрит в журнал
Ошибки пишутся в файл, который не открывают. Копятся месяцами. Узнают о них от клиента — и это худший из возможных каналов мониторинга.
Признак: «а почему у меня нет заказа?». Что делать: страница статуса обмена и уведомление при превышении порога ошибок.
7. Обновление затёрло правки
Обновили CMS, плагин, сам портал — и обмен отвалился. Причина в том, что интеграция была сделана «по месту»: правки прямо в шаблоне, в файле чужого модуля, в теме. Любое обновление такие правки перезаписывает.
Признак: поломка сразу после апдейта. Что делать: интеграция живёт отдельно от того, что обновляется — свой модуль или отдельный сервис, который общается по API.
Как узнать первым: три уровня контроля
Контроль не требует отдельной системы мониторинга. Достаточно трёх вещей, каждая из которых делается за час.
- Уведомление о сбое. Любая ошибка обмена — письмо или сообщение в рабочий чат ответственному. Не в файл, а человеку.
- Ежедневная сверка. Раз в сутки скрипт считает записи на обеих сторонах за прошедший день и сравнивает. Расхождение — сигнал, а не «показалось».
- Страница статуса. Один экран: когда был последний успешный обмен, сколько записей прошло, сколько ошибок, какая версия обмена. С закладкой у двух человек, чтобы не искать её во время сбоя.
Хорошая интеграция не та, которая никогда не ломается. Хорошая — та, о поломке которой вы узнаёте раньше клиента, и знаете, что делать в первые пятнадцать минут.
Признаки, что интеграция уже врёт
Эти проверки стоит делать раз в месяц, а не раз в год. Все данные для них уже есть в системах.
| Проверка | Где смотреть | Что значит расхождение |
|---|---|---|
| Заявки за сутки | Формы/почта и CRM | Часть заявок не дошла или дошла дважды |
| Остатки товара | 1С и каталог сайта | Клиент заказывает то, чего нет |
| Статусы заказов | 1С и CRM | Менеджер говорит «в работе», а отгрузки нет |
| Суммы документов | Счета в CRM и 1С | Ошибка в реквизитах или валюте |
| Контрагенты | Справочники двух систем | Дубли и «раздвоенные» истории |
| Последний обмен | Журнал интеграции | Обмен стоит, но никто не заметил |
Сколько стоит день простоя
Простой интеграции почти никогда не считают, а зря — цифра быстро окупает нормальный мониторинг. Возьмём магазин с 20 заказами в сутки и средним чеком 8 000 ₽.
- Обмен с 1С упал на двое суток: 40 заказов не попали в учёт. Часть клиентов получила товар, часть — отказ, третьи ушли к конкуренту. Потеря доверия считается не в рублях заказа, а в повторных покупках.
- Заявки с сайта не доходили неделю: при 15 заявках в день и конверсии 20 % это 21 потерянная сделка — при чеке 8 000 ₽ около 168 000 ₽.
- Дубли счетов: бухгалтерия тратит 3–4 часа на разбор каждого случая, а клиент ждёт возврата.
Отсюда простое правило: мониторинг и сверка стоят несколько часов в месяц, а обнаружение поломки «когда клиент позвонил» — недели работы и потерянные продажи.
Приёмка интеграции: восемь проверок до сдачи
Приёмка — это не демонстрация «смотрите, всё работает». Работающая интеграция на тестовой сделке не значит ничего: обмен чаще всего умирает не на первой сделке, а на трёхсотой, на битой карточке и на второй неделе. Поэтому восемь проверок ниже прогоняют на данных заказчика и смотрят не на результат, а на поведение при ошибке.
| Проверка | Как проверить | Признак, что не сдано |
|---|---|---|
| Массовая выгрузка | Отправить 200–300 записей подряд и засечь время | Очередь встаёт, часть записей доезжает не в том порядке |
| Битая запись в данных | Одна карточка с пустым обязательным полем, один несуществующий товар | Обмен молча пропускает запись: в журнале пусто |
| Повторная отправка | Тот же счёт или сделка уходит дважды | Возникает дубль или второй документ |
| Восстановление после падения | Выключить обмен, изменить 5 записей на одной стороне, включить | Изменения не доезжают или доезжают в одну сторону |
| Просроченный доступ | Перевыпустить токен и посмотреть, что делает обмен | Интеграция встаёт молча, узнаёте от клиента |
| Правка на стороне поставщика | Изменить в справочнике или карточке одно поле | Обмен падает с технической ошибкой без понятного текста |
| Журнал операций | Открыть журнал за вчера не программистом, а руководителем | Нельзя понять, сколько записей ушло, сколько упало и почему |
| Владелец и регламент | Задать вопрос: кто смотрит сверку и что делает при расхождении | Ответа нет — значит, поломку заметят по жалобе клиента |
Если по трём и более пунктам ответ «не знаю» — интеграцию рано принимать, даже когда заявки уже создаются: поломка всплывёт на чужой стороне и не в тот день, когда её удобно чинить.
Почему обмен 1С и Битрикс24 ломается чаще других
Связка CRM с 1С — самая распространённая и самая капризная. Причин три, и все они не про «плохие системы».
- Две правды об одном клиенте. Контрагента правят и в 1С, и в CRM. Если правила «кто главный по какому полю» не описаны, обмен аккуратно переносит вчерашнюю версию поверх сегодняшней.
- Версии модулей. Обмен идёт через модуль, у него есть версия, и она должна быть актуальной на обеих сторонах. Рассинхрон версий даёт ошибки, которые выглядят как «данные не те».
- Справочники не совпадают по смыслу. Номенклатура, склады, единицы измерения, ставки НДС. Формально обмен проходит, фактически остатки и цены расходятся.
Вывод простой: перед тем как чинить код, опишите правила обмена на одной странице — по каждому объекту: кто источник, кто приёмник, что делать при конфликте. Это скучная работа, которая экономит месяцы споров.
Эти проверки делаются на тестовом контуре, но с боевыми данными: реальные заявки, реальные номенклатуры, реальные суммы. На «синтетике» интеграции ломаются ровно там, где вы их не проверили.
| Проверка | Что делать | Норма |
|---|---|---|
| Повторная отправка | Отправить одну и ту же запись дважды | Одна запись, без дубля |
| Недоступность сервиса | Отключить принимающую сторону на 5 минут | Очередь, повтор, запись дошла |
| Истёкший токен | Отозвать доступ и дождаться цикла | Обновление само или понятная ошибка |
| Пустые поля | Отправить запись без суммы и адреса | Отказ с понятным сообщением |
| Объём | Прогнать 1 000 записей подряд | Время в допустимых рамках, без таймаутов |
| Кириллица и спецсимволы | Названия с кавычками, «ё», длинными строками | Данные не искажаются |
| Сверка итогов | Сравнить количество записей на двух сторонах | Расхождение — ноль |
| Откат | Выключить обмен | Системы продолжают работать вручную |
Что зафиксировать в договоре
- Схема обмена: кто, что, когда и в каком направлении передаёт. Таблицей, а не «настроим интеграцию».
- Что считается успехом: не «интеграция работает», а «все заявки за сутки есть в CRM, расхождение — ноль».
- Поведение при ошибке: повторы, уведомления, ответственный, срок реакции.
- Изменение API: кто и за чей счёт адаптирует. Это самый частый спор через год.
- Доступ к журналам: вы должны видеть, что происходит, а не догадываться.
- Тестовый контур и порядок его обновления, чтобы проверка не ломала боевые данные.
Про сроки реакции и приоритеты подробно — в статье SLA в договоре: семь формулировок, которые надо прочитать дважды. Про стоимость самой работы — Сколько стоит интеграция: из чего складывается смета.
Чем чинить: настройка, доработка или свой сервис
Прежде чем звать разработчика, полезно понять масштаб. Обычно проблема решается на одном из трёх уровней.
- Настройка. Обмен настроен неверно, модуль устарел, права не выданы: часто лечится за пару часов в рамках администрирования и обслуживания Битрикс24.
- Доработка. Нужны очередь, повторы, сверка и журнал — то есть обвязка вокруг штатного обмена. Обычно это несколько дней работы.
- Свой сервис или приложение. Если бизнес-процесс не влезает в штатный обмен, делаем локальное приложение для Битрикс24: свои правила, свои экраны, свои журналы.
- Отдельно про заявки с сайта. Если сайт сам теряет данные до CRM, сначала стоит посмотреть на создание сайтов на WordPress и связку форм с порталом.
Частые вопросы
Интеграция работала полгода и вдруг перестала. Что проверить первым?
Три вещи по порядку: последний успешный обмен в журнале, срок жизни токена и были ли обновления на любой из сторон за последние дни. В большинстве случаев причина в одном из этих трёх пунктов, и находится за 15 минут.
Почему пропадает только часть заявок?
Потому что часть событий приходит вебхуками и теряется, когда принимающая сторона недоступна, а сверки нет. Второй вариант — лимиты запросов в пиковые часы. Лечится очередью и регулярным обменом по расписанию.
Нужен ли отдельный сервер для интеграции?
Не всегда. Для обмена между сайтом, CRM и 1С в большинстве случаев достаточно штатных средств плюс небольшая обвязка. Отдельный сервис имеет смысл, когда интеграций много, у них общие правила и нужен единый журнал.
Как часто делать сверку данных?
Заявки и заказы — раз в сутки. Справочники и остатки — по расписанию обмена, но с контролем расхождения хотя бы раз в неделю. Перед крупными акциями сверку стоит делать чаще.
Кто платит за адаптацию, когда поставщик обновил API?
По договору. Если это не прописано, спор почти гарантирован: подрядчик считает это новой задачей, заказчик — гарантией. Разумный вариант: гарантия на N месяцев, дальше — работы по ставке, с приоритетом «сломалось у всех».
Можно ли обойтись без программиста, если обмен настроен штатно?
Пока всё работает — да. Когда ломается, нужен человек, который умеет читать журнал и понимать, где ошибка: в токене, в данных или в коде. Обычно это тот, кто отвечает за портал, а не отдельный разработчик.
Что сделать на этой неделе
- Сравните: сколько заявок пришло по форме за сутки и сколько появилось в CRM.
- Сравните остатки в 1С и в каталоге на сайте — по пяти позициям достаточно.
- Найдите журнал обмена и посмотрите, когда был последний успешный запуск.
- Проверьте, знает ли кто-то, кроме подрядчика, где смотреть статус обмена.
- Добавьте в календарь одну задачу в месяц: сверка и чтение журнала.
«Оно же работало раньше» — не аргумент, а описание нормы. Любая интеграция — живой механизм, который требует проверки хотя бы раз в месяц. Как огнетушитель: скучно, но однажды спасает.
