Мониторинг на статических порогах тонет в ложных алертах, а ручная корреляция событий отнимает часы. Мы внедряем 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 в существующую инфраструктуру?
Внедрение начинается с аудита текущего мониторинга: какие метрики собираются, какие алерты настроены, как выглядит процесс инцидент-менеджмента. Затем мы проектируем data pipeline и выбираем подходящие модели ML.
| Подход | Инструменты | Время внедрения |
|---|---|---|
| Anomaly detection метрик | VictoriaMetrics Anomaly Detection, Prometheus + Grafana ML | 4–6 недель |
| Alert correlation | Moogsoft, BigPanda, собственная реализация на Python | 6–8 недель |
| Log anomaly detection | OpenSearch ML Commons, ELK | 8–12 недель |
| Полный AIOps стек + auto-remediation | Весь стек + Kubernetes | 4–6 месяцев |
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 Russian."""
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+ серверов):
| Показатель | До AIOps | После AIOps |
|---|---|---|
| Количество алертов в сутки | 500–2000 | 150–600 (снижение на 70%) |
| MTTR (среднее время восстановления) | 2–4 часа | 30–60 минут (снижение в 3–5 раз) |
| Число инцидентов, требующих эскалации | 80% | 30% |
| Время на разбор первопричины | 40 минут | 10 минут |
| Загрузка дежурных инженеров | 12 часов/день | 6 часов/день |
Экономия бюджета поддержки достигает $2k–5k. в месяц за счёт сокращения дежурств и ускорения диагностики.
Что входит в работу
- Аудит текущего мониторинга и процессов incident management.
- Проектирование data pipeline: сбор метрик, логов, событий.
- Настройка anomaly detection для ключевых метрик (CPU, память, ошибки).
- Внедрение alert correlation — группировка алертов, снижение шума.
- Log anomaly detection — выявление аномальных паттернов в логах.
- LLM-суммаризация инцидентов для быстрого анализа.
- Документация и обучение команды.
- Поддержка на этапе стабилизации (2 недели).
Подробнее о процессе
Каждый этап завершается демонстрацией результатов заказчику. Настройка ведётся итеративно: мы подбираем параметры моделей на исторических данных, затем внедряем в продакшен. Все изменения фиксируются в Git, а документация обновляется в Confluence.
Почему выбирают нас
Наши инженеры — сертифицированные специалисты с опытом внедрения AIOps более 5 лет. Мы реализовали более 20 проектов для компаний из ритейла, финтеха и телекома. Гарантируем снижение MTTR в 3–5 раз после завершения работ. Окупаемость внедрения — в среднем 6 месяцев за счёт сокращения времени на разбор инцидентов и уменьшения числа дежурств.
Получите консультацию: мы проанализируем ваш мониторинг и предложим план внедрения. Свяжитесь с нами, чтобы обсудить детали.







