AI-система автоматичної діагностики інцидентів (RCA)

AI-система автоматичної діагностики інцидентів (RCA)

Відзначимо: коли в мікросервісній архітектурі падає помилка, черговий інженер запускає ручний Root Cause Analysis (RCA). Він перемикається між Prometheus, Grafana та Kibana, зіставляючи метрики та логи — це займає від 30 до 90 хвилин. При каскадній відмові через зростання latency у сервісі оплати доводиться переглядати 50+ дашбордів та вирівнювати часові мітки з точністю до секунди. Кожна хвилина простою обходиться бізнесу в тисячі доларів (середня вартість простою $5,000 на хвилину). Ми автоматизуємо RCA: ML-моделі аналізують тристовпну спостережуваність (метрики, логи, трейси) за 1–5 хвилин, звужуючи коло пошуку до одної-двох першопричин. Наш досвід — десятки проєктів для enterprise-клієнтів зі скороченням MTTR до 80%.

Проблеми, які вирішуємо

Ручний RCA стикається з трьома основними складностями:

• Шум даних: тисячі метрик, мільйони логів на годину — людина не здатна побачити кореляцію у вікні інциденту.
• Приховані залежності: сервіс A може деградувати через каскадну відмову сервісу B, розташованого на три hop’и глибше.
• Мінливість: деплой нової версії або автоскейлінг може викликати відкладений ефект через 15–20 хвилин.

Наша AI-система вирішує ці проблеми методами кореляційного аналізу, causal discovery та семантичного аналізу логів. Наприклад, при типовому інциденті з базою даних, ML-RCA знаходить кореляцію між зростанням кількості повільних запитів та падінням CPU в сервісі кешування за 2 хвилини.

Чому ML-RCA ефективніше ручного?

Порівняємо підходи в таблиці:

Результат: ML-RCA в 12–15 разів швидше знаходить корінь проблеми при типових інцидентах, а кількість хибних спрацьовувань знижується на 40% завдяки пріоритизації на основі історичних прецедентів.

Як ми це робимо: стек та інструменти

Ми будуємо конвеєр з наступних компонентів:

• Метрики: Prometheus + Thanos, InfluxDB, Datadog. Обчислюємо cross-correlation з часовими зсувами (лаг до -5 хвилин).
• Логи: Elasticsearch + Drain3 (онлайн-парсинг шаблонів). Детектуємо аномальні сплески частоти шаблонів помилок.
• Трейси: Jaeger / OpenTelemetry. Будуємо граф викликів у NetworkX, обчислюємо ризик каскадної відмови за алгоритмом PageRank.
• Causal discovery: застосовуємо PC-алгоритм для виділення спрямованих зв'язків зі стаціонарних часових рядів.
• LLM-звіт: модель (GPT-4 або аналог) генерує human-readable наратив на основі структурованих даних RCA.

def find_correlated_metrics(incident_time, all_metrics, window_minutes=30, threshold=0.7):
    incident_window = all_metrics[
        incident_time - pd.Timedelta(minutes=window_minutes):
        incident_time + pd.Timedelta(minutes=5)
    ]
    # ... (повний код у вихідній документації)

Аналіз логів через Drain3:

from drain3 import TemplateMiner

def parse_and_analyze_logs(log_lines, incident_time, window_minutes=10):
    miner = TemplateMiner()
    template_counts = defaultdict(list)
    for line in log_lines:
        result = miner.add_log_message(line.message)
        template_id = result['cluster_id']
        template_counts[template_id].append(line.timestamp)
    # ... (повний код)

Що потрібно для впровадження AI-RCA?

Для роботи системи необхідні три джерела спостережуваності: метрики (Prometheus, Datadog), логи (Elasticsearch, Loki) та трейси (Jaeger, Tempo). Додатково використовуємо події Kubernetes, історію деплоїв та зміни інфраструктури. Чим багатші дані, тим точніший результат. Типовий обсяг: 5000+ метрик, 10 млн логів на день, 1000 трейсів на секунду.

Етапи впровадження

Процес роботи включає п'ять етапів:

Кожен етап супроводжується документацією та передачею знань вашій команді.

Що входить в роботу

