Интеграция с CRM: почему она ломается через полгода и как это заметить

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

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

Почему интеграция с CRM ломается: поменялись поля на той стороне

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

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

Истёк или сменился доступ

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

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

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

Выросли объёмы

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

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

Поменялся процесс, а интеграцию не тронули

Самая частая и самая обидная причина. Отдел начал вести сделки по-новому: добавили стадию, изменили правило распределения, стали заводить клиента иначе. Интеграция продолжает делать то, о чём договаривались полгода назад, и с точки зрения кода она исправна — просто её работа больше не соответствует тому, как работают люди.

Технически здесь чинить нечего. Лечится только тем, что при изменении процесса кто-то вспоминает про интеграции — то есть у них должен быть владелец.

Как сделать интеграцию, которая сообщает о поломке

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

• Сигнал о тишине: если за сутки не прошло ни одной записи, а обычно проходят десятки, система должна написать человеку. Это ловит большинство поломок.
• Повторные попытки при сетевых сбоях и отдельное уведомление, когда попытки исчерпаны.
• Регулярная сверка: раз в сутки сравнить количество записей на обеих сторонах и сообщить о расхождении.
• Уведомления туда, где их увидят: мессенджер, а не лог-файл на сервере.

Как проверить свою интеграцию сегодня

• Когда последний раз через неё проходили данные? Если не знаете, где это посмотреть, — это и есть ответ.
• Сравните количество записей за вчера на обеих сторонах. Расхождение должно быть нулевым.
• Узнайте, под чьей учётной записью она работает. Если под конкретным сотрудником — запланируйте перевод на служебную.
• Спросите, что произойдёт, если внешний сервис будет недоступен три часа. Ответ «данные подтянутся позже» проверьте на практике.

Интеграция — не разовая работа, а часть инфраструктуры. Она требует не обслуживания, а всего лишь способности сказать, что у неё что-то не так. Без этого о поломке вы узнаете от клиента, и обычно самым неприятным способом.