Ко всем статьям

AIOps от телеметрии до GenAI — практический гид 2026

Как собрать AIOps без магии — от OpenTelemetry и ClickHouse до RCA, auto-remediation и generative-ассистентов. Рынок, архитектура, roadmap и подводные камни.

Поделиться в Telegram
Содержание

AIOps от телеметрии до GenAI — практический гид 2026

AIOps — это не «коробка, которая сама чинит прод». Это эволюция ответственности: данные → сигналы → гипотезы → действия с человеком в контуре. Ниже — сжатая, но рабочая карта по рынку, архитектуре, внедрению и GenAI-слою на 2026 год.


Почему сейчас

Объём телеметрии растёт быстрее, чем штат SRE. Классический алертинг по статическим порогам даёт шум, а поиск первопричины в микросервисах занимает часы. AIOps обещает:

  • меньше фальшивых алертов;
  • быстрее root cause analysis (RCA);
  • предсказуемые действия по типовым инцидентам;
  • позже — диалоговый слой поверх observability.

Без фундамента данных всё это быстро превращается в ещё один источник шума.


Рынок: коробки vs open-source

Gartner и практика рынка делят поле на два лагеря.

Корпоративные платформы

ServiceNow AIOps, BigPanda, Datadog Watchdog и аналоги:

  • быстрый старт и готовые коннекторы;
  • дорогой TCO;
  • ограниченная гибкость под свою архитектуру и data residency.

Подходят, когда нужна скорость «вчера» и команда небольшая.

Open-source / CNCF-стек

Prometheus, Loki/Grafana, Tempo/Jaeger, OpenTelemetry, Kafka, Flink, ClickHouse, MLflow/Kubeflow:

  • полный контроль и прозрачность;
  • нужна высокая квалификация;
  • вы сами отвечаете за reliability пайплайна.

Реалистичный гибрид 2026

Лидеры почти всегда строят гибрид:

  1. Телеметрия через OpenTelemetry.
  2. Потоки в Kafka → аналитическая БД (ClickHouse, StarRocks и т.п.).
  3. ML/правила через GitOps (MLflow, Kubeflow, Argo Workflows).
  4. Опционально — коммерческий слой для ITSM/incident management.

Так сохраняется прозрачность и возможность тонкой кастомизации.


Анатомия современной AIOps-платформы

1. Сбор и нормализация

  • Единый стандарт: метрики, логи, трейсы через OpenTelemetry.
  • Шина доставки (Kafka и аналоги) с контролем потери сообщений.
  • Обязательная система тегов: namespace, service, environment, version, owner.

Без единой разметки корреляция и ML разваливаются на этапе фич.

2. Feature engineering и хранилище

Сырые потоки превращаются в признаки:

  • скользящие перцентили латентности;
  • burst-счётчики ошибок;
  • эмбеддинги логов;
  • топология сервисов из трейсов.

Хранилища: ClickHouse/Druid + озеро на S3 (Iceberg/Delta). Для поиска похожих инцидентов — векторные БД (Qdrant, Milvus).

3. «Мозг» — алгоритмы

Задача

Подходы

Комментарий

Аномалии в метриках

Prophet + автоэнкодеры, isolation forest

Начинайте с простых baseline

Логи

Drain / Drain3, BERT-подобные модели

Кластеризация важнее «умного текста»

RCA

Граф сервисов + Bayesian / GAT

Объяснимость важнее accuracy в вакууме

Предиктив

LSTM, TFT

Только после стабильных golden signals

Auto-remediation

Runbooks в Argo / Ansible

Только при высокой precision и human gate

RL-агенты, которые сами меняют прод без утверждённых ранбуков, в 2026 всё ещё слишком рискованны для большинства команд.

4. Петля обратной связи

Инженер подтверждает или отвергает гипотезу → модель/правила дообучаются. Без human-in-the-loop зрелость почти недостижима.


