Как проверить качество работы действующей интеграции

Что значит «интеграция работает хорошо»

Интеграционное тестирование обычно описывают как проверку того, как система взаимодействует с внешними сервисами — CRM, платёжными шлюзами, рассылками: если API принял заказ и списал деньги, но не отправил уведомление клиенту — это баг интеграции [1]. Но для действующей интеграции, которая уже работает в проде, вопрос шире разового теста: важно, что происходит с ней каждый день, под реальной нагрузкой и реальными данными.

Полезно разделить проверку качества на три уровня:

1. Данные и бизнес-логика. Передаются ли нужные поля, в правильном формате, без потерь и задваивания. Соответствует ли то, что видит один участник обмена, тому, что видит другой.
2. Эксплуатационная надёжность. Доступность, скорость ответа, доля ошибок — то, что обычно называют мониторингом и наблюдаемостью (observability).
3. Устойчивость к сбоям. Что происходит, когда один из партнёров недоступен, отвечает с ошибкой или медленно: теряются ли данные, дублируются ли операции, восстанавливается ли обмен автоматически.

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

Как устроен обмен данными между системами

Прежде чем проверять качество, полезно понимать, через что именно идёт обмен — это определяет, где искать проблему.

Типовые архитектуры:

• Синхронный API (REST/SOAP) — запрос-ответ в реальном времени, обычно для операций, где нужен мгновенный результат (проверка остатка, создание заказа).
• Файловый обмен — одна система формирует файл (например, XML в формате CommerceML), другая его забирает и обрабатывает; так исторически устроен обмен 1С с сайтами, где 1С:Предприятие выступает инициатором обмена, устанавливает HTTP-соединение и передаёт XML-сообщения на сайт по правилам стандарта CommerceML 2 [20].
• Очереди сообщений — асинхронный обмен через брокер (Kafka, RabbitMQ, Service Bus), устойчивый к временной недоступности одной из сторон.

Каждая архитектура «ломается» по-своему. В синхронном API проблема — таймауты и деградация под нагрузкой. В файловом обмене — большие архивы, которые не успевают загрузиться или распаковаться, и рассинхронизация, если файл пришёл, но не обработался. В очередях — накопление необработанных сообщений и рост задержки (лага).

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

Российская специфика проверки интеграций

Обмен с 1С

Обмен между сайтом или CRM и 1С чаще всего строится на CommerceML — стандарте обмена коммерческой информацией в XML. Типичные точки отказа, которые стоит проверять в первую очередь:

• Кодировки. CommerceML традиционно передаёт данные в Windows-1251, и если сайт ожидает UTF-8, при обмене начинаются искажения текста [8].
• Блокировки сессий при параллельных запросах. Если файлы сессий хранятся на диске, при одновременных запросах от 1С возникают блокировки, что решается переносом сессий, например, в Redis [8].
• Конфликт одновременного изменения. Если товар меняют одновременно в 1С и на сайте, часть данных может потеряться [8].
• Большие каталоги изображений. При выгрузке от 500 товаров и более архив с картинками может не загрузиться или не распаковаться из-за лимитов хостинга.

При диагностике сбоя важно точно определить, на каком этапе обмен ломается: не зная, на каком именно шаге падает процесс, легко потратить время на исправление не тех ошибок [6]. Практический совет: включить технологический журнал на стороне 1С, а на стороне сайта — HTTP-лог и лог ошибок, чтобы по журналу передачи и точному времени сбоя отличить сбой формата от сетевой проблемы.

Для сложных сценариев (уникальная логистика, нестандартное ценообразование) типовые модули обмена часто не справляются, и требуется разработка отдельного API-шлюза — это дороже и дольше, но даёт гибкость в передаче сложных данных о комплектации, условиях доставки и программах лояльности [7].

Государственные системы и маркировка

Для интеграций с ГИС МТ (система маркировки, «Честный знак»), ФГИС и аналогичными системами добавляется требование по обработке отклонённых документов и защите от повторной отправки: система должна сохранять код и текст ответа рядом с исходным документом, показывать проблемные поля и повторять операцию с защитой от дублей после исправления [21]. Отдельно стоит проверять актуальность версии протокола и статус доступа — наличие документации API ещё не означает, что подключение открыто без договора или дополнительной авторизации.

Персональные данные при обмене

Если через интеграцию передаются персональные данные (ФИО клиентов, контакты, данные сотрудников в HR-интеграциях), проверка качества должна включать не только техническую часть, но и соответствие 152-ФЗ. Внутренний аудит обработки персональных данных обычно строится в несколько этапов — инвентаризация, правовой анализ, техническая оценка и план устранения нарушений, и пропуск любого из этапов создаёт слепые зоны, которые обнаружит регулятор при проверке [13]. Технический аудит систем, через которые проходят персональные данные, рекомендуется проводить не реже раза в квартал [14].

Практическая проверка: что смотреть в первую очередь

Функциональная проверка данных

