Когда операция магазина проходит через несколько сервисов, сообщение об ошибке в конечной системе ещё не указывает на место сбоя. Команда Ozon Tech в кейсе от 23 декабря 2024 года описала карту связей между внешними методами Seller API и внутренними сервисами. Разбираем инженерный принцип этого решения и его применение на стороне интеграции продавца, не предполагая доступа магазина к внутренним инструментам Ozon.

Почему одной трассировки было недостаточно

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

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

Опишите маршрут своей бизнес-операции

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

На каждой доступной границе определите признак принятия и признак завершения. HTTP-ответ от принимающего сервера и появление заказа в рабочей очереди — разные события. Эта разница также важна для мониторинга вебхуков Ozon. Проверка доступности адреса полезна, но не заменяет наблюдение за внутренней обработкой продавца.

Свяжите технический сигнал с затронутыми задачами

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

Храните только необходимые идентификаторы и технические признаки. Секреты подключения и полное содержимое клиентских сообщений не должны попадать в общедоступную диагностическую таблицу. Назначьте владельца карты и дату обновления. Старая схема после смены интеграции может направлять расследование не в ту систему и создавать ложную уверенность, что все зависимости уже известны.

Проверяйте гипотезу наблюдаемым результатом

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

После исправления проследите одну контрольную операцию до рабочего результата и проверьте накопившиеся задачи. Зафиксируйте подтверждённую причину и изменившийся участок маршрута. Кейс Ozon Tech показывает способ сделать зависимости видимыми команде; для магазина ценность появляется тогда, когда это знание сокращает неопределённость конкретного сбоя и помогает проверить восстановление всей операции.