Впровадження AIOps для автоматизації IT-операцій

Моніторинг на статичних порогах тоне в хибних алертах, а ручна кореляція подій забирає години. Ми впроваджуємо AIOps — підхід, що використовує машинне навчання для аналізу метрик, логів, подій та алертів. Мета — не замінити інженерів, а знизити alert fatigue, виявляти аномалії до інцидентів і автоматично корелювати події з різних джерел у єдину картину. Досвід показує: після впровадження AIOps кількість алертів скорочується на 70%, а MTTR знижується в 3–5 разів.

Розрив між теорією та практикою тут особливо великий. «Впровадити AIOps» звучить як купити продукт. Насправді — багатомісячна робота з побудови data pipeline з метрик, навчання baseline моделей, налаштування порогів та інтеграції з incident management. Ми гарантуємо, що ваш персонал отримає не просто інструмент, а працюючу систему, адаптовану під вашу інфраструктуру.

Що вирішує AIOps, чого не вирішує звичайний моніторинг

AIOps — це не просто тренд, а необхідність для великих інфраструктур. Prometheus з alert rules працює на статичних порогах: cpu > 80%. Проблема: нормальний рівень CPU в понеділок вранці — 70%, а в неділю вночі — 10%. Алерт на 80% або хибний (вночі), або спізнюється (в понеділок вже 90% до моменту спрацювання).

Anomaly detection дивиться не на абсолютні значення, а на відхилення від сезонного baseline. Якщо CPU зазвичай 70% в понеділок о 10:00, а сьогодні — 40% — це теж аномалія (можливо, сервіс перестав приймати трафік). Anomaly detection на 50% точніший за статичні пороги.

Друга задача — noise reduction. У великій інфраструктурі при одному інциденті спрацьовує 50–200 алертів: база недоступна → всі сервіси, які до неї звертаються, теж алертить → моніторинг цих сервісів теж. Event correlation групує їх в один інцидент з кореневою причиною.

Як впровадити AIOps в існуючу інфраструктуру?

Впровадження починається з аудиту поточного моніторингу: які метрики збираються, які алерти налаштовані, як виглядає процес incident-менеджменту. Потім ми проектуємо data pipeline та обираємо відповідні моделі ML.

Prometheus + Grafana ML Anomaly Detection

Grafana з Prophet-based forecasting через Grafana ML plugin:

---
# Grafana datasource для ML-оброблених метрик
apiVersion: 1
datasources:
  - name: Grafana ML
    type: grafana-ml-datasource
    url: http://grafana-ml:3000
    jsonData:
      prometheusUrl: http://prometheus:9090

Для Prometheus — metricbeat з ML jobs або VictoriaMetrics Anomaly Detection:

---
# VictoriaMetrics anomaly detection config
schedulers:
  periodic:
    class: "scheduler.periodic.PeriodicScheduler"
    infer_every: "1m"
    fit_every: "1h"
    fit_window: "14d"
models:
  zscore:
    class: "model.zscore.ZscoreModel"
    z_threshold: 2.5
  prophet:
    class: "model.prophet.ProphetModel"
    args:
      changepoint_prior_scale: 0.05
      seasonality_mode: "multiplicative"
      yearly_seasonality: false
      weekly_seasonality: true
      daily_seasonality: true
queries:
  cpu_usage:
    expr: "avg by (instance) (rate(node_cpu_seconds_total{mode!='idle'}[5m]))"
    step: "1m"
    model: "prophet"
  error_rate:
    expr: "rate(http_requests_total{status=~'5..'}[5m])"
    step: "1m"
    model: "zscore"

Результат — метрика anomaly_score від 0 до 1. Алерт спрацьовує при anomaly_score > 0.8, а не при cpu > 80%. Це знижує MTTR в 3 рази порівняно з ручною кореляцією.

Alert Correlation з Moogsoft / BigPanda / OpenAI

Комерційні AIOps платформи (Moogsoft, BigPanda) беруть алерти з Prometheus, PagerDuty, ServiceNow та корелюють їх через ML. Для тих, хто не хоче платити за enterprise — open-source шлях через власну кореляцію.

Найпростіша кореляція: групування алертів за часовим вікном та спільними labels:

from collections import defaultdict
from datetime import datetime, timedelta

