AIOps: как машинное обучение и LLM решают реальные проблемы эксплуатации

AIOps решает конкретную задачу: эксплуатация IT-систем перестала справляться с потоком алертов. Средняя команда DevOps получает сотни уведомлений в день, до 80% из них ложные или дублирующиеся. Машинное обучение и большие языковые модели автоматизируют разбор этих алертов, группируют их в инциденты и сокращают время диагностики. В этой статье разобраны три ключевые ML-задачи: дедупликация алертов, корреляция событий по топологии и обнаружение аномалий с динамическими базовыми линиями. Отдельно показаны сценарии применения LLM для саммаризации логов, подбора runbook и генерации постмортемов.

Главный вывод: начать можно без дорогих enterprise-платформ. Стандартные функции PromQL и настройка Alertmanager закрывают заметную часть задач по снижению шума. ML-модели и LLM добавляются поэтапно, когда базовая гигиена алертов уже налажена.

Что такое AIOps и почему это не просто модное слово

AIOps, Artificial Intelligence for IT Operations, это применение машинного обучения и языковых моделей к задачам эксплуатации IT-инфраструктуры. Цель: снизить шум от алертов, ускорить диагностику инцидентов и автоматизировать рутинные операции. Традиционный мониторинг работает по статическим правилам: порог CPU выше 85%, диск заполнен на 90%. Такие правила не учитывают сезонность нагрузки, архитектурные зависимости и контекст конкретного сервиса.

Практика показывает: 60% ML-проектов проваливаются на этапе деплоя, а 73% не доходят до продакшена из-за проблем с интеграцией и мониторингом. AIOps не исключение. Разница в том, что здесь можно начать с простых шагов и получать измеримый эффект без построения сложных пайплайнов.

Три ключевые ML-задачи в AIOps

В контексте эксплуатации машинное обучение решает три основные задачи:

• Дедупликация и группировка алертов - объединение сотен однотипных уведомлений в один инцидент.
• Корреляция событий по топологии - связывание алертов из разных систем в единую картину отказа.
• Обнаружение аномалий с динамическими базовыми линиями - выявление отклонений без ручной настройки порогов.

Каждая из этих задач решается как простыми средствами, так и полноценными ML-моделями. Выбор зависит от масштаба инфраструктуры и зрелости процессов.

Дедупликация и группировка алертов: как перестать тонуть в уведомлениях

Один упавший сервер может сгенерировать 50 алертов: недоступность порта, таймауты на зависимых сервисах, рост очередей, срабатывание health check. Инженер получает 50 писем, 30 push-уведомлений и 15 сообщений в Slack. Все они описывают одну проблему.

ML-подход к дедупликации использует кластеризацию текстов алертов. Алгоритмы TF-IDF или эмбеддинги преобразуют текст уведомления в вектор и группируют похожие сообщения. Временное окно добавляет контекст: алерты, пришедшие в течение 5-10 минут, с высокой вероятностью относятся к одному инциденту. Топологическая информация уточняет группировку: алерты от сервисов, зависящих от упавшего компонента, объединяются с корневым алертом.

Практический пример: группировка алертов в Prometheus

Базовую группировку можно настроить без ML. Alertmanager поддерживает параметры group_by, group_wait и group_interval. Пример конфигурации:

route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'team-devops'

receivers:
- name: 'team-devops'
  slack_configs:
  - channel: '#alerts'
    send_resolved: true

Эта настройка собирает алерты с одинаковыми метками в один инцидент. group_wait ждет 30 секунд перед отправкой первого уведомления, чтобы захватить каскадные алерты. group_interval ограничивает частоту повторных уведомлений. Эффект: количество сообщений снижается в 3-5 раз без единой ML-модели.

Ограничение: Alertmanager группирует по точному совпадению меток. Он не понимает, что алерт «High CPU on db-primary» и алерт «Connection timeout on app-server» связаны. Для этого нужна корреляция.

Корреляция событий по топологии: видеть лес за деревьями

