Postmortem потери конверсий: как разобрать инцидент без поиска виноватого

Редакция mevrica

Рекламные технологии4 мин чтения

Обновлено 2 августа 2026 г.

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

Главный принцип

Отделяйте наблюдаемые факты от гипотез. «После релиза исчезли approved» — наблюдение. «Разработчик сломал postback» — неподтверждённое объяснение, пока не восстановлена причинная цепочка.

Критерии запуска разбора

• Потеря или задержка событий изменила закупочные решения
• Есть финансовый impact или риск неверной выплаты
• Данные восстановлены ручным способом без гарантии полноты
• Нарушен SLO свежести или целостности
• Сбой затронул несколько источников или повторился
• Команда не может доказать точную границу поражения

Стабилизируйте поток до анализа

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

Impact без красивых оценок

Зафиксируйте первый подтверждённый плохой интервал, последний известный хороший интервал, затронутые event_type, источники, GEO и версии схемы. Разделите потерянные, задержанные, дублированные и неверно классифицированные события. Денежную оценку показывайте диапазоном, пока статусы и суммы не созрели.

SELECT date_trunc('hour', occurred_at) AS event_hour,
       source_id, schema_version,
       count(*) AS received_events,
       count(DISTINCT event_id) AS unique_events,
       count(*) - count(DISTINCT event_id) AS duplicate_rows
FROM raw_conversion_events
WHERE occurred_at BETWEEN :window_start AND :window_end
GROUP BY 1,2,3
ORDER BY event_hour, source_id, schema_version;

Запрос не доказывает потерю сам по себе. Результат сверяют с независимым upstream count, очередью доставки и downstream count по тому же бизнес-времени и версии контракта.

Timeline в трёх временных шкалах

• Event time — когда происходили пользовательские события
• System time — когда компоненты приняли, поставили в очередь и обработали данные
• Decision time — когда команда обнаружила проблему и выполняла действия

Одна колонка времени превращает задержку доставки в ложную последовательность. Timeline включает релизы, изменение конфигурации, рост очереди, первый алерт, ручные проверки, ограничение воздействия, восстановление и подтверждение стабильности. Для каждой точки указывается источник: лог, deploy record, тикет или сообщение.

Причинная цепочка вместо одной root cause

У инцидента обычно несколько слоёв: непосредственный технический механизм, условие, сделавшее его возможным, и причина позднего обнаружения. Например, producer отправил новое обязательное поле, consumer отклонял payload, контракт не проверялся на совместимость, а алерт следил только за HTTP 200 перед очередью.

Trigger: что изменилось непосредственно перед симптомом
Failure mechanism: где и как данные перестали соответствовать инварианту
Propagation: почему ошибка затронула следующие компоненты
Detection gap: почему мониторинг не сообщил раньше
Response gap: что замедлило ограничение воздействия
Recovery risk: как восстановление могло создать дубли или неверные статусы

Пять почему — не допрос

Вопрос «почему» направляется на систему. Почему несовместимая схема попала в production? Почему тест не содержал старого consumer? Почему deploy не имел canary? Почему алерт измерял доступность, но не целостность? Ответ «человек забыл» считается началом исследования процесса, а не финалом.

Корректирующие меры должны менять риск

Формулировка «быть внимательнее» не проверяется. Хорошее действие добавляет автоматический контрактный тест, сравнение контрольных сумм, ограниченный rollout, DLQ с алертом или кнопку идемпотентного replay. У каждого action item есть владелец, срок, приоритет и критерий приёмки.

{
  "action": "reject incompatible schema before production rollout",
  "owner_role": "tracking-platform-owner",
  "due_at": "set-an-approved-date",
  "risk_addressed": "consumer incompatibility",
  "acceptance": "CI fails on producer/consumer contract mismatch",
  "verification": "record a controlled incompatible fixture"
}

Дата и роль в примере являются инструкцией к заполнению, а не фиктивным обязательством реальной команды. В рабочем документе placeholders недопустимы.

Безопасное восстановление

1. Сделать snapshot сырых данных и текущих статусов.
2. Определить точный набор event_id для replay.
3. Проверить идемпотентность на контрольной выборке.
4. Восстанавливать небольшими партиями.
5. Сверять upstream, queue, accepted, current status и ledger.
6. Не перезаписывать поздние решения более ранними.
7. После завершения повторить сверку на полном интервале.

Как проверить, что исправление работает

После восстановления нужен период наблюдения. Контроль включает freshness percentile, долю отклонений по reason_code, глубину очереди, дубли, сумму по валютам и соответствие версий. «График снова похож на обычный» недостаточен: должны сойтись заранее определённые инварианты.

Postmortem не должен раскрывать чувствительные данные

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

Источники и границы применимости

Google SRE: Incident Management Guide · Google SRE: Postmortem Culture

Вывод

Хороший postmortem связывает impact, доказательный timeline, механизм отказа, пробел обнаружения и проверяемые меры. Он сохраняет техническую точность, не превращаясь в поиск виновного. Ценность документа появляется тогда, когда action items выполнены и повторный контролируемый сценарий подтверждает новую защиту.