Мониторинг интеграций Битрикс24: как заметить, что обмен молча остановился

Мониторинг интеграций Битрикс24 строится на простом правиле: для каждой связки (сайт, телефония, мессенджеры, 1С, рекламные формы) вы знаете время последнего успешного события и порог, после которого тишина считается сбоем. Скрипт или робот раз в час сверяет эти отметки и пишет ответственному, если поток данных пропал. Так остановку замечают за часы, без жалобы клиента.

Типичная картина выглядит так. В понедельник утром руководитель отдела продаж видит, что за выходные с сайта не пришло ни одной заявки. Сначала все думают про сезон, потом кто-то открывает форму на сайте, отправляет тестовую заявку и видит, что в CRM она не попадает. Сбой начался в пятницу вечером, когда разработчик сайта обновил плагин. Ошибок никто не видел: сайт показывал посетителям «Спасибо, мы свяжемся», а запрос в Битрикс24 молча падал. Три дня рекламного бюджета ушли в пустоту.

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

Интеграция ломается тихо, потому что сообщение об ошибке получает программа на другой стороне, а не человек. Тихий сбой интеграции — это ситуация, когда обмен данными прекратился, но ни одна из систем не показала сотрудникам предупреждение. Сайт, АТС или учетная система получают ответ с кодом ошибки, записывают его в свой журнал (если вообще записывают) и продолжают работать дальше. Менеджеры в CRM видят просто меньше новых лидов.

Причины почти всегда бытовые. По нашему опыту на проектах B2BPRO.KZ, больше всего остановок дают пять ситуаций:

• уволили сотрудника, от имени которого был создан вебхук;
• сменили пароль или токен на стороне внешнего сервиса;
• обновили сайт, модуль обмена или конфигурацию учетной системы;
• переехал сервер, сменился IP-адрес или закончился SSL-сертификат;
• скрипт уперся в ограничения REST API и стал получать отказы.

С увольнением история особенно коварная. По справке Битрикс24 об увольнении сотрудника, если у человека есть активные вебхуки, администратор выбирает один из двух вариантов: уволить и отключить интеграции или уволить и сохранить их. В первом случае интеграции перестают работать. Во втором они переходят на системного пользователя и продолжают работать. Кадровик, который увольняет менеджера в пятницу вечером, редко понимает, что именно он выбирает в этом окне.

Какие интеграции Битрикс24 останавливаются молча чаще всего

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

Интеграция	Как выглядит тихий сбой	Контрольный сигнал
Формы сайта, вебхук или модуль CMS	Посетитель видит «Спасибо», лид не создается	Время последнего лида с источником «Сайт»
Рекламные лид-формы через коннектор	Заявки остаются в рекламном кабинете	Время последнего лида с источником рекламы
Телефония	Звонки идут, но в CRM нет записей разговоров или самих звонков	Время последнего звонка в журнале CRM
Мессенджеры через открытые линии или коннектор	Клиент пишет, диалог в Битрикс24 не появляется	Время последнего нового диалога
Обмен с учетной системой	Счета, остатки или оплаты перестают обновляться	Дата последнего изменения товаров или оплат
Самописные скрипты на REST	Скрипт падает по расписанию, данные стареют	Отметка «последний успешный запуск»

Обратите внимание на правый столбец. В нем нет ни одной проверки вида «зайти и посмотреть». Каждый сигнал можно получить из данных CRM программно, и в этом весь смысл: проверку делает машина, человек получает только тревогу.

Как настроить мониторинг интеграций Битрикс24 по времени последнего события

Самый надежный способ мониторинга интеграций Битрикс24: регулярно запрашивать время последней записи по каждому каналу и сравнивать его с допустимым интервалом. Метод не зависит от того, как устроена сама интеграция. Вам не нужен доступ к коду сайта или к журналам АТС, достаточно данных, которые уже лежат в CRM.

1. Составьте реестр интеграций. Для каждой запишите: что передает, в какую сущность CRM пишет (лид, сделка, звонок, товар), каким полем ее можно отличить от остальных (источник, тип, ответственный), от чьего имени работает вебхук и кто отвечает за внешнюю сторону.
2. Создайте отдельного технического пользователя для интеграций или хотя бы зафиксируйте, у кого из сотрудников в профиле висят активные вебхуки. Так увольнение перестанет быть сюрпризом.
3. Создайте входящий вебхук с правами только на чтение нужных разделов. По документации Битрикс24 о входящих и исходящих вебхуках, он создается в разделе «Приложения» → «Разработчикам», вкладка «Готовые сценарии» → «Другое» → «Входящий вебхук». Секретный код вебхука нельзя передавать и встраивать в публичный код страниц.
4. Напишите проверку. Для каждого канала она запрашивает одну последнюю запись с фильтром по источнику и сортировкой по дате создания. Один запрос на канал, без выгрузки всех лидов.
5. Задайте порог тишины для каждого канала отдельно (об этом следующий раздел).
6. Настройте отправку тревоги ответственному: в чат Битрикс24, Telegram или на почту. Сообщение должно содержать канал, время последнего события и сколько часов прошло.
7. Запускайте проверку по расписанию раз в 30-60 минут на сервере, где уже работают ваши скрипты, или через сервис автоматизации.

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

Как выбрать порог тревоги, чтобы не получать ложные сигналы

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

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

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

Для каналов с редкими событиями время последнего события не годится. Там помогает контрольная заявка.

Контрольная заявка: проверка всего пути от сайта до сделки

Контрольная заявка — это тестовое обращение, которое скрипт по расписанию отправляет через настоящую форму или настоящий канал, а затем проверяет, появилось ли оно в CRM. Такой подход ловит сбой на любом участке пути: в верстке формы, в плагине, в вебхуке, в роботах CRM.