Проверка не ограничивается тем, «пришёл ли ответ». Нужно смотреть на содержимое: правильные ли поля, нет ли пустых массивов вместо каталога, нет ли скрытой ошибки внутри тела ответа при формально успешном статусе. Эндпоинт может вернуть 200 с пустым массивом вместо каталога или начать отвечать за восемь секунд вместо двухсот миллисекунд — формально всё живо, фактически интеграция уже сломана [4]. Отдельного внимания заслуживают:

• реакция системы на перестановку полей и регистр ключей — если принимающая сторона делает «select \*» вместо обращения по имени ключа, любое изменение во входном запросе сломает интеграцию;
• обработка граничных и некорректных данных — иногда в интеграционном тестировании негативные сценарии важнее позитивных [2].

Обработка ошибок

Хорошая интеграция не просто падает при ошибке 400/500 — она логирует контекст, показывает, что именно не устроило принимающую сторону, и позволяет повторно отправить исправленные данные без дублирования. Это стоит проверить отдельно: сохраняется ли исходный документ при отклонении, виден ли код и текст ошибки, есть ли защита от повторной обработки после исправления [21].

Сверка данных (реконсиляция)

Даже без единой ошибки в логе данные в двух системах могут постепенно расходиться — из-за гонки обновлений, сетевых сбоев или необработанных edge-кейсов. Задача сверки (реконсиляции) — контроль целостности и идентичности данных между системами, и при этом стоит трезво оценивать её пределы: если системы находятся в постоянном движении и обрабатывают большой поток транзакций, добиться нулевого расхождения не получится в принципе — важно минимизировать время до его обнаружения [10]. При интеграции двух систем сверка данных нужна почти всегда, а лучший способ снизить её объём — синхронизировать справочники автоматически, а не сравнивать их вручную постфактум [11].

Мониторинг и метрики действующей интеграции

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

Разумный набор метрик для действующей интеграции:

• Пропускная способность (throughput) — сколько операций проходит за период;
• Латентность, особенно перцентили p95/p99, а не только среднее значение;
• Доля ошибок (error rate);
• Глубина очереди и глубина DLQ — сколько сообщений скопилось необработанными;
• Лаг потребителя — насколько обработка отстаёт от поступления новых данных.

Дополнительно полезны структурированные логи с correlation ID, которые позволяют проследить одну и ту же операцию через все системы, участвующие в обмене. Health checks нужны для автоматических проверок, метрики должны покрывать все аспекты производительности, а логирование должно быть структурированным и контекстным [5].

SLA по интеграции стоит формулировать не абстрактно («работает быстро»), а конкретно и совместно с бизнес-заказчиком: допустимая задержка обработки заказа, максимальное время устранения инцидента, допустимая доля отклонённых документов.

Устойчивость к сбоям

Идемпотентность и защита от дублей

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

Retry и очередь недоставленных сообщений (DLQ)

Не каждая ошибка при передаче — повод считать интеграцию сломанной: временная недоступность одной из сторон — нормальная часть жизни распределённой системы, если есть повторные попытки. Рекомендованная практика — экспоненциальная задержка между попытками с элементом случайности (джиттер), чтобы не перегружать систему повторными запросами [19]. Для сообщений, которые не удалось доставить после исчерпания всех попыток, используется отдельная очередь недоставленных сообщений (DLQ) — она хранит такие сообщения для ручного разбора и не даёт им потеряться безвозвратно; такие сообщения не удаляются автоматически и остаются в очереди, пока их явно не заберут и не обработают [18]. Проверка качества интеграции должна включать вопрос: есть ли вообще такой механизм, или сообщения, которые не прошли с первого раза, просто теряются.

Контрактное тестирование при изменениях

Отдельный риск для уже работающей интеграции — тихая поломка при обновлении одной из систем: провайдер API поменял формат ответа, а потребитель об этом не узнал до продакшена. Контрактное тестирование (Consumer-Driven Contracts, например на базе Pact) фиксирует минимальный набор ожиданий одной стороны к API другой [15] и автоматически проверяет, что обе стороны продолжают этому контракту соответствовать — то есть проверяет и поставщика, и потребителя данных на соответствие контракту именно в точке интеграции [17]. Подход применим не только к HTTP: для очередей сообщений существуют message-контракты, которые проверяют консистентность события, отправленного в Kafka или аналогичный брокер, без запуска реальной очереди [16]. Для команд, которые регулярно обновляют интегрированные системы, это дешевле, чем каждый раз вручную проверять всю цепочку после релиза.

Типичные ошибки и риски

• Проверка только кода ответа, а не содержимого — «200 OK» не означает корректные данные внутри.
• Отсутствие сверки данных — обмен считается рабочим, пока никто не сравнил остатки в двух системах напрямую.
• Нет идемпотентности — повторная отправка после сбоя создаёт дубли вместо исправления.
• Ошибки теряются без следа — нет DLQ или журнала отклонённых документов, воспроизвести проблему постфактум невозможно.
• Мониторинг только по одному показателю — доступность выглядит нормальной, а бизнес уже теряет заказы.
• Обновление одной из систем без проверки контракта — интеграция ломается тихо, пока кто-то не заметит расхождение вручную.
• Игнорирование персональных данных — интеграция технически работает, но нарушает требования 152-ФЗ к их обработке и передаче.