Корреляция связывает алерты из разных систем в единую картину инцидента. Когда база данных тормозит, приложение начинает отдавать ошибки, балансировщик показывает рост latency, а очередь сообщений переполняется. Традиционный мониторинг показывает четыре независимые проблемы. Корреляция по топологии показывает одну: деградация БД.

Подходы к корреляции:

• Графовые модели - инфраструктура представляется как граф зависимостей. Алерт на узле распространяется на связанные узлы.
• Правила на основе зависимостей - явное описание связей между сервисами в конфигурации.
• Временная корреляция - алерты, возникшие в одном временном окне, группируются как связанные.

Для хранения топологии используют графовые базы данных, например Neo4j. Связи между сервисами извлекаются из систем service discovery, Kubernetes-манифестов или конфигураций IaC.

Обнаружение аномалий с динамическими базовыми линиями

Статические пороги устаревают. Порог «CPU выше 85%» не работает, когда сервис получает плановую нагрузку в конце месяца или во время маркетинговой кампании. Динамические базовые линии строятся на исторических данных и учитывают сезонность, тренды и паттерны нагрузки.

Методы обнаружения аномалий:

• Скользящее среднее - сравнение текущего значения с средним за последние N минут.
• Сезонная декомпозиция - разделение метрики на тренд, сезонность и шум.
• Изоляционный лес - ML-алгоритм, который изолирует аномальные точки в многомерном пространстве.

Prometheus предоставляет функции predict_linear и holt_winters для прогнозирования метрик. predict_linear предсказывает значение метрики на основе линейной регрессии, holt_winters применяет экспоненциальное сглаживание с учетом сезонности.

Пример: обнаружение аномалий в метриках с помощью PromQL

Динамический порог на основе стандартного отклонения:

(
  node_cpu_seconds_total{mode="idle"}
  - avg_over_time(node_cpu_seconds_total{mode="idle"}[1h])
) / stddev_over_time(node_cpu_seconds_total{mode="idle"}[1h]) > 3

Этот запрос срабатывает, когда текущее значение отклоняется от среднего за час более чем на три стандартных отклонения. Порог адаптируется к изменениям нагрузки автоматически. Для более сложных сценариев, когда метрика имеет выраженную сезонность, используются модели на основе Prophet или нейронных сетей, но PromQL закрывает 70% практических задач.

LLM в AIOps: саммаризация логов, подбор runbook и генерация постмортемов

Большие языковые модели решают текстовые задачи эксплуатации. Они не заменяют ML-модели для численного анализа метрик, а дополняют их. LLM хорошо справляются с тремя сценариями:

• Саммаризация логов - сжатие тысяч строк логов в краткое описание проблемы.
• Подбор runbook - поиск подходящей инструкции по устранению инцидента в базе знаний.
• Генерация постмортемов - создание черновика отчета об инциденте на основе алертов и действий команды.

Пример промпта для саммаризации логов:

Ты - SRE-инженер. Проанализируй логи ниже и составь краткое описание инцидента.
Укажи: вероятную причину, затронутые сервисы, временные рамки, рекомендуемые действия.
Логи:
{log_content}

Важно: LLM не заменяет анализ метрик. Он работает с текстом, который уже собран и отфильтрован. Численные аномалии остаются задачей ML-моделей и статистических методов.

Кейс: автоматическое создание описания инцидента из алертов

Практическая реализация на Python с вызовом LLM API:

import requests

def summarize_alerts(alerts: list) -> str:
    prompt = f"""Собери описание инцидента из алертов:
    {alerts}
    Формат: заголовок, затронутые сервисы, вероятная причина, приоритет."""
    
    response = requests.post(
        "https://api.llm.example/v1/chat/completions",
        json={
            "model": "gpt-4o",
            "messages": [{"role": "user", "content": prompt}],
            "temperature": 0.1
        }
    )
    return response.json()["choices"][0]["message"]["content"]

Скрипт собирает алерты из Alertmanager, передает их в LLM и получает структурированное описание инцидента. Это описание можно отправить в Slack или использовать как основу для тикета в Jira.

Риски и ограничения: галлюцинации, эффект «няньки» и наблюдаемость AI

