ИИ в эксплуатации (AIOps): разбор алертов и автоматизация инцидентов

В марте 2025 года аналитическое агентство Gartner сделало то, чего индустрия ждала несколько лет: официально переименовало рыночную категорию AIOps в Event Intelligence Solutions — решения для интеллектуальной обработки событий. Причиной стал ИИ-хайп, из-за которого слово «AIOps» превратилось в бессмыслицу. Вендоры называли искусственным интеллектом всё, от простейших регулярных выражений до тяжёлых LLM, обещающих полную автономию эксплуатации. В итоге ИТ-директора разочаровались, а инженеры получили очередной слой непредсказуемой автоматики.

Но реальная технологическая потребность никуда не исчезла. Когда в три часа ночи у вас падает сетевой коммутатор, а мониторинг за пару минут генерирует три сотни алертов во все каналы связи, вам не очень интересны «глобальные ИИ-стратегии». Вам нужен инструмент, который прямо сейчас отделит сигнал от шума и покажет, куда конкретно прикладывать руки, чтобы поднять прод. Да и термин AIOps всё равно никуда не делся: вендоры и инженеры продолжают его широко использовать как исторически сложившийся.

С подготовкой статьи помогали:

Константин Некрасов

Ведущий аналитик-исследователь в Газпромбанке, аналитик кафедры криптологии и кибербезопасности НИЯУ МИФИ, эксперт Нетологии на курсе «DevOps-инженер»

Антон Бондар

Эксперт команды SRE Databases во ВКонтакте

Алерт-шторм: почему классический мониторинг больше не масштабируется

Представьте стандартную ночь дежурного on-call инженера. В 02:15 в дежурном чате срабатывает триггер: просела скорость ответов одного из микросервисов. Через тридцать секунд просыпается база данных. Ещё через минуту Grafana загорается красным: отвалились смежные сервисы, выросли 500-е ошибки на шлюзе, а Alertmanager начинает бомбардировать личку десятками однотипных уведомлений. За четверть часа инженер получает около двухсот оповещений. Глаза замыливаются, начинается суета, а истинная причина — например, кривой конфиг в недавнем минорном деплое — тонет в этой лавине.

Избыток повторяющихся и малополезных уведомлений приводит к alert fatigue — снижению внимания и доверия к системе оповещений. В результате инженер может пропустить действительно важный сигнал.

Цифры отчётов за 2025 год подтверждают, что индустрия столкнулась с пределом:

• По данным отчёта Splunk «State of Observability 2025», 73% организаций сталкивались с простоями систем именно из-за проигнорированных или подавленных оповещений. 

• Согласно The SRE Report 2025 (Catchpoint), почти 70% инженеров по надёжности называют стресс от дежурств одним из прямых факторов выгорания. У 14% уровень стресса после инцидента оказался выше, чем во время него.

• Парадокс рутины (Toil): В том же отчёте Catchpoint зафиксирован тревожный тренд — впервые за пять лет доля ручной операционной рутины в SRE выросла с 25% до 30% рабочего времени. 

Нагрузка распределяется так: 46% опрошенных инженеров разбирают более 5 инцидентов за месяц, а 23% — от 6 до 10.

Пытаться решить эту проблему, переписывая статические правила в Prometheus, — утопия. Поддерживать тысячи порогов вручную невозможно. Именно на этом стыке возникает потребность в дополнительном интеллектуальном слое, который возьмет на себя первичную обработку потока событий.

Что такое AIOps и что он умеет сегодня

Если отбросить презентации вендоров, под капотом систем «умного» мониторинга нет никакой магии общего искусственного интеллекта (AGI). Именно поэтому Gartner ввел термин Event Intelligence — он гораздо точнее описывает суть. Это специализированный слой обработки данных, который использует классическое машинное обучение (ML), теорию графов и статистический анализ под узкий круг задач автоматизации.

