Собесов

Сценарий: баг в metric pipeline — как найти и доказать

Кейсы и метрикиDiagnoseСредняяMiddle

Условие

Вечером менеджер пишет: «DAU вчера упало на 15%, но юзеры не жалуются». Что проверить первым делом?

Решение

Гипотеза 1: баг трекинга

Самая частая причина «странных» падений. Проверять:

  1. Источник данных: сырой event log нормального размера?
SELECT date(ts) AS d, COUNT(*) AS events, COUNT(DISTINCT user_id) AS users
FROM raw_events
WHERE date(ts) >= CURRENT_DATE - 7
GROUP BY 1 ORDER BY 1;

Если events 20% меньше — потеря на уровне приёма.

  1. ETL last_run — все ли таблицы обновились?

  2. Schema changes: deploy ли новой версии SDK сломал event name?

Гипотеза 2: дедуп / фильтр

ETL фильтрует bots/dups. Если порог фильтра поменялся — DAU падает без real причины.

-- Сколько отфильтровано
SELECT date(ts), filter_reason, COUNT(*) FROM filtered
GROUP BY 1, 2 ORDER BY 1;

Гипотеза 3: definition change

Кто-то поменял определение DAU (например, теперь не считаем background app refresh). Проверять git history дашборда / SQL.

Гипотеза 4: TZ shift

Перевод сервера на другую таймзону → день сдвинут на 2 часа.

SELECT TIMEZONE(ts) FROM events LIMIT 1;

Гипотеза 5: late arrivals

Часть events приходит с lag (offline-кэш мобилки). «Вчерашний DAU» через сутки увеличится на 5-10%.

Гипотеза 6: real drop

Если все гипотезы пройдены — это правда падение. Тогда декомпозиция (см. отдельный сценарий про metric drop).

Доказательство «это баг»

DAU(date) vs n_unique_users(raw_events on date)

Если raw shows норма, DAU dashboard падает → bug в downstream pipeline.

Forensic SQL

WITH counts AS (
  SELECT
    date(ts) AS d,
    COUNT(DISTINCT user_id) AS dau_raw,
    COUNT(DISTINCT CASE WHEN ts >= '2024-01-15' AND ts < '2024-01-16' THEN user_id END) AS dau_check
  FROM raw_events
  GROUP BY 1
)
SELECT * FROM counts WHERE d = '2024-01-15';

Сравнить с dashboard.

Validation checks (на будущее)

Поставить data quality checks:

  • Row counts по таблицам (alarm если -20% YoY).
  • Schema enforcement (новые fields → alert).
  • Distribution checks (если DAU делится на geo, и одна geo == 0 — alarm).
  • Reconciliation: SUM по downstream = SUM по upstream.
# Great Expectations / Soda / dbt tests
expect_column_count_between(min=0.9*expected, max=1.1*expected)

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

  1. «DAU упало 15%» от прошлой пятницы — может быть сезонность (праздник). Сравнивать с прошлой неделей того же дня.
  2. Late arrivals — нормальная часть pipeline. Не паниковать, если за сутки добавили.
  3. Один источник данных может быть battered, остальные ок — сегментация по платформе.
  4. Schema break сложно обнаружить без unit-тестов — Great Expectations спасает.
  5. Если все говорят «у нас всё ок», а DAU упало — почти всегда баг агрегации/dashboard.

Эталонный ответ

Сначала проверить raw events (count, schema, late arrivals, timezone). Потом ETL (фильтры, дедуп). Потом dashboard SQL (изменили определение?). Forensic: сравнить count в raw и aggregated. Будущее: data quality checks (Great Expectations, dbt tests).

Хочешь увидеть разбор?

Зарегистрируйся бесплатно — откроется развёрнутое решение этой задачи и ещё 4 на выбор.

Зарегистрироваться и увидеть разбор
Уже есть аккаунт? Войти