LLM галлюцинируют. Модель может придумать несуществующую причину инцидента или указать неверный runbook. В постмортемах это опасно: отчет с вымышленными фактами попадает к руководству и искажает картину произошедшего. Каждый вывод LLM должен проверяться инженером.

Эффект «няньки» возникает, когда инженеры слепо доверяют AI. Модель предложила диагноз, команда не проверила, инцидент затянулся. Автоматизация не снимает ответственности с людей. LLM - инструмент, который ускоряет работу, но не заменяет экспертизу.

Наблюдаемость самого AI-слоя - отдельная проблема. Метрики качества ML-моделей: точность группировки, доля ложных срабатываний, время от алерта до предложенного диагноза. Без мониторинга этих метрик невозможно понять, работает ли AIOps или создает дополнительный шум. Практика показывает: 73% ML-проектов не доходят до продакшена именно из-за проблем с интеграцией и мониторингом.

Рекомендации по контролю:

• Логировать все выводы LLM с версией модели и входными данными.
• Ввести human-in-the-loop для критических действий: перезапуск сервисов, изменение конфигурации.
• Настроить алерты на метрики самого AI-слоя: задержка ответа, доля ошибок, количество галлюцинаций.

Пошаговый план внедрения AIOps «малой кровью»

Внедрение AIOps не требует покупки enterprise-платформы. Начните с существующего стека Prometheus и Alertmanager, добавляйте интеллектуальные слои постепенно.

Этап 1: Оптимизация Alertmanager

Первый шаг - навести порядок в алертах. Настройте группировку, дедупликацию и маршрутизацию. Пример конфигурации:

global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
  - match:
      severity: critical
    receiver: 'oncall'
    group_wait: 10s
  - match:
      severity: warning
    receiver: 'team'

receivers:
- name: 'oncall'
  pagerduty_configs:
  - service_key: 'your-key'
- name: 'team'
  slack_configs:
  - channel: '#alerts'

Ожидаемый эффект: снижение количества уведомлений на 40-60% за счет группировки и дедупликации.

Этап 2: Динамические пороги в Prometheus

Замените статические пороги на статистические. Пример алерта на аномальное отклонение latency:

alert: AnomalousLatency
 expr: |
   (
     histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
     - avg_over_time(histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))[1h])
   ) / stddev_over_time(histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))[1h]) > 3
 for: 5m
 labels:
   severity: warning
 annotations:
   summary: "Аномальная latency на {{ $labels.instance }}"

Выбор окна: 1 час для быстрых изменений, 24 часа для суточной сезонности. Порог 3 стандартных отклонения дает хороший баланс между чувствительностью и ложными срабатываниями.

Этап 3: Интеграция LLM для саммаризации

Добавьте простой скрипт, который собирает алерты из Alertmanager и отправляет их в LLM для создания описания инцидента. Пример вывода:

Инцидент: Деградация сервиса payments
Затронутые сервисы: payments-api, postgres-payments, redis-cache
Вероятная причина: рост latency на postgres-payments с 14:32
Приоритет: высокий
Рекомендуемые действия: проверить планы запросов, увеличить connection pool

Интеграция занимает 1-2 часа с использованием готовых библиотек. LLM не заменяет инженера, но сокращает время на составление первичного описания инцидента с 15-20 минут до 1-2 минут.

Заключение: AIOps - это эволюция, а не революция

AIOps начинается с гигиены алертов. Alertmanager и PromQL закрывают базовые задачи дедупликации, группировки и обнаружения аномалий. ML-модели добавляются для корреляции по топологии и сложных паттернов. LLM помогает с текстовыми задачами: саммаризация логов, подбор runbook, черновики постмортемов.

Ключевое правило: каждый слой автоматизации должен быть наблюдаемым и контролируемым. Галлюцинации LLM и слепое доверие к AI создают новые риски. Начните с настройки Alertmanager, добавьте динамические пороги в Prometheus, затем подключите LLM для саммаризации. Каждый этап дает измеримый эффект без крупных инвестиций.

Подписаться на канал