История обменов и база данных: как контролировать все интеграции

Знакомая ситуация: пятница, вечер, и вдруг выясняется, что заказы из интернет-магазина перестали попадать в CRM. Менеджеры узнали об этом случайно, когда клиент позвонил с вопросом «а где мой заказ?». Когда сломалось — непонятно. Что именно пошло не так — загадка. Кто виноват — вообще отдельный вопрос.

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

В CrmAI мы подошли к этой проблеме серьёзно. Система логирует каждый API-вызов, каждый обмен данными с внешними сервисами. Не просто факт «был обмен», а полную картину: что отправили, что получили, сколько времени заняло, какой был результат. Когда возникает сбой, вы видите его сразу, а диагностика занимает не часы, а секунды.

Что логируется в системе

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

• Входящие вызовы — webhook от мессенджеров, заказы из интернет-магазинов, уведомления от платёжных систем
• Исходящие запросы — отправка данных в 1С, выгрузка товаров на маркетплейсы, передача информации в службы доставки
• Синхронизация — двусторонний обмен контактами, товарами, остатками между системами
• Email-отправки — маркетинговые рассылки и транзакционные письма (подтверждения заказов, уведомления о статусах)
• SMS и push-уведомления — все сообщения, которые уходят клиентам через мобильные каналы

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

Структура записи лога: что именно сохраняется

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

• Timestamp — точное время операции вплоть до миллисекунд. Это критично, когда нужно понять последовательность событий
• Направление — входящий или исходящий вызов. Важно для понимания, кто инициатор обмена
• Источник и получатель — откуда пришли данные и куда ушли. Например: «Wildberries → CrmAI» или «CrmAI → 1С»
• Тип операции — создание новой записи, обновление существующей или удаление
• Статус выполнения — успех, ошибка или ожидание повторной попытки
• Payload — полное тело запроса и ответа. Видите не просто «был запрос», а конкретно какие данные передавались
• Код и текст ошибки — если что-то пошло не так, сразу видна причина: «401 Unauthorized», «Timeout», «Invalid JSON» и т.д.

Такая детализация позволяет не гадать, а точно знать. Когда разработчик на стороне интернет-магазина говорит «мы всё отправили правильно», вы можете открыть лог и показать, что именно пришло. Это экономит часы на выяснение отношений и поиск виноватых.

Диагностика сбоев: от паники к решению за минуты

Допустим, интеграция сломалась. Раньше это означало: звонки программистам, переписка с техподдержкой внешнего сервиса, несколько часов неизвестности. С историей обменов сценарий совсем другой.

Открываете журнал и сразу применяете нужные фильтры:

• Фильтр по статусу — показываете только ошибки, отсекая сотни успешных операций
• Фильтр по источнику — например, только обмены с 1С или только заказы с Ozon
• Фильтр по времени — за последний час, день или конкретный период
• Просмотр payload — смотрите, что именно отправили и что получили в ответ
• Повторная отправка — если проблема была временной, делаете retry одним кликом

Разница колоссальная. Вместо абстрактного «где-то что-то сломалось» вы видите конкретику: «15:42, запрос к 1С, ошибка 500, в ответе текст "Сервер недоступен"». Дальше уже понятно, куда копать — это проблема на стороне 1С, а не в вашей CRM.

Мониторинг в реальном времени: пульс ваших интеграций

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

Один взгляд на экран — и вы понимаете, всё ли в порядке:

• Количество обменов за период — видите общую активность системы
• Процент успешных операций — если обычно 99,5%, а сегодня 94% — что-то явно не так
• Средняя скорость ответа — замедление часто предшествует сбоям
• Топ ошибок — какие проблемы встречаются чаще всего
• График по времени — визуально видно, когда начались проблемы

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

Алерты о проблемах: узнавайте первыми

Самое неприятное — узнать о сбое от клиента. Он звонит, ругается, а вы понятия не имеете, о чём речь. Это не только портит отношения с клиентом, но и выглядит непрофессионально.

Система алертов решает эту проблему. Вы настраиваете правила, и при их срабатывании приходит уведомление:

• Email-алерт — при критических ошибках, которые требуют немедленного внимания
• Telegram-уведомление — в рабочий чат команды для оперативного реагирования
• Гибкий порог срабатывания — например, алерт при более чем 5 ошибках в час или при падении успешности ниже 95%
• Расписание уведомлений — можно ограничить только рабочими часами, чтобы не будить ночью из-за некритичных проблем

Результат: вы узнаёте о проблеме раньше, чем клиент. Иногда — до того, как она вообще на кого-то повлияла. Это совсем другой уровень контроля над бизнес-процессами.

Автоматический retry: второй шанс для каждого запроса

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

В CrmAI реализован механизм автоматических повторных попыток для временных сбоев:

• Автоповтор с нарастающим интервалом — система делает 3 попытки: сразу, через 30 секунд, через 2 минуты. Это позволяет переждать кратковременные сбои
• Очередь отложенных задач — если все попытки неуспешны, задача не теряется, а попадает в очередь на ручную обработку
• Ручной retry — для сложных случаев, когда нужно сначала разобраться в причине и только потом повторять
• Отмена операции — если данные уже неактуальны, можно отменить задачу, чтобы не засорять систему

На практике это означает, что 90% временных сбоев система обрабатывает сама, без вашего участия. Вы даже не узнаете, что была проблема — она решилась автоматически. В лог попадёт запись «успех со второй попытки», и всё.

Хранение и архивация: данные не пропадут

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

Мы нашли баланс с многоуровневой системой хранения:

• Горячее хранение — 30 дней. Полный поиск, мгновенный доступ, вся детализация. Этого обычно хватает для оперативной работы
• Архивное хранение — до 1 года. Данные сжимаются, но остаются доступны для анализа. Полезно для аудита и разбора старых инцидентов
• Экспорт в CSV и JSON. Если нужно проанализировать данные внешними инструментами или передать кому-то для разбора
• Автоматическая очистка. По истечении срока хранения данные удаляются автоматически, не нужно следить вручную

Для компаний с особыми требованиями к хранению данных (например, в регулируемых отраслях) сроки можно настроить индивидуально.

Реальный кейс: как история обменов спасла ситуацию

Недавно к нам обратился клиент с паникой: «Заказы с сайта не попадают в CRM уже сутки!» Первое, что мы сделали — открыли журнал обменов.

Картина стала ясна за пару минут. Последний успешный обмен был вчера в 14:32. После этого — серия ошибок с кодом 401 (авторизация не прошла). Что случилось? Оказалось, что интернет-магазин обновил API и сбросил токены доступа. Техподдержка магазина забыла предупредить клиента.

Благодаря сохранённым данным мы точно знали момент поломки и причину. Новый токен был сгенерирован за 5 минут, все отложенные заказы — обработаны автоматически через retry. Проблема, которая могла растянуться на дни разбирательств, решилась за полчаса.

Что вы получаете в итоге

История обменов — это не просто техническая функция для программистов. Это инструмент, который меняет подход к работе с интеграциями:

• Полный журнал всех обменов — знаете, что происходит с вашими данными на каждом этапе
• Диагностика сбоев в один клик — не тратите часы на поиск причины, а сразу видите проблему
• Проактивные алерты — узнаёте о проблемах раньше, чем они повлияют на клиентов
• Автоматический retry — система сама справляется с большинством временных сбоев
• Доказательная база — при спорах с подрядчиками у вас есть факты, а не догадки

Это переход от реактивного реагирования («что-то сломалось, надо срочно чинить») к проактивному контролю («всё работает, и я это вижу»).