AIOps и Platform Engineering

AIOps хорошо ложится на модель «платформа как продукт»:

  • Observability as Code — конфиги телеметрии в Git (Helm/Kustomize), изменения через MR.
  • GitOps для ML — код модели, пороги, фичи в репозитории; CI проверяет precision/recall и катит canary ML-движка.
  • Shift-left на деплое — модель, обученная на «плохих» выкатках, сравнивает поведение сервиса с эталоном и предлагает/запускает откат при характерном росте 5xx или latency.

Отдельная SRE/platform-команда может отдавать «AIOps as a Service» продуктовым командам: готовые дашборды, политики алертов, каталог runbooks.


Roadmap внедрения: 4 фазы

Фаза 1 — Data Foundation (1–3 мес.)

  • OpenTelemetry на ключевые сервисы.
  • Kafka + ClickHouse (или эквивалент).
  • Единая разметка сервисов и окружений.
  • Golden signals: latency, traffic, errors, saturation.

Фаза 2 — Augmented Operations (2–4 мес.)

  • Динамические baseline вместо жёстких порогов.
  • Базовая корреляция по графу сервисов.
  • Цель: −30…50% шума алертов без потери реальных инцидентов.

Фаза 3 — AI-Driven Response (4–8 мес.)

  • Автоматический RCA с объяснением.
  • Auto-remediation типовых проблем с подтверждением оператора.
  • Интеграция в ChatOps (Telegram/Slack).

Фаза 4 — Predictive & Generative (8+ мес.)

  • Прогноз насыщения и типовых сбоев.
  • RAG по внутренним runbooks и postmortem.
  • Генерация черновика отчёта по инциденту (человек утверждает).

Растите итеративно. Перескок сразу к GenAI без телеметрии — классический провал.


Подводные камни

  1. Ложные срабатывания. Без учёта maintenance windows и каскадной фильтрации команда выгорает.
  2. Грязные данные. Пропуски, битые лейблы, рассинхрон часов убивают модели. Нужны data contracts и гигиена пайплайна.
  3. Чёрный ящик. «Виноват сервис X, 92%» без графа/токенов/фич никто не примет. Нужна объяснимость (SHAP, evidence paths).
  4. Культурный страх. AIOps забирает рутину (перезапуски, поиск типовых логов), а не заменяет инженеров. Коммуницируйте это явно.

Generative AIOps: что реально в 2026

Gartner уже давно показал GenAI в I&O; практика догоняет осторожно.

Полезные сценарии:

  • NL-запросы к телеметрии: «аномалии payment-gateway за час» → краткий отчёт с гипотезой.
  • Черновики фиксов по логам (diff), которые ревьюит человек.
  • Мультимодальный RCA: трейсы + метрики + логи (+ скрин Grafana) → гипотеза с доказательствами.

Жёсткие ограничения:

  • Приватность: телеметрия не должна утекать во внешние LLM без политики. Self-hosted / private endpoint + RAG на внутренней документации.
  • Галлюцинации: действия в проде только по утверждённым runbooks, никаких «творческих» kubectl delete.

Чеклист «с чего начать на следующей неделе»

  1. Выберите 3–5 критичных сервисов и доведите OTel + единые теги.
  2. Соберите golden signals в одном месте (Grafana/ClickHouse).
  3. Введите suppression для плановых работ.
  4. Опишите 5 типовых инцидентов как runbooks.
  5. Только потом — baseline/аномалии и пилот RCA.

Итог

  1. Сначала данные: без OpenTelemetry нет разговора.
  2. Растите от baseline к RCA итеративно.
  3. Замыкайте обратную связь с инженерами.
  4. Доверяйте, но проверяйте: даже умный AI требует человеческого контроля.

AIOps — эволюция ответственности, а не магия. Фундамент телеметрии + GitOps + объяснимые модели + human gate дают результат; «купили коробку AI» — чаще дают шум.