Разработка автономной AI-системы обнаружения и исправления сбоев

При нагрузке в 10k RPS сервис в Kubernetes начал «тормозить»: p99 latency вырос с 200 мс до 2 секунд. On-call инженер потратил 40 минут на root cause — exhausted connection pool к PostgreSQL. Классический мониторинг только алертит, но не предотвращает повторения. Мы строим автономные системы, которые сами находят и устраняют такие причины за минуты.

Система использует машинное обучение для предиктивного обнаружения отказов до их возникновения.

Как AI-детекция снижает MTTR в 10 раз

Архитектура event-driven: метрики, логи и трейсы собираются через OpenTelemetry, поступают в стриминг-платформу (Kafka), затем проходят через ML Inference Engine. Decision Engine выбирает плейбук, Action Executor выполняет действия через Kubernetes API или cloud SDK. Все автоматические операции записываются в Audit Log. Результат — MTTR падает с часов до 5 минут, а нагрузка на on-call снижается на 70%.

Большинство продакшен-систем работают на уровнях 2-3. Уровень 4 — только для проверенных плейбуков.

Почему многоуровневая детекция лучше одного метода?

Один метод всегда даёт false positives. Мы комбинируем три и используем голосование: аномалия фиксируется, если согласны хотя бы два из трёх. Статистический (Z-score), ML (Isolation Forest) и динамический порог (CUSUM) — каждый закрывает слабые стороны других. False positive rate падает с 20% до 3%.

import numpy as np
from scipy.stats import zscore

class MultiLayerAnomalyDetector:
    def __init__(self):
        self.stat_detector = StatisticalAnomalyDetector()
        self.ml_detector = IsolationForestDetector()
        self.dynamic_threshold = DynamicThreshold()

    def detect(self, metrics_window):
        stat_anomalies = self.stat_detector.detect(metrics_window)
        ml_anomalies = self.ml_detector.detect(metrics_window)
        dynamic_anomalies = self.dynamic_threshold.detect(metrics_window)

        consensus = (
            stat_anomalies.astype(int) +
            ml_anomalies.astype(int) +
            dynamic_anomalies.astype(int)
        ) >= 2

        return consensus

Как AI находит первопричину инцидента?

RCA строится на ориентированном графе сервисов из distributed traces. Когда аномалия возникает, алгоритм обходит граф от проблемного сервиса вверх по потоку и находит ближайший компонент, который тоже был аномален. LLM (GPT-4, Claude) генерирует понятное резюме: объединяет временную последовательность аномалий, change log за последние 24 часа и похожие инциденты из базы runbook. Время анализа снижается с 20 до 2 минут.

import networkx as nx

class CausalGraph:
    def __init__(self):
        self.graph = nx.DiGraph()

    def build_from_traces(self, distributed_traces):
        for trace in distributed_traces:
            for span in trace.spans:
                if span.parent_id:
                    self.graph.add_edge(span.parent_service, span.service)

    def find_root_cause(self, affected_service, anomaly_timestamp):
        ancestors = nx.ancestors(self.graph, affected_service)
        anomalous_ancestors = []
        for ancestor in ancestors:
            if self.had_anomaly(ancestor, anomaly_timestamp - timedelta(minutes=5),
                                anomaly_timestamp):
                anomalous_ancestors.append(ancestor)
        return self.find_nearest_anomaly(affected_service, anomalous_ancestors)

Автоматическое реагирование: как плейбуки устраняют сбои

Playbook Engine подбирает действия по типу инцидента. При превышении p99 latency > 500 мс — рестарт сервиса, при 5xx — проверить балансировку, при исчерпании соединений с БД — сбросить idle-соединения. Все операции ограничены execution limits: не более 3 рестартов в час, масштабирование не более чем в 5 раз. Опасные операции требуют одобрения человека.

class AutoRemediationEngine:
    def __init__(self):
        self.playbooks = self.load_playbooks()
        self.execution_limits = {
            'max_restarts_per_hour': 3,
            'max_scale_factor': 5,
            'requires_approval': ['database_migration', 'security_patch']
        }

    def execute(self, incident, root_cause):
        playbook = self.match_playbook(incident.type, root_cause)
        if playbook is None:
            self.escalate_to_human(incident, 'no_playbook')
            return
        if playbook.requires_approval:
            self.request_approval(playbook, incident)
            return
        if self.safety_check(playbook, incident):
            result = self.run_playbook(playbook, incident)
            self.audit_log(incident, playbook, result)
            if not result.success:
                self.escalate_to_human(incident, 'remediation_failed')

Корреляция и шумоподавление

Один инцидент генерирует десятки алертов. Мы используем DBSCAN-кластеризацию: группируем алерты по временной близости, сервису и severity. В результате получаем один инцидент с максимальной severity. Suppression rules подавляют false positives во время плановых деплоев. Это снижает количество алертов на 80%.

Пошаговый план внедрения

1. Аудит текущего мониторинга: анализ источников данных, алертов, runbook.
2. Проектирование архитектуры: выбор стека (OpenTelemetry, Kafka, ML-сервисы).
3. Разработка ML-моделей: мультимодальная детекция аномалий.
4. Построение графа зависимостей: из distributed traces.
5. Реализация плейбуков: шаблоны для типовых инцидентов.
6. Интеграция с операционными инструментами: PagerDuty, Slack, Jira.
7. Тестирование и деплой: canary-выкатка, мониторинг метрик.
8. Обучение команды: документация, runbook, тренировки.

Требования к инфраструктуре

• Kubernetes (версия 1.22+), облачная или on-prem.
• Доступ к метрикам (Prometheus), логам (Loki, OpenSearch) и трейсам (Jaeger).
• GPU-нода для инференса моделей (желательно NVIDIA V100/A100).
• Kafka или Pulsar для стриминга.

Сроки и стоимость

Базовая детекция и алерты — 4-5 недель. Полноценная система с RCA, auto-remediation и интеграциями — 4-5 месяцев. Полная автономия с Kubernetes-ремедиацией — 6-8 месяцев. Стоимость рассчитывается индивидуально после предпроектного анализа. Свяжитесь с нами для оценки.

Получите консультацию инженера: мы оценим вашу текущую систему и предложим план улучшений.

Детекция аномалий: автоэнкодеры, 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 незапланированных остановки по $40k каждая. Экономия после внедрения — $120k за полгода (отчёт о пилоте на объекте клиента).

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

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

• 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-мониторинге. Получите консультацию — расскажем, как решить вашу задачу.