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

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

Що входить до типового контуру:

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 тижні на підготовку.