Ozon 28 августа сообщил о системе автоматического мониторинга адресов, на которые Seller API отправляет push-уведомления. По сообщению площадки, она отслеживает доступность вебхуков и предупреждает о проблемах. Для продавца это дополнительный сигнал о состоянии интеграции, через которую внешняя система получает события маркетплейса.

Почему доступность адреса важна для бизнеса

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

Новый мониторинг относится к доступности адресов приёма. Из объявления нельзя сделать вывод, что Ozon проверяет корректность всех внутренних действий CRM или ERP. Сервер может успешно принять запрос, а последующая обработка — завершиться ошибкой. Поэтому контроль площадки полезно дополнять проверкой того, что принятые события дошли до нужной рабочей очереди.

Какие сигналы собирать в своей системе

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

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

Как подготовиться к сбою обработчика

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

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

Кому передавать уведомления о проблеме

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

После устранения сбоя сверяйте полноту данных с доступным источником на площадке за проблемный интервал. Статус «сервер снова отвечает» ещё не доказывает, что очередь обработана полностью. Польза обновления Ozon в более раннем обнаружении недоступности, а устойчивость всей интеграции зависит от хранения событий, повторной обработки и проверяемого восстановления.