def correlate_alerts(alerts: list[dict], window_minutes: int = 5) -> list[dict]:
    """Групує алерти, що сталися в одному часовому вікні."""
    incidents = []
    used = set()
    for i, alert in enumerate(alerts):
        if i in used:
            continue
        group = [alert]
        alert_time = datetime.fromisoformat(alert['startsAt'])
        for j, other in enumerate(alerts[i+1:], i+1):
            if j in used:
                continue
            other_time = datetime.fromisoformat(other['startsAt'])
            # Алерт в тому ж часовому вікні
            if abs((other_time - alert_time).total_seconds()) < window_minutes * 60:
                # І в тій же namespace або на тому ж node
                if (alert['labels'].get('namespace') == other['labels'].get('namespace') or
                        alert['labels'].get('node') == other['labels'].get('node')):
                    group.append(other)
                    used.add(j)
        if len(group) > 1:
            incidents.append({
                "type": "correlated_incident",
                "root_cause_candidate": min(group, key=lambda a: a['startsAt']),
                "related_alerts": group[1:],
                "alert_count": len(group),
            })
        else:
            incidents.append({"type": "single_alert", **alert})
    return incidents

Перший алерт у групі — кандидат у root cause. Це не точно, але дає інженеру правильну точку старту.

Log anomaly detection з OpenSearch / Elasticsearch

OpenSearch ML Commons надає вбудований anomaly detection для логів:

PUT _plugins/_anomaly_detection/detectors
{
  "name": "error-rate-detector",
  "description": "Detect anomalies in error log rate",
  "time_field": "@timestamp",
  "indices": ["app-logs-*"],
  "feature_attributes": [
    {
      "feature_name": "error_count",
      "feature_enabled": true,
      "aggregation_query": {
        "error_count": {
          "value_count": {
            "field": "level",
            "script": {
              "source": "doc['level.keyword'].value == 'ERROR' ? 1 : 0"
            }
          }
        }
      }
    }
  ],
  "detection_interval": {
    "period": {
      "interval": 5,
      "unit": "Minutes"
    }
  },
  "window_delay": {
    "period": {
      "interval": 1,
      "unit": "Minutes"
    }
  }
}

Детектор навчається на 14 днях історичних даних і потім флагує аномальні сплески помилок раніше, ніж вони досягають SLO-порогу.

LLM для incident summarization

GPT-4 або локальна LLM (LLaMA через Ollama) для сумаризації інцидентів з логів та метрик:

import openai
from datetime import datetime, timedelta

def summarize_incident(prometheus_url: str, incident_start: datetime):
    # Збираємо метрики за період інциденту
    metrics = fetch_prometheus_metrics(prometheus_url, incident_start)
    logs = fetch_logs_from_loki(incident_start, incident_start + timedelta(hours=1))

    prompt = f"""You are a DevOps SRE. Analyze the following metrics and logs from a production incident and provide:
1. Root cause hypothesis
2. Affected services
3. Timeline of events
4. Recommended immediate actions

Metrics (last 30 min): {metrics}
Relevant log entries: {logs[:3000]}
Respond in Ukrainian."""

    response = openai.chat.completions.create(
        model="gpt-4-turbo",
        messages=[{"role": "user", "content": prompt}],
        max_tokens=1000,
    )
    return response.choices[0].message.content"}

Результат надсилається в Slack у момент створення інциденту — інженер отримує structured summary замість 200 рядків алертів.

Яких результатів очікувати?

Порівняння до та після впровадження AIOps на типовій інфраструктурі (1000+ серверів):

Економія бюджету підтримки досягає 200 000–500 000 грн на місяць за рахунок скорочення чергувань та прискорення діагностики.

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

• Аудит поточного моніторингу та процесів incident management.
• Проектування data pipeline: збір метрик, логів, подій.
• Налаштування anomaly detection для ключових метрик (CPU, пам'ять, помилки).
• Впровадження alert correlation — групування алертів, зниження шуму.
• Log anomaly detection — виявлення аномальних патернів у логах.
• LLM-сумаризація інцидентів для швидкого аналізу.
• Документація та навчання команди.
• Підтримка на етапі стабілізації (2 тижні).

Чому обирають нас

Наші інженери — сертифіковані спеціалісти з досвідом впровадження AIOps понад 5 років. Ми реалізували більше 20 проектів для компаній з ритейлу, фінтеху та телекому. Гарантуємо зниження MTTR у 3–5 разів після завершення робіт. Окупність впровадження — в середньому 6 місяців за рахунок скорочення часу на розбір інцидентів та зменшення кількості чергувань.

Отримайте консультацію: ми проаналізуємо ваш моніторинг і запропонуємо план впровадження. Зв'яжіться з нами, щоб обговорити деталі.