Anomaly Detection для IT-інфраструктури: від алертів до AIOps

## Проблема традиційного моніторингу Класичний підхід до моніторингу IT-інфраструктури — це порогові алерти: якщо CPU вище 90% протягом 5 хвилин — надіслати сповіщення. Цей підхід простий, зрозумілий і має два суттєві недоліки. Перший — велика кількість хибних тривог (false positives). Команда DevOps отримує десятки або сотні алертів на день, більшість з яких не є реальними проблемами. Через "alarm fatigue" справжня проблема може загубитись у шумі. Другий — реактивність замість проактивності. Поріг спрацьовує вже тоді, коли проблема є. Але деградація зазвичай починається набагато раніше, ніж метрика перетинає поріг. Machine Learning-підхід до виявлення аномалій вирішує обидва недоліки: система навчається, що є "нормою" для конкретного сервісу у конкретний час доби і день тижня, і сигналізує лише при справжніх відхиленнях від цієї норми. ## Як працює ML-виявлення аномалій Алгоритми anomaly detection умовно діляться на два класи. **Unsupervised методи** (без розмітки): навчаються виключно на "нормальних" даних і виявляють відхилення від вивченої норми. Популярні алгоритми: Isolation Forest (добре для табличних метрик), One-Class SVM, Autoencoder (нейромережа для складних патернів). **Часові ряди зі складними патернами**: LSTM (Long Short-Term Memory) та Prophet від Meta — для метрик з виразною сезонністю (трафік вдень вищий, ніж вночі; по понеділках вищий, ніж у вихідні). Ці моделі враховують часові залежності і розуміють, що "CPU 80% у чорну п'ятницю — норма, але CPU 80% у вівторок о 3 ночі — аномалія". ## Практичні сценарії використання **Метрики серверів.** CPU, RAM, disk I/O, network throughput — ML виявляє аномальні комбінації ще до того, як будь-яка окрема метрика перетинає поріг. Наприклад, незначне збільшення latency у поєднанні із зростанням кількості повторних з'єднань може вказувати на проблему в мережевому стеку. **Логи застосунків.** Різке збільшення частоти певного типу помилок, поява нових патернів помилок, зміна розподілу HTTP-статус-кодів — ML аналізує логи в реальному часі і виявляє патерни, які важко відловити порогами. **Метрики бізнес-логіки.** Кількість транзакцій за хвилину, конверсія, середній час сесії — різке падіння цих показників часто є першим симптомом технічної проблеми, помітним навіть раніше, ніж спрацьовують технічні алерти. **Затримки запитів до бази даних.** Anomaly detection на p95/p99 latency SQL-запитів дозволяє виявити деградацію продуктивності бази даних на ранній стадії, до того як вона вплине на кінцевих користувачів. ## Результати впровадження AIOps: реальний кейс E-commerce компанія з навантаженням 50 000 запитів на день впровадила ML-аномалій детекцію на основі Isolation Forest + LSTM для часових рядів. До впровадження: 40-60 алертів на день, MTTR (Mean Time to Resolve) 47 хвилин, 30% проблем виявлялись від клієнтів, а не від системи моніторингу. Після впровадження: 8-12 значущих алертів на день (зниження шуму на 80%), MTTR 19 хвилин (скорочення на 60%), 95% проблем виявляються системою до впливу на користувачів, 40% більше інцидентів виявляється на стадії "попередження" замість "криза". ## Інструменти для реалізації **Prometheus + ML-моделі.** Prometheus збирає метрики, модель (Python/sklearn) аналізує їх і повертає anomaly score. Алерт у Alertmanager спрацьовує не при перевищенні порогу, а при аномальному score. **Datadog з ML.** Хмарна платформа з вбудованим Watchdog — ML-движком для автоматичного виявлення аномалій у метриках та логах. Простий у налаштуванні, але дорожчий за self-hosted рішення. **Кастомне рішення на Python.** scikit-learn + FastAPI + Grafana. Максимальна гнучкість, нижча вартість при масштабі, але вимагає більше зусиль на підтримку. ## Перший крок Починайте з однієї метрики, яка є найважливішою для вашого бізнесу: зазвичай це latency основного API або кількість транзакцій за хвилину. Зберіть 2-4 тижні нормальних даних, навчіть просту Isolation Forest модель і порівняйте її алерти з вашою поточною системою. Ви побачите результат ще до повноцінного впровадження.