Чтобы понять, как эти алгоритмы работают на практике, проследим за развитием одного ночного сбоя через три ключевые задачи, которые Event Intelligence решает уже сегодня.

На схеме выше показан этот конвейер: сырые телеметрические данные (Logs, Metrics, Events, Traces) поступают на вход движка, где последовательно проходят через сита фильтрации, корреляции и поиска первопричины (Root Cause Analysis). На выходе инженер получает структурированную карточку инцидента.

Разберём механику этих этапов на сквозном примере.

1. Дедупликация и группировка (Deduplication & Clustering)

Проблема. На одном из серверов базы данных начинает деградировать дисковый массив. В течение трёх минут диски начинают отдавать данные с огромной задержкой. Мониторинг мгновенно генерирует веер алертов: 50 микросервисов кричат о таймаутах, Nginx пишет о 504 ошибках, системы очередей сообщают о переполнении буфера. Дежурный получает около 200 уведомлений.

Как решает алгоритм. Вместо отправки каждого триггера по отдельности движок анализирует метаданные: таймстампы, ID кластеров, имена инстансов. Алгоритмы кластеризации понимают, что все 200 событий произошли в одном временном окне и логически связаны. Они схлопываются в один инцидент: «Пакетный сбой: деградация ответов upstream-сервисов». 

Константин Некрасов

Ведущий аналитик-исследователь в Газпромбанке, аналитик кафедры криптологии и кибербезопасности НИЯУ МИФИ

Например, в Kubernetes падение одной ноды (NodeNotReady) порождает каскад событий: PodEvicted, ContainerUnhealthy, VolumeDetachFailed. Классический Alertmanager сгруппирует их по namespace, но умный движок через API Kubernetes строит дерево зависимостей и видит, что все 50 упавших подов принадлежат одному ReplicaSet под управлением одного Deployment. Вместо 50 алертов инженер получает один: «Деградация Deployment payment-service из-за потери ноды worker-03». Дальше сразу можно применить remediation — cordon проблемной ноды и масштабирование деплоймента на другие узлы, не проверяя каждый под вручную.

2. Корреляция по времени и топологии (Event Correlation)

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

Как решает алгоритм. Система сопоставляет временные ряды (когда именно начались аномалии) со встроенной картой инфраструктуры — топологией (Service Dependency Map). Алгоритм строит направленный граф зависимостей и видит: Деградация дисков (Storage) -> Задержки на СУБД (Data Layer) -> Рост 500-х ошибок на API (Application Layer). Сопоставив эти сущности, система не просто группирует сообщения, а выстраивает цепочку зависимостей и подсвечивает наиболее вероятную первопричину сбоя (Root Cause).

3. Обнаружение аномалий (Anomaly Detection)

Проблема. Традиционный алертинг опирается на статические пороги (Disk IOPS > 5000 или CPU > 85%). Но в 15:00 во время распродажи высокая нагрузка — это норма, а в 04:00 утра — признак зависшего процесса. Статические пороги заставляют дежурных либо ловить ложные тревоги по ночам, либо пропускать реальные проблемы днём.

Как решает алгоритм. Вместо жёстких цифр ML-модель строит динамическую базовую линию (baseline) на основе исторических данных. Она вычисляет профиль «поведенческой нормы» для каждого дня недели и часа суток с учетом сезонности. Алерт сработает только тогда, когда текущее значение метрики выйдет за пределы её индивидуального коридора нормальности для данного момента времени.

Константин Некрасов

Ведущий аналитик-исследователь в Газпромбанке, аналитик кафедры криптологии и кибербезопасности НИЯУ МИФИ

