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. Пілот на 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 кроків.