Пакет диагностики для передачи интеграционного сбоя
Версия 2.7
Опишите пользовательский эффект
Укажите, что оператор или покупатель не смог сделать, в какой среде и за какой период. Отдельно отметьте число затронутых складов и тип операции. «Не обновился статус в магазине» и «статус отсутствует в RouteDesk» приводят к разным проверкам. Если ошибка массовая, проверьте страницу статуса в кабинете и зафиксируйте наблюдение с временем.
Соберите минимальную цепочку доказательств
Запишите номер отправления или event_id, дату и часовой пояс, код ошибки и последний успешный шаг. Для запроса создания добавьте локальный номер задания и время попытки. Для webhook укажите настроенный адрес без чувствительных частей, код HTTP-ответа и наличие события в очереди. Приложите компактную последовательность «ожидали → получили → проверили».
Что скрыть перед отправкой
Удалите из материалов значения API-ключей, секретов webhook, заголовков Authorization и одноразовых кодов. В скриншотах закройте имя, контакты, адрес получателя и финансовые реквизиты. Для воспроизведения используйте синтетическую строку заказа или минимальное тестовое событие. Поддержка может начать диагностику по идентификаторам и времени.
Маршрут обращения
При подозрении на компрометацию или недоступности выпуска для всей организации опишите масштаб и передайте случай приоритетно. Для обычной задержки отдельной посылки начните с истории отправления. Если обращение уже есть, добавьте сведения в его карточку. Запишите, какие действия уже были выполнены и какие попытки приостановлены до ответа специалиста.
Пример полезной передачи
Пример: «Рабочий контур, склад Б. В 16:40 по местному времени перестали обновляться статусы в магазине. В кабинете событие видно. Журнал доставок показывает 2xx, а задача по event_id остаётся в очереди. Последний успешный импорт статуса был в 16:35». Такой набор помогает проверить внутренний обработчик. Полное тело и секрет webhook для первого разбора не нужны.
Что добавить при повторном обращении
Сошлитесь на предыдущую карточку, обновите время последнего наблюдения и опишите новое обстоятельство. Если после изменения настройки ошибка проявляется иначе, покажите успешный и неуспешный этап отдельно. Для затяжного сбоя отметьте, какие заказы уже восстановлены, какие продолжают ждать и кто контролирует отложенные повторы.
Завершение передачи между командами
Убедитесь, что получатель видит конкретное следующее действие. При успешном приёме webhook и незавершённой записи направьте проверку владельцу внутренней очереди. При неизвестном исходе выпуска передайте задачу дежурному, который сверяет кабинет и идентификатор запроса. После подтверждения результата сохраните его рядом с историей обращения, чтобы следующая смена не запускала повторную операцию.