Для платежного шлюза характерны резкие всплески трафика в «чёрную пятницу» или зарплатные дни. Статический порог RPS > 1000 будет постоянно ложно срабатывать. Модель Prophet или LSTM-сети, обученные на данных за последние 3 месяца, строят прогноз с доверительным интервалом. Если в обычный вторник в 14:00 RPS внезапно падает до 10 при норме 500, система мгновенно детектирует аномалию, даже если абсолютное значение не достигло «критического нуля». И наоборот, во время распродажи рост до 5000 RPS игнорируется, так как он укладывается в предсказанный сезонный тренд. Это критично для снижения False Positive Rate (FPR) в высоконагруженных системах.

Три перечисленные задачи — это базовый минимум систем Event Intelligence, но на практике они умеют заметно больше. Например, они будут полезны и для Topology Discovery, Service Dependency Mapping, Probable Root Cause Analysis. Эти функции составляют ядро современных платформ вроде Dynatrace Davis AI, Splunk ITSI, IBM Cloud Pak for AIOps и BigPanda.

Опыт российских команд

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

Переход на динамический baseline в Яндексе. В масштабах инфраструктуры Яндекса поддерживать статические пороги вручную физически невозможно. Команда запустила пилот в общеяндексовой системе метрик Monium: на 46 ключевых регионах Яндекс Такси (по 4 критические метрики, всего 184 алерта) статические пороги заменили на алгоритмы обнаружения аномалий — авторегрессию и MEDIFF, которые учатся на исторических графиках трафика и учитывают ночные спады и дневные пики. После калибровки (ручная настройка понадобилась лишь для трёх небольших городов) система полгода работала стабильно, а команда SRE теперь реагирует на все уведомления из канала.

Дедупликация по лейблам во Фланте. Команда Фланта за 10 лет дежурств по инфраструктуре на Kubernetes выстроила дедупликацию на строгой логике лейблов. Уникальный набор лейблов служит идентификатором алерта — это позволяет объединять однотипные срабатывания в серии и резко сокращать поток (миллионы событий в день сжимаются до обозримого числа).

Сам принцип «топология важнее чистого ML» — общий для индустрии: и Datadog, и BigPanda, и IBM строят корреляцию поверх карты зависимостей, потому что ML на голых временных рядах без контекста инфраструктуры даёт шум. Отсюда практическое правило: если падает физическая нода, автоматика должна сразу подавить (silence) дочерние алерты от её подов, чтобы дежурный видел первопричину — отказ железа, а не сотню следствий.

Классический AIOps ≠ LLM: где чья работа

На волне хайпа вокруг генеративного ИИ у многих ИТ-руководителей и инженеров возникло опасное заблуждение: кажется, что современный AIOps — это просто «прикрутить GPT к alertmanager в Slack».

Это не так. Классический Event Intelligence и большие языковые модели (LLM) — это принципиально разные инструменты. Они работают на разных математических моделях и обрабатывают разные типы данных. Искать аномалии во временных рядах с помощью LLM так же неэффективно, как парсить терабайты текстовых логов регулярными выражениями на bash в реальном времени.

Обязанности между ними делятся так:

Что большие языковые модели реально добавляют в процесс эксплуатации

Если классический ML отвечает за математику (найти аномалию, схлопнуть дубли, связать события по времени), то LLM берёт на себя роль интеллектуального интерфейса между системой и дежурным инженером. Вот пять сценариев, где они могут принести пользу уже сейчас:

1. Быстрая саммаризация контекста и логов. Когда инцидент сложный, в дежурном чате могут быть сотни сообщений от разных команд, а в Kibana — тысячи строк трейсбеков. Вместо того, чтобы перечитывать этот хаос, инженер может попросить LLM сделать выжимку. Модель мгновенно выдаст: «Сервис упал с NullPointerException на строке 42 при попытке распарсить поле discount_code в JSON. В чате команда бэкенда уже проверяет недавний релиз».

2. Мгновенный подбор Runbook. Когда горит прод, у инженера нет времени блуждать по корпоративной Confluence или Notion. LLM, подключённая к внутренней базе знаний, по описанию аномалии способна выдать точную инструкцию по локализации сбоя: «Для этого типа алертов выполните шаги из Runbook-12 (ссылка). Команда для очистки кэша: …».

