В квартальном отчёте руководству была озвучена выручка, которая, как выяснилось через неделю, завышена на 15% из-за бага в пайплайне дедупликации заказов. Как бы ты выстроил процесс реагирования на инцидент и предотвращения повторения, и какие тут компромиссы?

Короткий ответ

Единого рецепта нет — обычно нужны одновременно (1) немедленная прозрачная коммуникация руководству с исправленной цифрой и объяснением причины, (2) постмортем без поиска виноватых с конкретными техническими исправлениями (тесты на дедупликацию, алерты), и (3) усиление процесса проверки критичных метрик перед публикацией, но каждый дополнительный контроль увеличивает время подготовки отчётности.

Как это работает подробнее

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

Пример кода

example.sqlКопировать

-- Пример теста, который нужно было внедрить: проверка на дубликаты order_id
SELECT order_id, COUNT(*) FROM fact_orders GROUP BY order_id HAVING COUNT(*) > 1;
-- Пример алерта: рост выручки день-к-дню более чем на 20% требует ручного подтверждения перед публикацией

Что использовать на практике

• На практике. Постмортем должен зафиксировать не только техническую причину (баг дедупликации), но и то, почему существующие проверки качества его не поймали — например, не было автоматического теста на количество уникальных order_id, или алерт на аномальный рост выручки был, но его проигнорировали.
• Проверка. после исправления — прогнать этот тест как обязательный шаг пайплайна (CI/dbt test), который блокирует публикацию витрины выручки при обнаружении дублей, и зафиксировать это в постмортеме как конкретное предотвращающее действие.

Подводные камни

• Частые ошибки. Ограничиваются точечным исправлением бага без изменения процесса, из-за чего похожий класс ошибок повторяется в другой витрине; либо вводят настолько тяжёлый процесс согласования любой цифры для руководства (множественные ручные проверки, долгое утверждение), что отчётность начинает систематически опаздывать.
• Компромисс. Больше автоматических проверок и ручных sign-off перед публикацией критичных метрик снижает риск повторения инцидента, но увеличивает время и стоимость подготовки каждого отчёта и может быть избыточным для менее критичных метрик. Решение о том, насколько тяжёлый процесс проверки оправдан, зависит от цены ошибки (публичная отчётность перед советом директоров против внутреннего operational-дашборда) — универсального порога не существует, и его нужно явно обсуждать со стейкхолдерами, а не выбирать в одиночку.