Что происходит, когда 340 алертов превращаются в один инцидент
AIOps-агент на дежурстве читает метрики, логи, трассировки, историю изменений и обращения клиентов, находит в этом потоке связанные оповещения и отдаёт инженеру один инцидент вместо сотни уведомлений. На выходе получается не список «что-то упало», а описание причины, перечень затронутых сервисов и черновик действий.
Сцена из кейса: 340 алертов за двадцать минут, все про одну сетевую ноду. Агент склеил их в один инцидент, и дежурному осталось проверить выводы вместо ручного перебора уведомлений. Кейс разобран на примере недели дежурного инженера Алексея и агента «Цифровой техлид» в материале Дениса Романова. Автор оформил его как пьесу, так что числа берём из сюжета, а не из замеров на боевой инфраструктуре.
Граница ответственности проходит по последнему шагу. Агент предлагает решения, и среди них бывают рискованные: перезапуск приложения с активными операциями, например. Финальное действие подтверждает инженер. В кейсе эта мысль звучит прямо: последнее слово остаётся за человеком, который контролирует принятие решений.
Почему 340 алертов - это не 340 проблем: механика корреляции
Триста сорок уведомлений не означают триста сорок поломок. Классический AIOps сначала выполняет корреляцию: группирует оповещения по времени появления, по общим метрикам, по топологии сервисов и по карте зависимостей. Если все 340 алертов ссылаются на одну сетевую ноду и на сервисы, которые от неё зависят, у системы есть основание собрать один инцидент с корневой причиной и списком пострадавших зависимостей.
Без карты зависимостей корреляция деградирует до группировки по времени. Тогда два разных сбоя, совпавшие по минуте, слипаются в один инцидент, а один сбой, растянутый на полчаса, распадается на несколько. Дежурный получает аккуратно оформленную, но неверную картину, и первое действие инженера уходит в сторону от настоящей причины.
Какие сигналы агент сопоставляет: метрики, логи, трассировки, изменения и обращения клиентов
Каждый источник даёт свой срез ситуации, и склейка опирается на совпадение этих срезов. Упрощённо картина выглядит так:
| Источник сигнала | Что показывает | Что добавляет к корреляции |
|---|---|---|
| Метрики | Отклонение от нормы по CPU, памяти, задержкам и доле ошибок | Общий знаменатель: несколько алертов растут на одном узле одновременно |
| Логи | Код и текст ошибки | Совпадение ошибок у сервисов, которые выглядят независимыми |
| Трассировки | Путь запроса через сервисы | Видно, на каком участке цепочки обрывается обработка |
| История изменений | Деплои, правки конфигурации, миграции | Связь всплеска с недавним релизом или переключением |
| Обращения клиентов | Внешний симптом: жалобы, рост ошибок в интерфейсе | Подтверждение, что сбой заметен пользователям, а не только мониторингу |
Склейка держится на согласованности по времени. Разные часовые пояса у источников, задержки доставки логов и рассинхронизация часов превращают корреляцию в случайную выборку: агент видит события рядом, но не может доказать, что они связаны. Проверка синхронизации времени и задержек ingestion идёт первой строкой в подготовке к запуску.
Роль карты зависимостей: почему без неё корреляция ломается
Карта зависимостей связывает сетевую ноду, сервисы и приложения: кто на кого опирается, какой трафик куда идёт, что упадёт вслед за узлом. Именно она превращает набор однотипных алертов про недоступность в утверждение «корень здесь, а остальное - следствия».
Когда карты нет или она устарела после переезда сервисов, корреляция скатывается к сортировке по времени. Агент либо объединяет несвязанные сбои в один инцидент, либо разносит один сбой на несколько. Второй вариант опаснее: дежурный видит три инцидента и трижды начинает диагностику с нуля. Конкретный инструмент построения карты не принципиален, принципиально то, что она обновляется вместе с инфраструктурой, а не раз в год перед аудитом.
Архитектура связки: нижний слой AIOps и языковой агент поверх него
Систему удобно представить двумя слоями. Нижний: классический AIOps с корреляцией и поиском аномалий. Верхний: языковой агент, который читает результат нижнего слоя и превращает его в текст, черновики и рекомендации. Слои решают разные задачи, и попытка оставить только верхний заканчивается уверенными формулировками без проверяемой основы.
За что отвечает классический AIOps: корреляция и поиск аномалий
Нижний слой считает. Он группирует алерты, ищет аномалии в метриках относительно базовой линии, сопоставляет события с топологией и картой зависимостей. Результат воспроизводим: одни и те же входные данные дают один и тот же набор инцидентов, и это можно проверить на исторических выгрузках.
Генеративных функций здесь нет и не нужно. Задача слоя - дать устойчивый, объяснимый ответ на вопрос «сколько инцидентов на самом деле и что у них общего». Формулировки в промпте на этот ответ не влияют, и в этом его ценность для дежурства, где решения повторяются сотни раз.
Что добавляет языковой агент: объяснение, черновики и контекст
Верхний слой читает результат корреляции, историю изменений и обращения клиентов, формулирует инцидент человеческим языком и объясняет, почему алерты склеены именно так. Дальше идут черновики: тикет с гипотезой и ссылками на данные, статья в базу знаний, отчёт по инциденту.
Ночная смена в кейсе закончилась так: 23 тикета первой линии разобраны, три статьи в базе знаний обновлены, черновик отчёта по инциденту готов. Языковой агент не заменяет корреляцию, он интерпретирует её результат. Разница принципиальная: LLM умеет собирать связный текст из разрозненных фактов, но не умеет считать базовые линии и не гарантирует одинаковый ответ на одинаковые данные.
Соблазн поставить отдельного агента на каждый шаг понятен, только рой агентов не становится умнее от роста числа участников. Лишние звенья добавляют точки отказа и размывают ответственность за вывод, который в итоге увидит дежурный.
Где агент ошибается: рискованное действие и человек в контуре
Ошибка агента стоит дорого ровно там, где он звучит уверенно. Чем лучше сформулирован черновик действия, тем выше шанс, что инженер нажмёт кнопку, не перепроверив контекст.
Сценарий с кнопкой перезапуска: почему рекомендация агента может ухудшить ситуацию
На дашборде висит кнопка перезапуска, агент предлагает её нажать. У приложения в этот момент идут активные операции: обработка очереди, выгрузка, длинная транзакция. Перезапуск прерывает их, и вместо восстановления сервиса команда получает второй инцидент, уже с потерянными данными.
Причина в границе знаний. Агент видит метрики, логи и карту зависимостей, но не видит бизнес-контекст незавершённых операций, если этот контекст ему явно не передан. В кейсе граница обозначена без иллюзий: агент предлагает решения, но порой такие, что после них становится хуже, поэтому финальное действие остаётся за инженером. Вывод для тех, кто строит похожую систему: в промпт и в правила агента нужно класть не только «что сломано», но и «что сейчас нельзя прерывать».
Правило человека в контуре: какие действия требуют подтверждения
Практическое правило формулируется коротко: агент готовит рекомендацию и черновик действия, инженер подтверждает или отклоняет. Классы действий, которые не выполняются без подтверждения:
- перезапуски и остановки сервисов, особенно с активными операциями;
- изменения конфигурации, лимитов и фича-флагов;
- откаты деплоя и миграций базы данных;
- массовые операции по парку узлов и прав доступа.
Это разделение ответственности, а не недоверие к модели. Похожая логика зафиксирована в открытой методологии Agent-Ops 0.4.0: ИИ предлагает, человек утверждает, программа исполняет, где рекомендация агента не считается разрешением на изменение инфраструктуры.
Техническая часть важна не меньше процессной. Агент с правами только на чтение всё равно изменил данные, когда запись выполнил downstream-узел, поэтому граница исполнения должна быть детерминированной и находиться вне модели. Если агент физически не может вызвать перезапуск, вопрос «доверяем или нет» перестаёт быть вопросом настроения.
Ограничения подхода: данные, карта зависимостей и окно истории
Качество склейки упирается в три вещи, и каждая ломается тихо, без красных лампочек на дашборде.
- Качество данных. Пропуски в метриках, шумные логи, обрезанные трассировки и рассинхронизация времени дают корреляции ложные связи. Агент уверенно объединяет то, что рядом по времени, и ошибается в причине.
- Карта зависимостей. Устаревшая топология после переезда сервисов или смены балансировщика превращает корреляцию в угадывание. Обновление карты стоит держать в том же процессе, что и деплой.
- Окно истории инцидентов. Редкие сценарии не попадают в доступный период, и агент не узнаёт их при повторе. Чем короче окно, тем чаще система видит «новое» там, где на самом деле был разбор год назад.
Постепенная деградация: как агент привыкает к плохому и что с этим делать
Модель нормы, которая обновляется по текущим данным, со временем впитывает ухудшение. Память течёт месяцами, задержка растёт на проценты в неделю, и через несколько циклов такое поведение становится базовой линией. Агент молчит, потому что формально всё в пределах нормы.
Лечится это не настройкой одного порога, а процедурой: сравнение текущего поведения с историческими базовыми значениями за длинный период, периодический пересмотр модели нормы и отдельная проверка на дрейф. Полезно держать статический набор контрольных запросов и метрик, по которым видно, что система стала работать хуже, даже если аномалий не найдено.
Отдельная зона внимания - наблюдаемость самого AI-слоя. Внешний аудит AI-агентов чаще смотрит на модель, а не на то, как она запущена, поэтому логи, права, изоляция и таймауты остаются базовой гигиеной дежурной системы.
Что агент делает за смену: тикеты, база знаний и отчёты
За ночную смену в кейсе агент разобрал 23 тикета первой линии, обновил три статьи в базе знаний и подготовил черновик отчёта по инциденту. Это ровно та работа, которая съедает время дежурного между настоящими разборами: типовые обращения, поиск актуальной инструкции, сбор хронологии для отчёта.
Эффект для MTTR складывается из подготовки. Инженер приходит к инциденту с готовой хронологией, списком затронутых сервисов и ссылками на недавние изменения, а не тратит первые минуты на сбор контекста из пяти систем. Шум алертов падает по той же причине: 340 уведомлений превращаются в один инцидент, и внимание дежурного не распыляется. Точных процентов снижения кейс не даёт, и подставлять их из головы не стоит.
Проверка фактов остаётся за человеком. Черновик статьи в базе знаний, опубликованный без вычитки, быстро превращает хранилище инструкций в набор правдоподобных текстов. Подход к базе знаний как к управляемому активу, а не как к свалке черновиков, описан в руководстве по системе управления знаниями для команд с AI-агентами.
Когда AIOps-платформа для мониторинга окупается
Окупаемость считается не по красоте дашборда, а по объёму рутины и цене простоя. Признаки, при которых вложение имеет смысл:
- много алертов и заметный поток тикетов первой линии, который не успевают закрывать дежурные;
- зрелый мониторинг: метрики, логи и трассировки собираются, время синхронизировано;
- есть карта зависимостей, пусть неидеальная, но обновляемая;
- накоплена история инцидентов с разборами, а не только список закрытых тикетов;
- простой стоит дорого: выручка, SLA или репутация зависят от скорости восстановления;
- дежурные перегружены ночными сменами, и цена ошибки на усталости уже известна.
При малом объёме алертов и слабых данных выгода сомнительна: агент будет склеивать вслепую, а инженер - перепроверять каждый вывод. Экономика здесь зависит от исходных условий, и универсальной цифры окупаемости не существует.
Минимальный набор данных и процессов до внедрения
Подготовка занимает больше времени, чем подключение модели, и именно она определяет, будет агент помогать или мешать.
- Телеметрия: метрики с понятными базовыми линиями, логи с единым форматом, трассировки с идентификаторами запросов и синхронизация времени.
- Карта зависимостей: сервисы, узлы, связи и владельцы, с регламентом обновления при каждом значимом изменении.
- История инцидентов: разборы с причиной и действиями, а не только заголовки закрытых тикетов.
- Runbook-и: пошаговые инструкции для типовых сбоев, пригодные для цитирования агентом.
- Регламент подтверждения: список действий, которые выполняются только после явного согласия инженера.
- Процесс дежурства и первая линия: кто принимает решение, кому уходит черновик, кто отвечает за публикацию в базе знаний.
- Проверка самого агента: логи его действий, права, изоляция и таймауты до первого рабочего включения.
Без карты зависимостей и истории инцидентов агент склеивает алерты вслепую, а без регламента подтверждения первая же уверенная рекомендация может стать причиной второго инцидента. Последнее слово за инженером - это условие безопасного запуска, а не временная мера на период обкатки.