3. Ответы на запросы на естественном языке. Вместо написания сложных и тяжёлых SQL- или PromQL-запросов в Grafana в состоянии стресса, инженер может спросить человеческим языком: «Покажи мне все сервисы, у которых за последние 15 минут выросло время ответа, и найди, какие релизы деплоились в это же время».

4. Автоматический черновик постмортема. Самая нелюбимая рутина любого SRE — писать отчёт об инциденте после того, как все починили. LLM может собрать хронологию: когда сработал первый алерт, какие метрики вышли за baseline, в какое время инженер применил команду отката и когда система стабилизировалась. На выходе получается готовый на 80% черновик постмортема, который человеку остается только проверить и зафиналить.

5. Разбор логов легаси-систем. При миграции монолита на микросервисы всплывают ошибки интеграции со старыми системами — Mainframe, SOAP-сервисы, — логи которых неструктурированы и часто в старых кодировках. LLM может парсить сырые логи stderr, находить паттерны ошибок, которые регулярными выражениями выделить сложно из-за вариативности сообщений, и сопоставлять их с документацией по API. Например, модель может заметить, что ошибка HTTP 503 коррелирует не с нагрузкой, а с изменением формата даты в запросе к легаси-системе после обновления библиотеки-клиента, и предложить конкретный хотфикс для сериализатора.

С чем LLM пока не помогут

Инженерам важно понимать границы применимости генеративных моделей, чтобы не совершать критических ошибок:

• Потоковая обработка сырых метрик. LLM физически не способны обрабатывать миллионы таймстампов в секунду. Они слишком медленные и дорогие для этой задачи.

• Принятие детерминированных решений. Вероятностная природа LLM означает, что на один и тот же запрос в разные моменты времени модель может выдать слегка отличающиеся ответы. Для критической инфраструктуры это неприемлемо.

• Поиск истинной первопричины (Root Cause) в коде. LLM может предположить, почему упала система, опираясь на похожие случаи из обучающей выборки. Но она не знает реального состояния вашей сети в данную секунду и может увести расследование по ложному следу или попросту галлюцинировать.

Классический ML — это «глаза и уши» мониторинга, которые видят аномалии в цифрах. LLM — это «переводчик», который перекладывает сложный язык инфраструктуры на понятный человеческий и помогает быстрее работать с текстами и инструкциями. 

Автоматизация ответа: где можно доверить действие, а где только подсказку

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

В российских продуктах и западных практиках этот процесс называют auto-remediation, автоматическое устранение, или «самолечение» — автохилинг. Но неаккуратный запуск автоматических скриптов в прод — это кратчайший путь к каскадной аварии, когда «умный» бот в попытках починить систему добивает её окончательно.

Чтобы этого не произошло, внедрять автоматизацию ответов нужно строго по градации автономности, сохраняя баланс между скоростью реакции и безопасностью инфраструктуры.

Четыре уровня автономии ИИ в инцидентах

Безопасный автохилинг строится по принципу постепенного расширения прав автоматики. Нельзя прыгнуть с нулевого уровня на последний, минуя промежуточные. Ниже — практическая градация автономности, её можно взять за основу при проектировании. Это не универсальный отраслевой стандарт: конкретные уровни и названия в разных компаниях могут отличаться в зависимости от задач. 

Уровень 1: Информационная подсказка (Advisory). Система не принимает решений. Она просто собирает контекст инцидента и пишет в тикет или чат: «Похожие симптомы наблюдались 14 дней назад в инциденте #4412, тогда помог перезапуск пода payment-backend». Дежурный делает всё руками.

Уровень 2: Интерактивный ранбук (Human-in-the-loop). Алгоритм не просто находит инструкцию, а готовит конкретное действие, но не выполняет его без подтверждения. В чате появляется кнопка: [Запустить очистку кэша Redis]. Инженер валидирует контекст, нажимает кнопку, автоматика выполняет сценарий через API. Финальное слово всегда за человеком.

