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

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

Команда дізнається про просадку виручки, стрибок рівня плинності або дивну конверсію в момент появи сигналу, а не через два тижні на ретроспективі.

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

1. Підключення до джерела даних — сховище даних або прямий запит у BI-інструмент.
2. Опис набору метрик: виручка за каналами, MRR, активні користувачі, конверсія за етапами воронки, відтік, середній чек, розмір замовлення, залишки складу, фінансовий запас.
3. Навчання базових моделей на історичних даних кожної метрики — враховуються денна та тижнева сезонність, свята, тренд.
4. Регулярний запуск перевірок (cron або подієво-керований) з розрахунком відхилення від очікуваного значення.
5. Публікація алерту в Slack або Teams з контекстом: метрика, поточне значення, очікуваний діапазон, величина відхилення, посилання на дашборд.
6. Логування підтверджених аномалій і хибних спрацювань — для дообучення порогів.

Що детектор робити НЕ буде:

• Не пояснює причину аномалії. Сигнал каже «тут дивно», але аналіз першопричин залишається за людиною.
• Не працює без чистих історичних даних. Якщо вітрина виручки розвалюється раз на тиждень або метрика нещодавно змінила формулу — модель буде давати шум.
• Не відповідає за бізнес-рішення. Алерт у Slack — це вхідний тригер для розслідування, а не вказівка зупинити кампанію або підвищити ціни.

Архітектурно сервіс складається з чотирьох шарів: джерело даних, розрахунковий рушій, рушій алертів, канал доставки. Підхід на основі власного коду обирається, коли готові SaaS-платформи для виявлення аномалій надлишкові за ціною або погано лягають на специфіку метрик клієнта.

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

1. Планувальник (Airflow, Prefect, Dagster або cron у kubernetes) запускає пакетне завдання за розкладом — раз на годину або раз на день, залежно від метрики.
2. Завдання робить SQL-запит у сховище даних і забирає часовий ряд за потрібною метрикою з історією за 90-365 днів.
3. Модуль детекції застосовує одну з моделей: STL-декомпозиція та z-score для більшості метрик, Prophet або ARIMA для рядів з вираженою сезонністю, isolation forest для багатовимірних випадків.
4. Розрахунок очікуваного діапазону для поточної точки. Якщо фактичне значення виходить за межі довірчого інтервалу — фіксується аномалія із зазначенням напрямку та величини.
5. Постпроцесинг: фільтрація дублікатів (одна аномалія не алертить двічі), агрегація пов'язаних сигналів, класифікація за рівнем критичності.
6. Формування повідомлення в Slack або Teams через вебхук — метрика, значення, очікування, дельта, часове вікно, посилання на BI-дашборд для деталізації.

Кроки впровадження

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

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

Вартість інфраструктури низька: розрахунок займає хвилини, навантаження на DWH невелике. Головний ресурс — час інженера з даних або ML-інженера на калібровку моделей і роботу з власниками метрик.

Що має бути на стороні клієнта до старту проекту:

Дані та доступи:

• Сховище даних або централізована аналітична база з історією метрик мінімум за 6 місяців (рік — краще).
• Задокументовані SQL-запити або dbt-моделі для ключових метрик. Якщо кожна метрика рахується по-різному, без єдиного підходу, — спершу наводимо порядок.
• Сервісний акаунт для читання даних і URL вебхука у Slack або Teams для надсилання алертів.
• Розуміння сезонності: команда знає, що в суботу падає виручка, а в грудні зростає середній чек — модель навчається з урахуванням цього.

Команда та власники:

• Черговий по метриках — людина, яка реагує на алерт. Без відповідального сервіс перетворюється на шумовий канал.
• Аналітик або інженер з даних, який володіє логікою метрик і допомагає в калібруванні.
• DevOps або платформний інженер для розгортання (Docker, секрети, доступ до DWH з інфраструктури).

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

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

Терміни:

• Прототип на 2-3 метриках: 2-3 тижні.
• Повний набір із 10-20 метрик із калібруванням і тіньовим режимом: 4-6 тижнів.
• Якщо сховище даних не налаштоване або дані брудні — додайте 2-4 тижні на підготовку.