Аномалии в метриках: как находить скачки и проверять их до сообщения команде

Когда нужен этот метод

Алерт о падении заказов может означать инцидент checkout, задержку ETL, праздник или смену часового пояса. Если слать команде каждое отклонение, алерты перестанут читать. Надёжный мониторинг связывает статистическое правило с контекстом источника, бизнес-критичностью и понятным владельцем реакции.

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

Определения без жаргона

Аномалия — наблюдение, которое заметно отличается от ожидаемого поведения по выбранной модели baseline. Baseline может быть rolling mean, медианой аналогичных дней или прогнозом с сезонностью. z-score работает лучше на подходящей форме распределения, IQR устойчивее к хвостам, а для временных рядов важны календарные и релизные признаки.

Выбери окно и уровень агрегации, затем зафиксируй baseline до просмотра результата. Сравни текущую точку с ожидаемой и оцени абсолютное и относительное отклонение. Добавь минимальный порог объёма, чтобы не ловить шум маленьких сегментов. После алерта проверь source freshness, дубли, полноту дня, deployment и разрезы.

Рабочий кейс

DAU упал на 28% в 10:00. Проверка показала, что ingestion отставал на два часа, а raw events продолжали поступать. Это не продуктовый инцидент, хотя бизнес-дашборд выглядел тревожно. В мониторинге нужны отдельные сигналы freshness и completeness, иначе аналитический алерт будет компенсировать техническую слепоту.

Раздели detection и diagnosis. Detection отмечает отклонение, diagnosis собирает контекст: источник, дата, сегмент, релиз, event rate, null rate и соседние метрики. Заверши проверку статусом confirmed, data issue, expected seasonality или unknown. Для каждого статуса нужна следующая команда и срок обновления.

Контрольная сверка

До интерпретации проверь единицу наблюдения, период и правило включения. Затем пересчитай результат на небольшой выборке, где ответ известен заранее, и сравни с разумной альтернативой: другим горизонтом, зрелой когортой или user-level агрегацией.

Если показатель станет регулярным, сохрани рядом входные параметры, контрольные сверки и версию определения. Это важнее дополнительного знака после запятой.

• Зафиксируй baseline до просмотра результата.
• Проверь пропуски, дубли и зрелость периода.
• Покажи размер выборки и диапазон неопределённости.

Когда метод подводит

Один глобальный порог плохо работает для всех сегментов. z-score после сильного релиза может считать новый нормальный уровень аномалией. Слишком чувствительный алерт создаёт шум, слишком редкий — пропускает ущерб. Не объединяй метрику и качество данных в один сигнал: команда должна понимать, что именно сломалось.

Пиши: «Заказы ниже сезонного baseline на 19%, но raw events и платёжный провайдер в норме; падение локализовано в Android 6.4 после релиза. Статус — подтверждённый продуктовый инцидент, владелец — mobile team». Это уже маршрут действия, а не просто красная точка.

Попробуй сам

Для трёх ключевых метрик задай baseline, минимальный объём, порог, сегменты и владельца. Прогони правила на историческом периоде и посчитай false alerts. Затем добавь искусственную задержку данных и проверь, ловит ли её отдельный data-quality мониторинг. Настройка без backtest почти всегда приводит к лишнему шуму.

series['baseline'] = series['value'].rolling(28, min_periods=14).median()
series['delta_pct'] = series['value'] / series['baseline'] - 1
alerts = series[series['delta_pct'].abs() > 0.2]

• Сохрани период и параметры расчёта.
• Назови хотя бы один крайний случай.
• Сформулируй вывод отдельно от гипотезы о причине.

Что делать дальше

Пиши: «Заказы ниже сезонного baseline на 19%, но raw events и платёжный провайдер в норме; падение локализовано в Android 6.4 после релиза. Статус — подтверждённый продуктовый инцидент, владелец — mobile team». Это уже маршрут действия, а не просто красная точка.

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