Уровень 3: Условная автономия (Conditional Automation). Автоматика имеет право самостоятельно выполнять строго определенные, безопасные действия при жёстких ограничениях. Например: «Если алерт сработал в нерабочее время, а глубина очереди превысила порог X — примени скрипт Y. Но делай это не чаще одного раза в час».

Уровень 4: Полная автономия (Autonomous Auto-remediation). Система сама обнаруживает сбой, оркеструет цепочку исправлений, проверяет метрики после применения и закрывает инцидент. Для современного прода этот уровень — скорее исключение, применимое для узко изолированных задач.

Золотое правило автохилинга: цена отката

Как понять, какую задачу можно отдать триггеру на автоматическое исполнение, а где инженера нужно подключать обязательно? Всё упирается в простое правило: доверять действие автоматике можно только там, где цена ошибки минимальна, а откат (rollback) — дешёвый, быстрый и предсказуемый.

Разбор сценария автохилинга на практике

Разберём классический пример автоматического устранения инцидента уровня Middle+ на базе связки Prometheus → Webhook → Ansible или Скрипт.

Инцидент. На одной из нод кластера заканчивается свободное место на диске (DiskSpaceFillingUp). До критического падения системы осталось 15 минут. На часах 03:40 утра.

Логика автоматики (Auto-remediation):

1. Prometheus фиксирует скорость заполнения диска и шлёт алерт в Alertmanager.

2. Alertmanager маршрутизирует событие не в личку инженеру, а дёргает Webhook автоматического воркера очистки.

3. Движок автохилинга запускает безопасный сценарий первого уровня: очистка кэша пакетов (apt-get clean), удаление неиспользуемых локальных образов старше указанного срока (docker image prune -a --filter "until=24h").

4. После выполнения скрипта система берёт прописанную паузу и проверяет метрику свободного места.

Вариант А (Успех). Место освободилось, метрика вернулась в baseline. Автоматика пишет отчёт в Jira или Slack: «Инцидент INC-882 закрыт автоматически. Освобождено 45 ГБ за счёт очистки кэша и образов. Дежурного не трогали».

Вариант Б (Эскалация). Скрипт отработал, но место продолжает стремительно уменьшаться (например, какое-то приложение пишет аварийный лог в нетипичную директорию). Автоматика понимает, что её стандартный ранбук не помог. Происходит мгновенная эскалация: система включает звонок дежурному инженеру, прикладывая к алерту отчёт о том, что она уже попыталась сделать, чтобы человек не тратил время на базовые проверки.

Константин Некрасов

Ведущий аналитик-исследователь в Газпромбанке, аналитик кафедры криптологии и кибербезопасности НИЯУ МИФИ

Например, в системах с базами данных (PostgreSQL или MySQL) частая проблема — разрастание WAL-логов или временных таблиц из-за «зависшей» длинной транзакции. Простая очистка диска (rm -rf) здесь опасна и может повредить данные. Умный автохилинг в таком случае не просто чистит место, а взаимодействует с СУБД: он определяет PID процесса, держащего долгую транзакцию, через системные представления (pg_stat_activity), и отправляет сигнал CANCEL или TERMINATE этому соединению. Только после освобождения блокировок и автоматического завершения транзакции скрипт выполняет VACUUM или очистку временных файлов. Если это не помогает, система эскалирует инцидент с пометкой «Возможна логическая ошибка в приложении, требующая анализа кода», а не просто «Нет места на диске».

Обратная сторона медали: скрытые риски и иллюзии AIOps

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

Разберём, где и как умные системы могут подставить дежурного инженера.

Галлюцинации LLM в критических отчётах

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

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

Ложная корреляция и увод по ложному следу