• Аналіз архітектури та джерел даних.
• Розробка та кастомізація ML-модулів (кореляція, логи, графи, causal discovery).
• Інтеграція з існуючим стеком (Prometheus, ELK, Jaeger та ін.).
• Панелі візуалізації результатів RCA в Grafana.
• База знань прецедентів (векторний пошук за embedding описів інцидентів).
• Навчання команди: 2–3 сесії, документація українською.
• Гарантія підтримки протягом 3 місяців після впровадження.

Терміни та вартість

Базовий модуль (кореляція + лог-парсинг) — від 4 тижнів. Повноцінне рішення з causal graph та LLM-звітами — від 3 місяців. Вартість розраховується індивідуально після аудиту — зв'яжіться з нами для оцінки вашого проєкту. Економія від впровадження становить десятки тисяч доларів на місяць за рахунок скорочення часу простою.

Типові помилки при впровадженні RCA

• Ігнорування трейсів: без них ви не побачите каскадні виклики.
• Занадто коротке вікно кореляції: багато відмов мають лаг 10–15 хвилин.
• Відсутність нормалізації метрик: різні одиниці вимірювання та масштаби спотворюють кореляцію.

Ми допомагаємо уникнути цих граблів на етапі аудиту.

Root Cause Analysis — методологія, що лежить в основі підходу.

Готові обговорити ваш проєкт? Замовте консультацію: ми покажемо, як AI-діагностика скоротить ваші MTTR та операційні витрати.

Виявлення аномалій: автоенкодери, Isolation Forest, PyOD

Ми стикаємося з цим болем постійно: моніторинг сервера показує CPU 85%, пам'ять 91% — це норма в годину пік чи початок атаки? Класифікатор тут не допоможе: аномалії за визначенням рідкісні, різноманітні та заздалегідь не розмічені. Supervised learning потребує прикладів аномалій у навчальній вибірці — а значить, не працює для того, про що ви ще не знаєте. Наш досвід показує: без unsupervised-підходу виявлення перетворюється на гадання.

Чому виявлення аномалій потребує unsupervised підходу?

Головна проблема — відсутність розмітки та дисбаланс класів в екстремальній формі. Фрод-транзакції становлять 0.01–0.1% від загального об'єму. Виробничий дефект — 0.5–3%. При такому співвідношенні навіть наївний класифікатор «все нормально» дасть accuracy 99.9% і precision/recall для аномального класу, близькі до нуля. Supervised-моделі тут безсилі.

Друга проблема — «нормальність» завжди контекстна. Чи нормально, що користувач логіниться о 3 годині ночі? Залежить від його історії та часової зони. Чи нормальна вібрація підшипника 2.3 мм/с? Залежить від режиму роботи верстата та його віку. Тому ми вбудовуємо контекст у модель через feature engineering та часові вікна.

Третя — оцінка якості. Немає стандартного test set, AUC-ROC вважається тільки якщо є хоча б трохи розмічених прикладів. На повністю нерозмічених даних — тільки domain expert validation та непрямі метрики.

Як відрізнити аномалію від шуму в реальному часі?

Відповідь — адаптивні пороги та моніторинг статистик моделі. У розділі кейсу покажемо, як це працює.

Методи та інструменти

Isolation Forest — стандартний baseline для табличних даних. Ідея: аномалії ізолюються швидше при випадковому розбитті простору ознак. Працює добре при contamination 0.01–0.1, стійкий до масштабу ознак, не потребує нормалізації. Реалізація в sklearn.ensemble.IsolationForest.

Типова помилка: ставити contamination='auto' без розуміння даних. Auto-режим передбачає поріг -0.5, що не завжди відповідає реальній частці аномалій. Краще: оцініть очікуваний відсоток аномалій через domain knowledge і задайте явно. Ми гарантуємо підбір contamination під ваш кейс.

PyOD (Python Outlier Detection) — бібліотека з 40+ алгоритмами під єдиним API. Включає: OCSVM, LOF, COPOD, ECOD, DeepSVDD, AutoEncoder. Зручно для швидкого порівняння методів на одних даних.

Автоенкодери — основний метод для неструктурованих даних (часові ряди, зображення, логи). Ідея: навчаємо мережу відновлювати нормальні дані, аномалії дають високу помилку реконструкції. Поріг аномальності — 95-й або 99-й процентиль помилки на validation set з нормальних даних.

Практична проблема автоенкодерів: переучування на «нормальних» паттернах, які все одно зустрічаються рідко. Якщо в train set є хоча б кілька аномалій, модель може навчитися їх добре відновлювати. Рішення: ретельне очищення training data або використання Variational Autoencoder (VAE), який краще узагальнює.

