Детектор аномалий в бизнес-метриках

Детектор аномалий — это сервис, который ежедневно (или чаще) сканирует бизнес-метрики и поднимает руку, когда показатель ведёт себя нетипично. Логика проста: модель учится на исторических данных, фиксирует нормальный диапазон с учётом сезонности и тренда, помечает точки за пределами этого диапазона. Команда узнаёт о просадке выручки, скачке churn rate или странной конверсии в момент появления сигнала, а не через две недели на retrospective.

Что входит в типовой контур:

1. Подключение к источнику данных — data warehouse или прямой запрос в BI-инструмент.
2. Описание набора метрик: выручка по каналам, MRR, активные пользователи, конверсия по этапам воронки, churn, средний чек, размер заказа, остатки склада, runway.
3. Обучение базовых моделей на исторических данных каждой метрики — учитываются дневная и недельная сезонность, праздники, тренд.
4. Регулярный запуск проверок (cron или event-driven) с расчётом отклонения от ожидаемого значения.
5. Публикация алерта в Slack или Teams с контекстом: метрика, текущее значение, ожидаемый диапазон, величина отклонения, ссылка на дашборд.
6. Логирование подтверждённых аномалий и ложных срабатываний — для дообучения порогов.

Что детектор делать НЕ будет:

• Не объясняет причину аномалии. Сигнал говорит «здесь странно», но root cause analysis остаётся за человеком.
• Не работает без чистых исторических данных. Если витрина выручки разваливается раз в неделю или метрика недавно сменила формулу — модель будет давать шум.
• Не отвечает за бизнес-решения. Алерт в Slack — это входной триггер для расследования, а не указание остановить кампанию или повысить цены.

Архитектурно сервис состоит из четырёх слоёв: источник данных, расчётный движок, движок алертов, канал доставки. Custom-code подход выбирается, когда готовые SaaS-платформы для anomaly detection избыточны по цене или плохо ложатся на специфику метрик клиента.

Технический поток

1. Планировщик (Airflow, Prefect, Dagster или cron в kubernetes) запускает batch-задачу по расписанию — раз в час или раз в день, в зависимости от метрики.
2. Job делает SQL-запрос в data warehouse и забирает временной ряд по нужной метрике с историей за 90-365 дней.
3. Модуль детекции применяет одну из моделей: STL-декомпозиция и z-score для большинства метрик, Prophet или ARIMA для рядов с выраженной сезонностью, isolation forest для многомерных случаев.
4. Расчёт ожидаемого диапазона для текущей точки. Если фактическое значение выходит за границы доверительного интервала — фиксируется аномалия с указанием направления и величины.
5. Постпроцессинг: фильтрация дубликатов (одна аномалия не алертит дважды), агрегация связанных сигналов, классификация по severity.
6. Формирование сообщения в Slack или Teams через webhook — метрика, значение, ожидание, дельта, временное окно, ссылка на BI-дашборд для drill-down.

Шаги внедрения

1. Аудит метрик и приоритизация: список из 10-20 критичных KPI, которые имеет смысл мониторить (больше — утонете в алертах).
2. Подготовка данных: проверка качества, единая таблица метрик в DWH или materialized view, документирование SLA на свежесть данных.
3. Выбор стека: Python с библиотеками для time-series анализа, оркестратор, секреты для подключения к DWH и messenger.
4. Прототип на 2-3 метриках, ручная калибровка порогов, прогон на исторических данных для проверки точности.
5. Расширение покрытия, добавление severity-уровней, разделение каналов (P1 алерты идут в дежурный канал, P2 — в дайджест).
6. Двухнедельный shadow-режим: алерты пишутся в лог, но не уходят в Slack — проверяется частота ложных срабатываний.
7. Запуск в продакшен, ежемесячный review порогов и эффективности.

Компоненты системы

Стоимость инфраструктуры низкая: расчёт занимает минуты, нагрузка на DWH небольшая. Главный ресурс — время data-инженера или ML-инженера на калибровку моделей и работу с владельцами метрик.

Что должно быть на стороне клиента до старта проекта:

Данные и доступы:

• Data warehouse или централизованная аналитическая база с историей метрик минимум за 6 месяцев (год — лучше).
• Документированные SQL-запросы или dbt-модели для ключевых метрик. Если каждая метрика считается ad hoc разными способами — сначала наводим порядок.
• Сервисный аккаунт для чтения данных и webhook URL в Slack или Teams для отправки алертов.
• Понимание сезонности: команда знает, что в субботу падает выручка, а в декабре растёт средний чек — модель обучается с учётом этого.

Команда и владельцы:

• Дежурный по метрикам — человек, который реагирует на алерт. Без owner'а сервис превращается в шумовой канал.
• Аналитик или data-инженер, который владеет логикой метрик и помогает в калибровке.
• DevOps или платформенный инженер для развёртывания (Docker, секреты, доступ к DWH из инфраструктуры).

Технологический стек:

• Python 3.10+, Docker, оркестратор (если ещё нет — поднимаем простой Prefect или cron в существующем kubernetes-кластере).
• Доступ к Slack или Microsoft Teams через incoming webhook.

Сроки:

• Прототип на 2-3 метриках: 2-3 недели.
• Полный набор из 10-20 метрик с калибровкой и shadow-режимом: 4-6 недель.
• Если data warehouse не настроен или данные грязные — добавьте 2-4 недели на подготовку.