Классические алгоритмы машинного обучения ищут математические совпадения во временных рядах. Но совпадение по времени (корреляция) не означает наличие причинно-следственной связи (каузальности).

Как это выглядит в проде. Ровно в 04:00 утра на сервере запускается тяжёлый плановый cron-скрипт бэкапа — метрика диска идёт вверх. В эту же секунду из-за бага в коде падает upstream-сервис авторизации. Движок Event Intelligence, не зная контекста кода, связывает эти события в одну карточку инцидента и выдаёт вердикт: «Причина падения авторизации — дисковая активность cron-задачи». Дежурный идёт отключать бэкапы, пока прод продолжает лежать.

Проблема «чёрного ящика» и кризис доверия

Большинство глубоких ML-моделей выдают результат, который трудно интерпретировать без дополнительных инструментов. Система говорит: «Это аномалия с вероятностью 94%». На вопрос «почему?» ответа нет.

Как это выглядит в проде. Инженеры уровня Middle+ и Senior обладают сильной интуицией и привыкли доверять проверяемым фактам. Если автоматика регулярно выдаёт алерты без прозрачной аргументации, команда быстро сталкивается с синдромом недоверия. Инженеры начинают либо полностью игнорировать подсказки системы, возвращаясь к ручному разбору, либо тратить вдвое больше времени на перепроверку «магических» выводов модели.

Эффект «няньки при ИИ» (AI Babysitting)

Феномен, который зафиксировал свежий отчёт The SRE Report 2025 (Catchpoint). Ожидалось, что ИИ уберёт рутину (toil) из жизни инженеров, но объём ручной работы только вырос до 30%.

Как это выглядит в проде. Вместо того чтобы заниматься развитием инфраструктуры, SRE-инженеры превращаются в «нянек» для алгоритмов. Они целыми днями размечают ложные срабатывания, донастраивают веса моделей, корректируют исторические выборки для обучения и объясняют движку, почему плановый хабраэффект или сезонная распродажа — это не повод слать аварийный сигнал. Рутина не исчезла, она просто сместилась из плоскости «разбери алерт» в плоскость «почини модель, которая разбирает алерт».

Наблюдаемость самого ИИ-слоя: кто дежурит по дежурному

Внедряя Event Intelligence, вы добавляете в свой продакшн-контур ещё один сложный, распределенный и ресурсоёмкий компонент. У него есть своя база данных (векторная или графовая), свои брокеры очередей и свои вычислительные воркеры.

Как это выглядит в проде. Если сам движок AIOps начнёт деградировать (например, из-за утечки памяти в воркере сбор логов начнёт отставать на 10 минут), система либо перестанет присылать алерты вовсе, либо начнёт выдавать их с огромным опозданием. Возникает вопрос: выстроена ли у вас наблюдаемость (observability) самого ИИ-слоя? Есть ли у вас простые, «глупые» статические триггеры в Prometheus, которые закричат, если умная платформа обработки событий упадёт?

Как застраховаться от рисков: правила инженерной гигиены

Чтобы внедрение умного мониторинга не принесло проблем, стоит соблюдать несколько жёстких правил:

• Shadow Mode на старте: Любая модель обнаружения аномалий или корреляции должна минимум месяц крутиться в «теневом режиме». Она собирает данные, генерирует инциденты, но не шлёт уведомления дежурным и не выполняет скрипты. Команда раз в неделю сравнивает реальные инциденты с тем, что «наловила» модель, и докручивает точность.

• Принцип Explainable AI: Не внедряйте решения, которые не могут декомпозировать свой вывод. Карточка инцидента должна содержать чёткие факты: «Сгруппировано 15 алертов, так как все они содержат тег cluster-id: prod-eu и начались в интервале 120 миллисекунд». Инженер должен видеть логику автоматики.