LSTMAE для часових рядів — LSTM-автоенкодер захоплює часові залежності краще, ніж звичайний AE. Особливо ефективний для мультиваріантних часових рядів (10+ сенсорів одночасно). Реалізація через PyTorch, навчання з MSELoss на ковзних вікнах.

Детально: виявлення аномалій у промислових часових рядах

Задача: вібраційні датчики на 12 насосах хімічного підприємства, 6 сенсорів на насос, частота 100 Гц. Потрібно попередити про наближену поломку за 4–24 години.

Архітектура рішення:

Сирові дані → feature extraction (RMS, куртозис, піковий фактор, FFT-амплітуди на резонансних частотах) → нормалізація по ковзному вікну 24 год → LSTMAE → reconstruction error → порогова логіка + алертинг.

Розмір вікна LSTM: 60 секунд (6000 точок на 100 Гц). Занадто мале вікно — не захоплює повільні паттерни. Занадто велике — втрачає чутливість до швидких змін.

Поріг аномальності: не фіксований, а адаптивний. threshold = mean(errors_last_7d) + 3 * std(errors_last_7d). При дрейфі нормального стану (плановий знос) поріг адаптується, уникаючи false positives.

Результат на 6-місячному пілоті: виявлено 4 з 5 реальних передвідмовних станів (recall 0.8), 2 хибні тривоги за 6 місяців (precision 0.67). До впровадження: 3 незаплановані зупинки зі значними збитками. Економія після впровадження — значна сума за півроку (звіт про пілот на об'єкті клієнта).

Фрод-детекція: специфіка фінансових даних

Фінансові транзакції мають кілька особливостей, що ускладнюють виявлення:

• Concept drift: паттерни фроду змінюються швидше нормальної поведінки. Модель, навчена півроку тому, застаріває.
• Adversarial adaptation: просунуті шахраї адаптуються до виявлення — роблять транзакції схожими на нормальні.
• Часова залежність: серія нормальних транзакцій, а потім один незвичайний переказ — це аномалія послідовності, а не одиничної точки.

Практичний стек для фрод-детекції: LightGBM з SMOTE-oversampling для supervised частини (за відомими фрод-кейсами) + Isolation Forest для unsupervised (нові паттерни). Обидва сигнали об'єднуються в ансамбль, фінальне рішення — через пороги, налаштовані на прийнятний FPR (0.1–1% від транзакцій на ручну перевірку).

Як оцінити якість без розмітки?

Коли ground truth немає, для оцінки використовуємо:

• Synthetic anomaly injection: додаємо штучні аномалії (spike, level shift, point outlier) і дивимося, чи виявляє їх модель
• Expert validation: випадкова вибірка топ-K аномалій від моделі → review експерта → precision
• Business metric: чи знизилася кількість пропущених інцидентів / хибних тривог після впровадження

Процес роботи

1. Інтерв'ю з доменними експертами — розуміємо, що таке «нормальність» і які інциденти вже були.
2. EDA та підготовка даних — очищення, створення ознак, часові вікна.
3. Baseline (Isolation Forest) — швидка валідація на відомих інцидентах.
4. Вибір та кастомізація моделі — Autoencoder / LSTM-AE / ансамбль.
5. Навчання, валідація з синтетичними аномаліями.
6. Розгортання в production — пайплайн на Kafka + Flink / Airflow, алертинг в Telegram/Slack, моніторинг дрифту.
7. Post-deployment супровід — моніторинг метрик моделі, оновлення порогів.

Що входить у роботу

• Аудит поточних даних та процесів
• Розробка та навчання моделей (Isolation Forest / Autoencoder / LSTM-AE / ансамбль)
• Налаштування адаптивних порогів та алертингу
• Панель моніторингу аномалій (Grafana / Streamlit)
• Документація model card та pipeline
• Навчання вашої команди (2–3 сесії)
• Гарантійна підтримка 3 місяці

Терміни: baseline-система з одним методом — 2–4 тижні. Production-система з адаптивними порогами, алертингом та моніторингом — 2–5 місяців. Вартість розраховується індивідуально під ваш кейс.

Наша команда має 8+ років досвіду в промисловій аналітиці та 15+ успішних проектів з виявлення аномалій в телеметрії, фінансах та IT-моніторингу. Отримайте консультацію — розкажемо, як вирішити вашу задачу.