Що робить
Агент скорочує час від спрацювання алерту до першої осмисленої дії — ту саму MTTM (середній час до усунення інциденту), яка визначає, скільки клієнти реально страждають від інциденту.
Працює зв'язкою з моніторингу, оркестрації сценаріїв реагування і комунікацій з черговими, перетворюючи розрізнені сигнали на один керований процес.
Що агент робить покроково
- Отримує сирі сигнали із систем спостережуваності — метрики, логи, трейси, health-check'и, alertmanager — і об'єднує дублі в один інцидент за кореляційними ключами.
- Класифікує інцидент за рівнем критичності (SEV1-SEV4) і доменом (БД, API, мережа, розгортання, зовнішній вендор) на основі історичних паттернів і заздалегідь заданих правил.
- Збирає контекст: останні деплої, зміни функціональних прапорців, схожі інциденти з минулого, список відповідальних за компонент, SLO/SLA по сервісу.
- Маршрутизує алерт у потрібний канал комунікацій — один, а не п'ять. Черговий отримує компактний брифінг у Slack або PagerDuty замість десятка однакових пейджів.
- Підбирає відповідний сценарій реагування з бібліотеки та пропонує його виконання з оцінкою ризиків кожного кроку.
- За командою чергового виконує кроки сценарію реагування з проміжними підтвердженнями — перед кожною мутуючою дією показує, що саме буде зроблено і які наслідки очікуються.
- Документує таймлайн інциденту: хто що зробив, коли, який був ефект. Готує чернетку розбору інциденту з фактами, а не здогадками.
Чого агент не робить
- Не приймає рішень про відкат, failover або drain без явного підтвердження чергового інженера — кожна незворотна дія потребує підтвердження, тому в пілоті зафіксовано нуль помилкових відкатів.
- Не замінює чергову ротацію і не знімає відповідальність із команди — він прискорює інженера, а не скасовує його.
- Не вгадує причини інцидентів, для яких немає даних у бібліотеці сценаріїв реагування або історичних записах. Нові класи падінь ескалюються людям, а прогалини в сценаріях реагування підсвічуються у звіті після інциденту.
Як працює
Під капотом — агент-оркестратор на фреймворку агентів (LLM як шар міркувань), підключений до стеку спостережуваності, системи комунікацій та runbook-бібліотеки. Ключовий принцип — усі дії з побічними ефектами проходять через механізм підтвердження: агент формулює намір, показує його людині, чекає підтвердження.
Потік обробки інциденту
Алерт потрапляє до черги агента через webhook із alertmanager, PagerDuty або DataDog. Агент нормалізує формат, звіряється з відкритими інцидентами (чи нема дубля), збагачує контекстом із API моніторингу та CMDB. Далі LLM-шар класифікує інцидент і обирає сценарій реагування — це окремий виклик зі структурованим виводом із валідацією за JSON-схемою. Оркестратор запускає сценарій реагування як граф кроків: кожен крок або лише для читання (запит метрик, пошук логів), або мутуючий (restart pod, flip feature-flag, відкат розгортання). Мутуючі кроки вимагають підтвердження від чергового.
Кроки впровадження
- Інвентаризація — зібрати список сценаріїв реагування (навіть якщо вони в Confluence, у голові сеньйора або в gist'ах), каталогізувати за компонентами та рівнем критичності.
- Нормалізація сценаріїв реагування — перевести у машиночитаний формат: YAML, Markdown із фронтматером або DSL. Кожен крок позначається як лише для читання або мутуючий, із явною дією відкату.
- Підключення спостережуваності — налаштувати вихідні вебхуки з alertmanager/PagerDuty/DataDog до агента, зіставити мітки алертів із доменною класифікацією.
- Інтеграція комунікацій — Slack-бот для брифінгів та діалогів підтвердження, threading за incident ID, маршрутизація за каналом команди відповідальних.
- Налаштування LLM-конвеєра — класифікатор, селектор сценарію реагування, генератор брифінгу. Кожен виклик — структурований вивід із жорсткою JSON-схемою.
- Пілот на 1-2 сервісах — спочатку в тіньовому режимі (агент пропонує, але не діє), потім із підтвердженням вручну для всіх кроків, потім із автопідтвердженням для кроків лише для читання.
- Розширення на решту команд — у міру стабілізації метрик MTTM та зростання довіри чергових.
Компоненти системи
Компонент | Роль |
|---|---|
Збирач алертів | Нормалізація вебхуків із моніторингу, дедуплікація за кореляційними ключами |
Класифікатор | LLM-класифікація рівня критичності та домену зі структурованим виводом |
Runbook-сховище | Бібліотека сценаріїв реагування у YAML/Markdown із версіонуванням |
Оркестратор | Покрокове виконання сценарію реагування, механіка підтвердження на мутуючих кроках |
Адаптер комунікацій | Брифінги, діалоги підтвердження, threading у Slack |
Журнал аудиту | Хронологія всіх дій агента та людини, вхід у розбір інциденту |
Runbook-сховище — критичний елемент: якщо сценаріїв реагування немає або вони застаріли, агент працює вхолосту. Перші тижні впровадження йдуть саме на дисципліну команди щодо їх написання. Журнал аудиту — другий критичний елемент: без нього механіка підтвердження втрачає сенс, тому що неможливо відновити, хто і що підтвердив.
Агент працює в циклі міркування → дія → підтвердження → спостереження до досягнення або дозволеного стану (метрики повернулися до норми), або ескалації (людина бере управління, агент переходить у роль помічника та документує дії чергового).
Що потрібно
Для впровадження потрібна базова зрілість процесів — без неї агенту ні на що спиратися.
Дані та доступи
- Стек спостережуваності з вебхук-відправкою алертів (Prometheus + alertmanager, DataDog, New Relic, Grafana, PagerDuty — будь-який сучасний).
- Хоча б 5-10 письмових сценаріїв реагування для найчастіших класів інцидентів. Можуть бути в Confluence, Notion або git — головне, щоб існували.
- Доступ до API інфраструктурних систем для мутуючих дій (kubectl, Terraform Cloud, платформа функціональних прапорців, CI/CD).
- Канал комунікацій для інцидентів (Slack або Teams) з правами бота на запис, читання threads, створення каналів.
- Історія минулих інцидентів за 3-6 місяців для калібрування класифікатора.
Готовність команди
- Призначений власник з боку SRE/DevOps, який відповідає за бібліотеку сценаріїв реагування та її актуальність.
- Культура розборів інцидентів без звинувачень — інакше агент, який документує все підряд, викличе спротив.
- Чергові готові до нового робочого процесу з підтвердженнями замість прямих дій у консолі.
- Розуміння, що перші 2-4 тижні агент працюватиме в тіньовому режимі без реальних дій — це не провал, а калібрування класифікатора та селектора сценаріїв реагування.
Таймлайн
Середній проєкт — 6-10 тижнів від старту до продуктивного використання на кількох сервісах. Перші два тижні — інвентаризація та нормалізація сценаріїв реагування, третій-п'ятий — інтеграції зі спостережуваністю та комунікаціями, пілот у тіньовому режимі. Шостий-десятий — розширення обсягу та налаштування автопідтвердження для безпечних кроків лише для читання.
Болі
- Знання в головах, не в документах
- Постійне перемикання контексту
- Повільний відгук клієнтам
FAQ
Скільки часу займає впровадження?
6-10 тижнів для середньої SRE-команди. Перші 2 тижні йдуть на інвентаризацію та нормалізацію runbook'ів, 3-5 тижні — інтеграції зі спостережуваністю і комунікаціями плюс pilot у shadow-режимі. 6-10 тижні — розширення обсягу на додаткові сервіси та поступове включення auto-approve на read-only кроках. Темп значно залежить від того, чи є у команди письмові runbook'и на старті, чи їх доводиться збирати з нуля.
Що робити, якщо у нас немає runbook'ів у письмовому вигляді?
Це найчастіша перешкода для SMB-команд. Перші 2-3 тижні впровадження перетворюються на дисципліноване написання runbook'ів разом із сеньйорами — агент у цей час допомагає витягти процедури з їхніх голів через структуровані інтерв'ю та аналіз історії інцидентів. Без цієї роботи рухатись далі безглуздо: агенту нема на що спиратися, класифікатор працює наосліп, а ROI не матеріалізується.
Які ризики і що може зламатися?
Головний ризик — хибні спрацьовування класифікатора на рідкісних класах інцидентів. Мітигація — receipt-механіка: мутувальні дії вимагають підтвердження чергового, незворотні операції (відкат, drain, failover) завжди вимагають явного підтвердження. У пілоті зафіксовано нуль помилкових відкатів. Другий ризик — деградація runbook-бібліотеки з часом. Owner зі сторони SRE потрібен обов'язково, щоб runbook'и не застарівали та не збивали агента.
Чи підходить рішення для нашої індустрії?
Рішення оптимальне для SaaS/Tech з observability-стеком і on-call ротацією. В універсальних горизонтальних сценаріях — будь-яка компанія з продакшн-сервісами, черговими та алертами — теж працює. Для команд з менше ніж 5 сервісами та рідкісними інцидентами (менше ніж 10 на місяць) ROI матеріалізується слабше, ніж у компаній з регулярним інцидентним навантаженням, де MTTM безпосередньо впливає на SLA і доходи.
Чи можна впровадити без заміни поточного PagerDuty або alertmanager?
Так. Агент підключається поверх існуючого стеку через webhook'и та API — він не замінює моніторинг і оповіщення, а доповнює їх шаром класифікації, збагачення контекстом та оркестрації runbook'ів. PagerDuty продовжує ескалювати по on-call ротації, alertmanager продовжує дедупити на рівні джерел, агент бере на себе тріаж, брифінг черговому та виконання runbook'а за командою.
Що відбувається з інцидентами, які агент не вміє обробляти?
Для таких випадків агент ескалює чергового інженера та переходить у роль помічника: збирає контекст, документує дії людини, шукає схожі інциденти в історії та пропонує кроки за аналогією. Нові класи падінь — це матеріал для розширення runbook-бібліотеки; агент сам підсвічує такі прогалини власнику у звіті після інциденту, і вони стають наступними кандидатами на автоматизацію.
Хочете таку автоматизацію в своєму бізнесі?
Запишемо безкоштовний аудит — покажемо, як це працюватиме саме для вас.