• Жёсткий Fallback: У вас всегда должен оставаться независимый, прямой и максимально простой канал прохождения критических алертов (например, PingFailed или DatabaseUnreachable), идущий в обход любых интеллектуальных платформ напрямую в Alertmanager. Если «умная» система зависнет, база должна суметь достучаться до человека напрямую.

С чего начать малой кровью: прагматичный подход на вашем стеке

Частая ошибка команд эксплуатации при знакомстве с концепцией Event Intelligence — это попытка сразу купить тяжёлую энтерпрайз-платформу, развернуть её поверх необъятной инфраструктуры и ждать чуда. К сожалению, это приводит лишь к тому, что к лавине алертов от Prometheus добавляется лавина непредсказуемых уведомлений от «умной» коробки.

Если классический стек (Prometheus, Grafana, Alertmanager, ELK / OpenSearch) у вас уже развёрнут, то всё необходимое, чтобы бороться с алерт-фатигой «малой кровью», тоже есть — без бюджетов и сложных ML-моделей.

Внедрение интеллектуальной обработки должно идти снизу вверх: от базовой гигиены к базовым алгоритмам.

Шаг 1: Выжмите максимум из Alertmanager. Прежде чем учить нейросеть группировать ваши алерты, настройте стандартные механизмы фильтрации. Настройте group_by, group_wait, group_interval и inhibition rules так, чтобы связанные уведомления объединялись в компактные группы. Например, алерты можно группировать по cluster, node и alertname. Добейтесь того, чтобы при падении одной ноды алерты от всех находящихся на ней подов гарантированно схлопывались в одно уведомление на уровне стандартного движка маршрутизации.

Шаг 2: Наведите порядок в лейблах (Labels). Ни один алгоритм корреляции по топологии не сможет связать базу данных с приложением, если в ваших метриках не разобраться. Сквозные и единообразные лейблы — необходимое условие для группировки и корреляции событий. Полезно заранее определить обязательные поля, например application, environment, cluster, namespace, node и tier, и проверять их наличие автоматически. Без этой разметки любая ML-система останется слепым «чёрным ящиком». 

Шаг 3: Попробуйте встроенную математику PromQL. Чтобы начать уходить от жёстких статических порогов, не обязательно разворачивать Python-воркеры с моделями прогнозирования. Используйте встроенные функции Prometheus, например predict_linear. Функция предсказывает, через какое время заполнится диск или переполнится очередь, опираясь на динамику последних нескольких часов. Это простейший, детерминированный, но эффективный предиктивный алертинг. 

Константин Некрасов

Ведущий аналитик-исследователь в Газпромбанке, аналитик кафедры криптологии и кибербезопасности НИЯУ МИФИ

Помимо predict_linear, для обнаружения аномалий в метриках с шумом эффективно использовать комбинацию функций avg_over_time и stddev_over_time для расчёта Z-Score прямо в PromQL. Например, алерт можно настроить так:

(current_value - avg_over_time(metric[1h])) / stddev_over_time(metric[1h]) > 3

Это означает, что текущее значение отклоняется от среднего за последний час более чем на 3 стандартных отклонения. Такой подход позволяет детектировать резкие скачки (spikes) или провалы (drops) в реальном времени без обучения сложных ML-моделей, оставаясь в рамках стандартного стека Prometheus и Grafana.

Если захочется копнуть глубже: как уйти от жёстких порогов к алертингу на бюджете ошибок и реальном пользовательском опыте — подробно разобрано в разделе Alerting on SLOs из книги Site Reliability Workbook. А чтобы разобраться с самой наблюдаемостью, на которой всё это держится, стоит заглянуть в две книги-опоры: «Обеспечение наблюдаемости ПО» — о том, чем наблюдаемость отличается от классического мониторинга по метрикам, и «Изучаем OpenTelemetry» — о современном сборе телеметрии, с которого начинается любой AIOps.

Чек-лист: как понять, что вам нужен Event Intelligence, и сделать первый шаг

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