Как выбрать решение: чек-лист, аудит своими силами или внешний аудит

Если объём интеграций небольшой (одна-две системы, невысокая нагрузка), часто достаточно:

• настроить логирование с контекстом и алерты на рост ошибок;
• добавить простую сверку ключевых сущностей раз в сутки;
• проверить обработку повторной отправки данных.

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

Как может помочь «Пятый фактор»

Команда «Пятого фактора» занимается разработкой и интеграцией систем — 1С, CRM, ERP, банковских API и государственных сервисов — и в рамках таких проектов закладывает журнал обмена, проверку статусов и защиту от дублей, а не только первичное подключение. Например, в интеграции с Wialon предусмотрены передача данных о поездках и топливе вместе с настройкой сверки и журнала, в обмене с Workday — журнал обмена и результаты проверки кадровых событий, а в интеграции с СберБизнес API — журналирование запросов и статусов, обновление токенов и заблаговременное уведомление об истекающем сертификате доступа [21]. Если у вас уже есть работающая интеграция и вы не уверены, действительно ли она справляется с задачей, команда «Пятого фактора» может изучить существующий процесс, посмотреть логи и точки обмена данными и предложить, что стоит доработать — от добавления мониторинга до полной пересборки архитектуры обмена, если это оправдано задачей.

Вывод

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

Источники

[1] blog.skillfactory.ru — Как проверить API: чек-лист начинающего тестировщика — https://blog.skillfactory.ru/kak-proverit-api-chek-list-nachinayuschego-testirovschika/

[2] habr.com — Как тестировать методы REST API — https://habr.com/ru/articles/704090/

[3] upscanx.com — Что такое мониторинг API и какие показатели наиболее важны для надежности — https://upscanx.com/ru/blog/what-is-api-monitoring-and-which-metrics-matter-most-for-reliability

[4] prufen.ru — Мониторинг API: как отслеживать доступность endpoint'ов — https://prufen.ru/blog/monitoring-api-kak-otslezhivat-dostupnost-endpointov

[5] lightboxapi.ru — API Monitoring и Logging: как отслеживать здоровье API — https://lightboxapi.ru/blog/api-monitoring-logging-guide

[6] rdn-grp.ru — Обмен данными между 1С и 1С-Битрикс/БУС: коротко о схемах и точках отказа — https://www.rdn-grp.ru/blog/obmen-dannymi-mezhdu-1s-i-1s-bitriks-bus-korotko-o-skhemakh-i-tochkakh-otkaza/

[7] amsales.ru — Интеграция сайта с 1С: настройка обмена без ошибок — https://amsales.ru/journal/integraciya-sayta-s-1c-nastroyka-obmena-bez-oshibok/

[8] avodigital.ru — Интеграция сайта с 1С: настройка синхронизации без ошибок — https://avodigital.ru/blog/integratsiya-sayta-s-1c/

[9] learnixo.io — Lecture 5: System Integration Monitoring — https://learnixo.io/blog/si-monitoring [10] habr.com — Реконсиляция — проверка целостности данных в распределенных системах — https://habr.com/ru/articles/428443/

[11] erp.is1c.ru — Проблемы интеграции 1С: ERP с негибкой системой производственного учета — https://erp.is1c.ru/useful/tpost/gi1627ra21-problemi-integratsii-1s-erp-s-negibkoi-s

[12] animarmedia.com — Виды интеграций между системами 2026: способы и методы — https://animarmedia.com/vidy-integracij/

[13] vitvet.com — Аудит защиты персональных данных: соответствие 152-ФЗ — https://vitvet.com/articles/audit/proverki_operatorov_personalnyh_dannyh/

[14] integrator.digital — Чек-лист проверки сайта на соответствие 152-ФЗ — https://integrator.digital/blog/vse-o-razrabotke-saytov/chek-list-proverki-saita-fz-152-o-personalnyh-dannyh/

[15] habr.com — Consumer Driven Contracts глазами разработчика — https://habr.com/ru/companies/oleg-bunin/articles/452960/

[16] habr.com — Контрактные тесты CDC на Pact — https://habr.com/ru/companies/otus/articles/941366/

[17] habr.com — Контрактные тесты с Pact: гарантия стабильности микросервисов — https://habr.com/ru/companies/kuper/articles/845964/

[18] learn.microsoft.com — Очереди недоставленных сообщений (DLQ) — https://learn.microsoft.com/ru-ru/azure/service-bus-messaging/service-bus-dead-letter-queues

[19] didit.me — Надежность вебхуков: стратегии повторных попыток и DLQ — https://didit.me/ru/blog/mastering-webhook-reliability-retry-and-dead-letter-queue-strategies/

[20] v8.1c.ru — Протокол обмена с сайтом (CommerceML 2) — https://v8.1c.ru/tekhnologii/obmen-dannymi-i-integratsiya/standarty-i-formaty/protokol-obmena-s-saytom/

[21] 5factor.ru — Интеграция Wialon с 1С или TMS; Workday и 1С:ЗУП; True API «Честного знака»; СберБизнес API — https://5factor.ru/