AIOps — это новая черная магия: почему ML в мониторинге чаще галлюцинирует, чем помогает

Centicore Group

По данным исследований рынка за 2025–2026 годы, инструменты AIOps действительно могут срезать до 95% мусорных уведомлений и ускорить поиск причин инцидента. Но этот механизм работает только поверх уже выстроенной системы мониторинга.

Эта статья — разбор Centicore Group того, где именно ломаются алгоритмы в мониторинге инфраструктуры, почему модели теряют связь с реальностью при изменении данных и как заставить AIOps-платформу работать нормально, а не генерировать новые проблемы.

Что нам обещали и с чем мы остались

Изначально AIOps продавали как волшебную таблетку. Загружаете логи и метрики, а на выходе получаете готовые решения проблем. Сегодня вендоры пошли еще дальше и добавили агентов на базе LLM, которые сами пишут отчеты об инцидентах и открывают треды в мессенджерах.

На практике почти все платформы — это старые добрые движки правил, обернутые в интерфейс с рекламой про ИИ. Специалисты Centicore Group, которые занимаются внедрением ИТ-решений, говорят об этой же проблеме: многотысячные (иногда миллионные) инвестиции не гарантируют результат. На рынке есть примеры компаний, которые тратили огромные деньги для внедрения ИИ, но в итоге продукт просто не работал стабильно на реальных нагрузках.

Как машинное обучение в мониторинге работает на самом деле

Почти любая AIOps-платформа проходит один и тот же путь: собирает сигналы, приводит их к общему формату, склеивает похожие события, ищет связи между ними и только потом формулирует итог для человека.

Четыре шага, которые делают все платформы

Система собирает сигналы из разных источников. На вход летят метрики из мониторинга, логи приложений, события оркестрации, данные об изменениях после деплоя и служебные уведомления от облака или CI/CD.
Система нормализует данные. У разных источников разные поля, названия и уровни детализации, поэтому платформа сначала приводит их к общей схеме: время события, сервис, хост, контейнер, severity, набор тегов.
Система группирует похожие уведомления и собирает инцидент. Дальше алгоритмы смотрят на время, теги, топологию сервисов и шаблоны сообщений. Если за пару минут сыпятся десятки однотипных алертов от одного сервиса, платформа схлопывает их в один инцидент.
Система ищет связи и формулирует вывод. После группировки движок корреляции пытается понять порядок событий: что сработало раньше, какой сервис тянет за собой остальные, где проходит общая зависимость. И только на этом этапе подключается языковая модель или шаблонный summarizer.

Базовый конвейер AIOps: как поток алертов превращается в одну карточку инцидента

Где заканчивается магия и начинается статистика

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

Самые полезные функции в AIOps вообще пришли из до-LLM эпохи. Лучше всего себя показали группировка похожих логов, дедупликация однотипных алертов и автоматическая подстройка порогов под реальное поведение системы.

Языковая модель не видит инфраструктуру напрямую и не заменяет движок мониторинга. Она берёт уже найденные события, собирает описание инцидента и помогает стартовать расследование. Поэтому качество её текста всегда зависит от качества предыдущих шагов.

Аномалия в мониторинге — это чаще всего отклонение от привычного паттерна, а не «озарение» модели

Три причины, почему умный мониторинг ломается в продакшне

Почти любая AIOps-платформа хорошо работает на стабильных данных и предсказуемых паттернах нагрузки. Но есть исключения.

Система не знает того, чего не видела

Любая модель в мониторинге учится на исторических данных. Она знает, как обычно ведёт себя сервис, какие пики нагрузки считаются нормой и какие комбинации событий уже встречались раньше. Если в проде появляется новый тип сбоя, у модели нет знаний об этом: она видит отклонение, но не понимает причину. AIOps хорошо помогает там, где инфраструктура уже накопила историю и повторяемые паттерны.

Новый тип инцидента ломает привычную логику модели: сигнал есть, точной причины нет

Смерть модели от изменения данных

Даже если модель однажды научилась отличать норму от сбоя, это состояние быстро устаревает. Инфраструктура меняется постоянно: выходят релизы, добавляются сервисы, меняется поведение пользователей, растёт объём запросов, сдвигаются пики нагрузки.

Нужно следить не только за сервисами, но и за качеством самой модели: проверять стабильность входных данных, отслеживать долю ложных срабатываний, закладывать регулярное переобучение после изменений в системе.

Concept drift: модель опирается на старую норму, а прод уже живёт по новым правилам

Языковые модели любят выдумывать

LLM появились в AIOps как удобный интерфейс к уже найденным событиям. Они умеют собрать сводку по инциденту, вытащить фрагменты из логов и подготовить черновик RCA. Но языковая модель генерирует наиболее правдоподобный ответ, а не гарантированно верный.