✔️ Шаг 1. Оцените масштаб бедствия: Посчитайте чистый объём уведомлений. Если дежурный инженер получает суммарно более 50 алертов за смену (включая некритичные каналы) — фокус внимания размыт, резко повышается вероятность пропустить важный сигнал.

✔️ Шаг 2. Проведите ревизию мусора: Выделите топ-5 самых частотных алертов за последний месяц. Если среди них есть те, которые инженеры годами закрывают кнопкой Acknowledge без проведения реальных работ — удалите эти правила или поднимите их пороги. Это не мониторинг, это шум.

✔️ Шаг 3. Зафиксируйте «золотые сигналы» (Golden Signals): Уберите технические алерты по утилизации железа (CPU, RAM) из каналов экстренного оповещения. Переключите фокус дежурных на четыре ключевых показателя: задержка (Latency), трафик (Traffic), ошибки (Errors) и насыщение (Saturation). База данных может быть загружена на сколько угодно, но пока пользователи не начинают видеть ошибок и таймаутов — это не повод будить инженера ночью.

✔️ Шаг 4. Настройте базовое подавление (Inhibition rules): Убедитесь, что в вашем Alertmanager прописаны правила подавления. Если недоступен дата-центр целиком, автоматика должна заблокировать отправку сотен вторичных алертов от приложений, которые в нём крутились.

✔️ Шаг 5. Оцифруйте инструкции (Runbooks): Проверьте, к каждому ли критическому алерту привязана живая ссылка на документацию. Если дежурный должен сам вспоминать, как рестартовать сервис или где лежат логи — автоматизация вам пока не поможет, начните с наведения порядка в базе знаний.

✔️ Шаг 6. Начните вести строгий учёт MTTR: Замеряйте среднее время от момента фиксации аномалии до полной стабилизации системы. Без этих метрик вы не сможете оценить, помогло ли вам внедрение автоматики. 

✔️ Шаг 7. Выберите один пилотный сценарий автохилинга: Найдите самую простую, частую и рутинную операцию (например, очистка логов при заполнении диска на 90%). Напишите простой Ansible-плейбук или скрипт, который будет дергаться по вебхуку. Не пытайтесь автоматизировать всё и сразу.

✔️ Шаг 8. Запустите пилот в режиме Shadow Mode: Дайте любому новому скрипту автоматизации или модели поиска аномалий поработать «вхолостую» минимум 2–3 недели, лучше — месяц. Оцените точность срабатываний по логам до того, как доверите системе реальные действия в проде.

Эксплуатация всё больше опирается на автоматику и ИИ, и планка требований к инженерам растёт. Чтобы оставаться востребованным, полезно системно подтягивать навыки — будь то разработка, аналитика или управление. Можно изучить новое, начав с чего-то небольшого и бесплатного:

• вводного курса онлайн-магистратуры УрФУ «Программная инженерия цифровых решений»;

• демодоступа к лекциям и практике курса «Специалист по искусственному интеллекту»;

• вводного курса онлайн-магистратуры НИУ ВШЭ «Инженерия данных»;

• практической программы «ИИ в деле: ускорьте свою работу», которая включает 4 мини-проекта и 13 задач;

• вводного курса онлайн-магистратуры УрФУ «Инженерия машинного обучения».

Или можно сразу сделать решительный шаг к карьерному росту и повышению дохода с профессиональным обучением:

• на курсе «DevOps-инженер» с изучением ИИ и программой трудоустройства;

• в онлайн-магистратуре УрФУ «Инженерия машинного обучения»;

• на программе профпереподгготовки «Дата-инженер», где вас ждут 6 крупных проектов для портфолио и дипломная работа с поддержкой наставника;

• в онлайн-магистратуре НИУ ВШЭ «Инженерия данных»;

• на курсе «Инженер машинного обучения» с активным комьюнити студентов и экспертов, менторскими сессиями и поддержкой инженеров из Amazon, Яндекса, Сбера.