API вернул 200, а данные разошлись: как построить сверку интеграций
Как находить потерянные и расходящиеся записи между CRM и ERP: эталон данных, окно сверки, версии, классификация расхождений и безопасное исправление.
Содержание
В журнале нет ошибок: API отвечает успешно, очередь разобрана. Однако заказ существует в CRM и отсутствует в ERP, а в отчёте отображается вчерашний статус. Транспортные метрики показывают движение запросов. Чтобы проверить результат обмена, нужна отдельная сверка бизнес-объектов.
Назначьте источник истины для каждого поля
Одна система не обязательно владеет всей записью. CRM может отвечать за контакт клиента, ERP — за состояние отгрузки. Зафиксируйте владельца, бизнес-ключ, правила преобразования и допустимую задержку каждого значимого поля.
Свяжите внешний ID с постоянным внутренним ключом. Учитывайте объединение дублей, удаление и повторное создание объекта. Сравнение по имени или номеру строки даёт ложные совпадения.
Перед сравнением нормализуйте представление: часовые пояса, пустые значения, регистр там, где он незначим, точность сумм и порядок элементов. Правило нормализации должно быть общим для сверки и интеграционного контракта.
Сравнивайте согласованный срез
Если CRM изменилась во время выгрузки ERP, разные значения ещё не означают потерю события. Определите контрольный момент, версии объектов и период допустимого отставания.
При наличии согласованных snapshot или watermark используйте их. В других случаях выбирайте записи, не изменявшиеся дольше допустимой задержки, повторяйте проверку кандидатов и сохраняйте версии обоих чтений. Один локальный timestamp не доказывает порядок событий в разных системах.
Для больших объёмов делите данные по устойчивому ключу и периоду. Контрольные суммы разделов помогают сузить поиск, но требуют одинаковой канонизации и не заменяют разбор конкретных записей.
Разделяйте причины расхождений
| Класс | Что выяснить |
|---|---|
| Запись отсутствует | Событие потеряно, отложено или было отклонено |
| Версия отстаёт | Есть ли очередь и допустима ли задержка |
| Поля различаются | Кто владеет значением и совпадают ли преобразования |
| Лишняя запись | Был ли дубль, удаление или изменение области выборки |
Сохраняйте ID запуска сверки, ключ объекта, версии, тип различия и ссылку на исходное событие. Не переносите полные персональные данные в диагностический журнал, если для расследования достаточно идентификаторов.
Сверка дополняет наблюдаемость инфраструктуры: зелёный график HTTP-запросов может соседствовать с растущим числом несогласованных заказов.
Исправляйте через обычный процесс записи
Не превращайте сверку в ночной скрипт, который вслепую перезаписывает принимающую базу. Подготовьте план исправления: объект, обнаруженная версия, ожидаемая версия и причина. Сначала выполните dry-run и оцените область изменений.
Перед применением повторно проверьте версию. Если пользователь уже изменил запись, старый план должен остановиться или уйти на разбор. Повторная обработка обязана быть идемпотентной и не создавать повторные отгрузки или уведомления.
При возможности повторите исходное событие через штатный обработчик. Для потерянных событий полезен transactional outbox, но даже такой журнал не отменяет контроль конечного результата. Смена структуры данных требует отдельного плана миграции схемы.
Задайте критерий завершения
Измеряйте число расхождений по возрасту, объектам и причинам, объём непроверенных данных и долю успешно исправленных записей. Отдельно отслеживайте повторное появление уже исправленной ошибки.
Запуск завершён, когда проверены все запланированные разделы, кандидаты перепроверены, а неустранённые случаи имеют владельца. Начните с одного критичного потока, например «заказ — отгрузка», и проверьте потерю события, повтор, изменение во время сверки и отказ одного источника. Так интеграция получает измеримый результат обмена, а не только счётчик успешных запросов.