Финальный вывод о причине сбоя по-прежнему требует проверки по трассировкам, метрикам, событиям деплоя и реальному поведению зависимостей.

Карточка инцидента с двумя колонками: слева исходные сигналы, справа текстовый summary от LLM

Где алгоритмы приносят пользу

Сокращение шума — это то, что работает сразу. Вместо 200 алертов за двадцать минут инцидента инженер получает карточку с объединёнными событиями. Это убирает ситуацию, когда первые пять минут дежурный тратит на то, чтобы понять, сколько проблем перед ним — одна или двадцать.
Время на поиск причины сбоя сокращается по той же причине. Когда все связанные события уже собраны в одном месте и отсортированы по времени, инженер начинает расследование с готовой временно́й шкалой.

Главное условие: всё это работает только поверх уже организованного мониторинга. Если в системе есть мусор из устаревших правил, алертов без понятного ownership и уведомлений, на которые давно никто не реагирует, то AIOps уверенно группирует и этот мусор. Качество выходного сигнала всегда ограничено качеством входного.

Как выбрать вендора

Спросите, как именно система находит проблему. Если показывают алерт, который сработал потому, что CPU поднялось выше 90%, это пороговый мониторинг, а не ML. Нам нужен случай, когда модель нашла аномалию без заранее заданного порога.

Уточните, что происходит после крупного изменения в инфраструктуре. Добавили регион, поменяли архитектуру сервиса, выкатили новый компонент с другим паттерном нагрузки. Система должна адаптироваться к новым данным без ручного обновления.

Проверьте, умеет ли система учиться на ошибках. В нормальном продукте инженер может отметить алерт как ложное срабатывание, и система корректирует своё поведение для похожих ситуаций в будущем.

Спросите про cold start. Любой алгоритм, который обучается на ваших данных, требует времени на накопление baseline. Нормальный ответ — две-четыре недели на первичное обучение с явной деградацией качества в начале. Если говорят, что система работает корректно с первого дня без данных, это либо статические правила, либо модель, обученная на чужих данных, которые могут не совпадать с вашими паттернами.

Разница между плановым событием и реальным сбоем — именно её должна видеть система

Как внедрить умный мониторинг и не уволить половину команды

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

Сначала привести в порядок обычный мониторинг. Перед запуском AIOps нужно проверить data readiness: теги, источники телеметрии, качество логов, долю дублей и ложных срабатываний. Этот шаг нужен, потому что платформа опирается на те данные, которые уже есть, и плохо работает на разном потоке событий.
Начать с режима подсказок, а не с автопилота. Сначала включают read-only сценарий: система группирует события, предлагает причины и подтягивает контекст, но не делает автоматических действий сама. Автоматизацию подключают позже, когда команда уже видит, как платформа ошибается, и понимает, где ей можно доверять.
Погонять систему в shadow mode. Новый контур аномалий и корреляции лучше не выкатывать две-четыре недели до замены текущего alerting-процесса. За это время видно, что платформа пропускает и насколько её выводы совпадают с реальными инцидентами.
Раскатывать по сервисам, а не по всей инфраструктуре сразу. Практика staged rollout работает лучше большого запуска: команда берёт два-три хронически шумных сервиса, меряет эффект, публикует метрики по false positives и MTTR, а затем расширяет охват.
Собирать обратную связь каждую неделю. Сколько алертов схлопнулось корректно, сколько инцидентов она объединила ошибочно, сколько времени сэкономила.
Автоматизировать только низкорисковые действия. В пилотах AIOps автоматические runbooks закрывают часть повторяющихся тикетов, но безопасно это работает там, где есть понятные границы, откат и аудит. Сначала подходят простые действия вроде перезапуска зависшего процесса, очистки кэша или повторного запуска джобы, а доступ к чувствительным изменениям в проде лучше оставлять под ручным подтверждением.

Нормальное внедрение AIOps идёт по ступеням: сначала доверие к данным, потом доверие к модели

Финальная мысль

AIOps приносит пользу там, где команде нужно быстрее связывать события и экономить время на первом этапе инцидента. Но качество результата по-прежнему зависит от телеметрии, мониторинга и обратной связи от инженеров сильнее, чем от количества AI-функций в интерфейсе.

Если коротко, хороший AIOps не заменяет SRE-процесс и не снимает ответственность с команды. Он сокращает рутину, ускоряет triage и оставляет инженерам ту часть работы, где всё ещё нужны проверка и контекст.

Полезная граница внедрения: шум и рутина — платформе, решение и ответственность — команде