Как это обычно устроено:

1. Раз в сутки (например, в 8:00) скрипт заполняет форму на сайте тестовыми данными с узнаваемой меткой в имени, например «ТЕСТ-МОНИТОРИНГ».
2. Через 5-10 минут другой запрос ищет в CRM лид с этой меткой.
3. Если лид нашелся, скрипт удаляет его или переводит в отдельную стадию, чтобы тест не попадал в отчеты по продажам.
4. Если не нашелся, ответственный получает тревогу с текстом «форма на сайте не создает лиды».

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

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

Какие ошибки REST API нужно ловить в журналах интеграций

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

Две ошибки встречаются чаще других. По описанию ограничений REST API Битрикс24, портал считает интенсивность запросов: на тарифе «Энтерпрайз» допустимо 5 запросов в секунду, на остальных тарифах 2 запроса в секунду, короткие всплески выше этого допускаются. Когда счетчик переполняется, запрос получает HTTP-код 503 и ошибку QUERY_LIMIT_EXCEEDED. Вторая ошибка связана со временем выполнения методов: если один метод у одного приложения или вебхука накопил слишком много времени работы, следующий вызов получает код 429 и ошибку OPERATION_TIME_LIMIT. Остальные методы и вебхуки при этом продолжают работать, поэтому такой сбой выглядит частичным и его особенно трудно заметить.

Что в журнале	Что это значит	Что делать
503, QUERY_LIMIT_EXCEEDED	Слишком много запросов подряд	Повторять с нарастающей паузой, объединять запросы, не запускать параллельные потоки с одного IP
429, OPERATION_TIME_LIMIT	Метод работал слишком долго в сумме	Дождаться сброса, облегчить запросы: меньше полей, точнее фильтры
Ошибки авторизации	Вебхук отключен или ключ сменился	Проверить владельца вебхука и его статус в профиле сотрудника

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

Контроль обмена данными Битрикс24 с учетной системой

Контроль обмена данными Битрикс24 с учетной системой требует сверки количества, одной отметки времени тут мало. Обмен может работать каждые 15 минут и при этом пропускать часть документов, например все счета определенного типа или контрагентов с незаполненным БИН.

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

Здесь мониторинг упирается в организационный вопрос. Доступ к данным учетной системы обычно есть у бухгалтерии и у ее подрядчика, а доступ к CRM у отдела продаж и у партнера Битрикс24. Сверку проще всего поручить той стороне, которая писала обмен, но результат должен приходить и руководителю. Обмен с учетной системой затрагивает деньги, и узнавать о его остановке из жалобы клиента на неверный счет дорого.

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

Кто разбирает тревогу: роль техподдержки Битрикс24

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

У небольшой компании своего специалиста для этого обычно нет. Чаще всего роль берет на себя техническая поддержка Битрикс24 у партнера: она получает тревоги, сужает область сбоя (портал, внешняя сторона или сеть) и либо чинит сама, либо передает подрядчику сайта или учетной системы с конкретным описанием. Именно так работает техподдержка Битрикс24 24/7 от B2BPRO.KZ: линия принимает обращения круглосуточно, и тревога, пришедшая в субботу ночью, не ждет понедельника.

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

Минимальный регламент разбора тревоги, который мы рекомендуем закрепить письменно:

1. В течение часа ответственный подтверждает, что увидел тревогу.
2. Проверяет вручную: отправляет тестовую заявку, делает звонок, проводит документ.
3. Если сбой подтвердился, сообщает руководителю отдела продаж, чтобы менеджеры проверили почту, рекламный кабинет и другие каналы, куда заявки могли уйти мимо CRM.
4. После починки переносит потерянные заявки вручную и записывает причину в реестр интеграций.

Последний пункт часто пропускают, а зря. Через полгода реестр причин показывает, какая связка ломается регулярно и что в ней пора переделать.

Отдельно продумайте нерабочее время. Заявки с рекламы идут и вечером, и в выходные, а сотрудник, который получает тревогу, в это время спит или отдыхает. Есть два честных варианта. Первый: принять, что ночные сбои разбираются утром, и включить ночную тишину в пороги. Второй: передать тревоги службе, которая работает в режиме 24/7, и договориться, какие сбои она чинит сразу, а какие только фиксирует до утра. Для компаний, у которых реклама крутится круглосуточно, второй вариант обычно окупается первым же предотвращенным эпизодом.

Пример: сколько стоит сбой, который заметили через три дня

Приведем иллюстративный расчет на условных цифрах. Компания в Алматы тратит на контекстную рекламу условные 30 000 тг в день и получает с сайта около 20 заявок в день. Форма перестала передавать заявки в CRM в пятницу в 18:00, заметили сбой в понедельник в 11:00. За это время рекламный бюджет за три дня ушел полностью, а примерно 50 заявок либо потерялись совсем, либо всплыли на почте администратора сайта без ответственного и без задачи.

Даже если часть заявок удалось восстановить из почты, клиенты ждали ответа двое-трое суток, и многие уже купили у конкурентов. При проверке «время последнего лида» с порогом три часа в рабочее время тревога пришла бы в пятницу около 21:00. При ночном исключении из проверки ее увидели бы в субботу утром. В обоих случаях потеря сокращается с трех дней до нескольких часов.

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

Частые вопросы

Как понять, что интеграция с Битрикс24 перестала работать?

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

Можно ли настроить мониторинг интеграций без программиста?

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

Что будет с интеграциями, если уволить сотрудника в Битрикс24?

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

Как часто нужно проверять обмен данными Битрикс24 с учетной системой?

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