Диагностика обмена: найти один заказ среди миллиона событий

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

Наблюдаемость начинается до первой ошибки. Если разные компоненты пишут свободный текст без общего идентификатора, после аварии остаётся поиск по номеру заказа и времени «примерно после обеда». Вместо этого каждое бизнес-событие получает correlation ID, который проходит через сайт, прокси, HTTP-сервис, очередь и созданный документ.

Одна строка журнала — одно событие

Запись должна быть структурной: время, интеграция, correlation ID, event ID, этап, результат, длительность и безопасный код ошибки. Текстовое пояснение остаётся, но не заменяет поля. Тогда журнал можно агрегировать, а не только читать глазами.

{
  "integration": "web-orders",
  "correlation_id": "corr-8ca31",
  "event_id": "b861b9f0-6d84-4d5f-91cc-3c09863a91c3",
  "stage": "create_order",
  "result": "rejected",
  "error_code": "SKU_NOT_MAPPED",
  "duration_ms": 184,
  "payload_hash": "sha256:51d9…"
}

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

Три панели для разных ролей

Бизнес видит долю доставленных заказов и задержку от оплаты до появления документа. Поддержка ищет по order ID или correlation ID и видит этапы. Разработчик получает технические метрики: коды ответов, длительность зависимостей, число повторов и глубину очереди. Одна перегруженная панель не обслужит все три задачи.

Для web-orders определим сервисный уровень: 99% корректных событий создают заказ не дольше пяти минут. Он измеряется от occurred_at отправителя до времени записи документа, а не от старта фонового задания. Иначе очередь может сутки ждать, но локальная обработка покажет прекрасные 200 миллисекунд.

Разбираем инцидент по временной линии

09:41:12 — сайт сформировал событие.
09:41:13 — 1С ответила 202 и сохранила входящее сообщение.
09:41:16 — обработчик не нашёл соответствие SKU и отправил запись в карантин.
10:07:02 — оператор добавил соответствие и сформировал новую попытку.
10:07:04 — документ создан; ссылка записана рядом с event ID.

Такая линия сразу отделяет задержку системы от задержки ручного решения. Она также показывает, что повтор был осознанным, а не случайным.

Безопасное воспроизведение

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

После исправления инцидент заканчивается не фразой «починили», а новой защитой: тестом контракта, алертом на возраст карантина, ограничением повтора или уточнением инструкции оператору. Иначе журнал лишь документирует будущий повтор проблемы.

Проверка готовности: дайте коллеге только correlation ID тестового заказа. Если он без вашей помощи находит все этапы, причину остановки и конечный документ, диагностика выполняет свою работу.