AI incident triage + runbook executor

Агент сокращает время от срабатывания алерта до первого осмысленного действия — ту самую MTTM (Mean Time To Mitigate), которая определяет, сколько клиенты реально страдают от инцидента. Работает связкой из мониторинга, оркестрации runbook'ов и коммуникаций с дежурными, превращая разрозненные сигналы в один управляемый процесс.

Что агент делает пошагово

1. Получает сырые сигналы из систем observability — метрики, логи, трейсы, health-check'и, alertmanager — и объединяет дубли в один инцидент по correlation-ключам.
2. Классифицирует инцидент по severity (SEV1-SEV4) и домену (БД, API, сеть, deploy, внешний вендор) на основе исторических паттернов и заранее заданных правил.
3. Собирает контекст: последние деплои, изменения feature-флагов, похожие инциденты из прошлого, список ответственных за компонент, SLO/SLA по сервису.
4. Маршрутизирует алерт в нужный канал коммуникаций — один, а не пять. Дежурный получает компактный брифинг в Slack или PagerDuty вместо десятка одинаковых пейджей.
5. Подбирает подходящий runbook из библиотеки и предлагает его выполнение с оценкой рисков каждого шага.
6. По команде дежурного выполняет шаги runbook'а с промежуточными receipt-подтверждениями — перед каждым мутирующим действием показывает, что именно будет сделано и какие последствия ожидаются.
7. Документирует таймлайн инцидента: кто что сделал, когда, какой был эффект. Готовит черновик postmortem с фактами, а не догадками.

Чего агент не делает

1. Не принимает решений о rollback, failover или drain без явного подтверждения дежурного инженера — каждое необратимое действие требует receipt, поэтому в пилоте зафиксирован ноль ошибочных откатов.
2. Не заменяет on-call ротацию и не снимает ответственность с команды — он ускоряет инженера, а не отменяет его.
3. Не угадывает причины инцидентов, для которых нет данных в runbook-библиотеке или исторических записях. Новые классы падений эскалируются людям, а пробелы в runbook'ах подсвечиваются в отчёте после инцидента.

Под капотом — агент-оркестратор на фреймворке агентов (LLM как reasoning-слой), подключённый к observability-стеку, системе коммуникаций и runbook-библиотеке. Ключевой принцип — все действия с побочными эффектами проходят через receipt-механизм: агент формулирует намерение, показывает его человеку, ждёт подтверждения.

Поток обработки инцидента

Алерт попадает в очередь агента через webhook из alertmanager, PagerDuty или DataDog. Агент нормализует формат, сверяется с открытыми инцидентами (нет ли дубля), обогащает контекстом из API мониторинга и CMDB. Дальше LLM-слой классифицирует инцидент и выбирает runbook — это отдельный structured-output вызов с валидацией по JSON-схеме. Оркестратор запускает runbook как граф шагов: каждый шаг либо read-only (запрос метрик, поиск логов), либо mutating (restart pod, flip feature-flag, rollback deploy). Mutating-шаги требуют receipt от дежурного.

Шаги внедрения

1. Инвентаризация — собрать список runbook'ов (даже если они в Confluence, в голове у сеньора или в gist'ах), каталогизировать по компонентам и severity.
2. Нормализация runbook'ов — перевести в машиночитаемый формат: YAML, Markdown с фронтматтером или DSL. Каждый шаг помечается как read-only или mutating, с явным rollback-действием.
3. Подключение observability — настроить outgoing webhook'и из alertmanager/PagerDuty/DataDog в агента, сопоставить labels алертов с доменной классификацией.
4. Интеграция communications — Slack-бот для брифингов и receipt-диалогов, threading по incident ID, channel-маршрутизация по команде ответственных.
5. Настройка LLM-пайплайна — классификатор, селектор runbook'а, генератор брифинга. Каждый вызов — structured output с жёсткой JSON-схемой.
6. Pilot на 1-2 сервисах — сначала в режиме shadow (агент предлагает, но не действует), потом с manual approval на всё, потом с auto-approve на read-only шагах.
7. Expand на остальные команды — по мере стабилизации метрик MTTM и роста доверия дежурных.

Компоненты системы

Runbook-store — критический элемент: если runbook'ов нет или они устарели, агент работает вхолостую. Первые недели внедрения уходят именно на дисциплину команды по их написанию. Audit log — второй критический элемент: без него receipt-механика теряет смысл, потому что нельзя восстановить, кто и что подтвердил.

Агент работает в цикле reasoning → action → receipt → observation до достижения либо разрешённого состояния (метрики вернулись в норму), либо escalation'а (человек берёт управление, агент переходит в роль помощника и документирует действия дежурного).

Для внедрения нужна базовая зрелость процессов — без неё агенту не на что опираться.

Данные и доступы

• Observability-стек с webhook-отправкой алертов (Prometheus + alertmanager, DataDog, New Relic, Grafana, PagerDuty — любой современный).
• Хотя бы 5-10 письменных runbook'ов для самых частых классов инцидентов. Могут быть в Confluence, Notion или git — главное, чтобы существовали.
• Доступ к API инфраструктурных систем для mutating-действий (kubectl, Terraform Cloud, feature-flag платформа, CI/CD).
• Канал коммуникаций для инцидентов (Slack или Teams) с правами бота на запись, чтение threads, создание каналов.
• История прошлых инцидентов за 3-6 месяцев для калибровки классификатора.

Готовность команды

• Назначенный owner со стороны SRE/DevOps, который отвечает за runbook-библиотеку и её актуальность.
• Культура postmortem'ов без blame — иначе агент, который документирует всё подряд, вызовет сопротивление.
• Дежурные готовы к новому workflow с receipt-подтверждениями вместо прямых действий в консоли.
• Понимание, что первые 2-4 недели агент будет работать в shadow-режиме без реальных действий — это не провал, а калибровка классификатора и runbook-селектора.

Таймлайн

Средний проект — 6-10 недель от kick-off до продуктивного использования на нескольких сервисах. Первые две недели — инвентаризация и нормализация runbook'ов, третья-пятая — интеграции с observability и communications, pilot в shadow-режиме. Шестая-десятая — расширение scope и настройка auto-approve для безопасных read-only шагов.