Що робить
AI-агент чергує разом з on-call інженером: читає алерти зі Slack і observability-стеку, збирає діагностичний контекст і готує pull request з виправленням. Він не замінює чергового, а першим реагує на інцидент — щоб до моменту ескалації був зібраний контекст і у відомих випадках вже запропонований fix. У продуктивному режимі це знімає з команди 675 годин на місяць і закриває 28 PR без участі людини.
Що робить агент
- Слухає канал чергових і webhook'и моніторингу — ловить новий алерт за секунди, а не після того як інженер відкриє сповіщення.
- Витягує stack trace, метрики, посилання на пов'язані дашборди і останні деплої, щоб зібрати повну картину.
- Шукає схожі інциденти в історії Slack-тредів і runbook'ах — витягує знання, які зазвичай залишаються в головах досвідчених інженерів.
- Формулює гіпотезу про причину інциденту і публікує її в тред першим повідомленням із зазначенням confidence-рівня.
- Якщо інцидент відповідає відомому паттерну — відкриває pull request з виправленням і призначає рев'юерів.
- Прикріплює до PR докази: логи, трейс, посилання на схожі випадки, diff з попередніми фіксами.
- Залишається в треді й відповідає на уточнення чергового, поки інцидент не закрито — одне джерело правди замість ручного копіювання контексту.
- Після резолюції пише коротку postmortem-чернетку і фіксує новий паттерн для майбутніх інцидентів — база знань поповнюється автоматично.
Черговий перемикає контекст рідше: замість ланцюжка «алерт → метрики → код → Slack → репозиторій» він читає готове зведення і приймає рішення. За даними референсного впровадження, 66% пропозицій агента отримують positive feedback, вартість однієї взаємодії — $0,30.
Чого агент НЕ робить
- Не мержить pull request без approve людини — всі зміни проходять стандартний code review і CI.
- Не гасить інциденти, для яких немає задокументованого runbook або схожого попереднього випадку — ескалює черговому з вже зібраним контекстом.
- Не приймає архітектурних рішень, не рефакторить компоненти і не чіпає код поза дозволеними сервісами — лише точкові фікси за відомими паттернами.
Як працює
Агент побудований на патерні багатокрокової оркестрації: LLM керує циклом «спостереження → гіпотеза → дія → перевірка» до тих пір, поки не знайде рішення або не прийме рішення ескалювати. Ядро — мовна модель з tool use через agent framework.
Архітектура
Агент працює в трьох інтеграційних шарах, кожен зі своїми tool calls:
Шар | Що дає агенту | Приклади операцій |
|---|---|---|
Observability / monitoring | Сигнал та метрики | Читання алертів, pull метрик за instance/service, вивантаження stack traces |
Code repository | Код та історія змін | Пошук файлу за помилкою, перегляд останніх комітів, створення branch та PR |
Communications | Контекст команди | Читання Slack-тредів за інцидентом, запис відповіді, згадка чергового |
Потік обробки інциденту
- Triggering event. Алерт з observability-системи потрапляє до Slack-каналу чергових. Webhook передає подію агенту з payload: severity, сервіс, метрика.
- Context gathering. Агент робить серію tool calls: читає останні рядки логів, графік метрики за 24 години, deploy history за останні 6 годин.
- Pattern search. Агент векторним пошуком по історії Slack-інцидентів та runbook'ів знаходить схожі випадки з їхніми резолюціями.
- Hypothesis. LLM формулює гіпотезу виду «підвищена latency на service X спричинена релізом Y — роллбек або hotfix Z» з оцінкою впевненості.
- Diagnosis post. Агент публікує перше повідомлення в тред: summary, гіпотеза, посилання на докази. Черговий бачить зведення, а не сирі логи.
- Remediation path. Якщо патерн відомий і confidence високий — агент створює гілку, застосовує fix за шаблоном, відкриває PR з описом і призначає рев'юерів. Якщо ні — зупиняється і просить чергового підтвердити напрямок.
- Human-in-the-loop. Черговий читає PR, приймає або запитує зміни. Агент реагує на коментарі: додає логи, виправляє fix, пояснює вибір.
- Post-mortem draft. Після інциденту агент збирає timeline — що сталося, що зроблено, скільки часу — і кладе чернетку в канал для редагування.
Як розгортається на проекті
- Підключення observability: webhook з Datadog, Grafana, New Relic, Sentry або Prometheus Alertmanager на сервіс агента.
- Інтеграція з repository: GitHub App або GitLab access token з правами create branch, open PR, read commit history.
- Встановлення Slack-бота в канал чергових: читання подій, запис відповідей, threading.
- Імпорт історичних інцидентів: парсинг Slack-тредів та наявних runbook'ів у векторний індекс — ядро знань агента.
- Визначення патернів auto-remediation: список інцидент-типів, де агенту дозволено відкривати PR (rollback deploy, зміна feature flag, bump лімітів).
- Guardrails: список сервісів та репозиторіїв, де агент лише читає, і окремий список, де може писати.
- Пілот: тиждень у режимі «агент пише лише діагностику, без PR». Команда оцінює якість гіпотез.
- Розширення: після стабільного positive feedback вмикаються auto-remediation патерни по одному.
Де криється цінність
Агент перетворює три пари рук на одного першого респондера, який завжди онлайн. За даними референсного впровадження, 28 PR на місяць мерджаться без участі людини — це низькоризикові фікси, які раніше займали час старших інженерів і витягували їх із поточних завдань.
Що потрібно
Для запуску On-call AI agent команді потрібні три групи готовності: доступи, історичні дані та операційний процес. Без них пілот іде у відлагодження інтеграцій замість реальної роботи з інцидентами.
Доступи та інтеграції
- Observability-стек з webhook'ами: Datadog, Grafana, New Relic, Sentry або Prometheus Alertmanager.
- Git-репозиторій з налаштованим CI та code review (GitHub, GitLab, Bitbucket).
- Slack або аналог з каналом чергових та правом встановлення бота.
- Технічне узгодження: read-only для більшості репозиторіїв, write (create branch + open PR) для списку дозволених.
Історичні дані
- Slack-треди щодо інцидентів за останні 6–12 місяців — чим більше, тим точніше працює паттерн-матчинг.
- Runbook'и у будь-якому форматі (Confluence, Notion, markdown у репозиторії).
- Список відомих auto-remediation паттернів: які типи інцидентів команда готова довірити агенту (rollback, feature-flag toggle, bump лімітів).
Готовність команди
- On-call rotation вже налагоджено: є черговий та процес ескалації.
- Code review обов'язковий для всіх PR — агент не мержить сам.
- Виділений власник: senior SRE або tech lead, який валідує паттерни та розбирає false positives у перші тижні.
Терміни впровадження
Комплексність — середня. Повний запуск від контракту до продакшну — 6–10 тижнів:
- Тижні 1–2: інтеграції, доступи, індексація історії інцидентів.
- Тижні 3–5: пілот у діагностичному режимі, налаштування паттернів.
- Тижні 6–8: увімкнення auto-remediation за одним паттерном, калібрування.
- Тижні 9–10: передача команді та playbook власника.
Болі
- Знання в головах, не в документах
- Постійне перемикання контексту
- Повільний відгук клієнтам
FAQ
Скільки часу займає впровадження?
Повний запуск — 6–10 тижнів. Перші 2 тижні йдуть на інтеграції з observability, репозиторієм і Slack. Наступні 3–4 тижні — пілот у режимі «тільки діагностика», де команда калібрує якість гіпотез. Останні 2–4 тижні — увімкнення auto-remediation за одним патерном і передача власнику. Діагностичну частину можна запустити швидше, якщо інциденти добре задокументовані в Slack-тредах.
У нас немає актуальних runbook'ів — чи спрацює агент?
Частково. Агент компенсує відсутність runbook'ів історією Slack-тредів: якщо команда обговорює інциденти в каналах, цих даних достатньо для патерн-матчингу. У перші тижні агент частіше ескалює замість auto-remediation, зате поповнює базу знань. Через 1–2 місяці роботи з'являється структурований індекс інцидентів — листування перетворюється на runbook-аналог автоматично.
Які ризики і що може піти не так?
Головний ризик — хибні гіпотези, які ведуть чергового в неправильному напрямку. Тому агент показує confidence-рівень і докази, а auto-remediation вмикається лише для патернів з історією успіху. Другий ризик — PR з некоректним fix'ом, але code review і CI зупиняють такі зміни. Агент не мержить сам і не торкається коду поза дозволеними сервісами.
Чи підходить автоматизація для нашої галузі?
Основний профіль — SaaS і Tech, де є observability-стек і on-call rotation. Підходить також для e-commerce, fintech, gaming — скрізь, де production потребує чергування. Не підходить командам без моніторингу або без процесу code review. Галузева специфіка зашивається в патерни auto-remediation: для fintech важливі compliance-перевірки, для gaming — швидкість rollback.
Чи замінить агент чергового інженера?
Ні. Агент — перший респондер, а не заміна. Він збирає контекст, пропонує гіпотезу і в простих випадках відкриває PR, але рішення залишаються за людиною. Референсне впровадження показує 66% positive feedback і 28 PR на місяць без human intervention — це низькоризиковані фікси, які раніше забирали час старших інженерів. Складні інциденти агент ескалює із вже зібраним контекстом.
Чи можна запустити лише діагностичну частину без auto-remediation?
Так, це типовий старт. У діагностичному режимі агент пише зведення, гіпотезу і посилання на докази, але не відкриває PR. Так знімається основний біль — контекст-світчинг і пошук схожих інцидентів — без ризику втручання в код. Auto-remediation вмикається окремим етапом, після 1–2 місяців пілоту, коли команда бачить стабільну якість гіпотез.
На якій моделі працює агент?
Ядро — LLM з tool use через agent framework. Модель керує циклом «спостереження → гіпотеза → дія» і робить виклики до observability, репозиторію і Slack. Вибір обумовлений якістю code-reasoning і стійкістю довгих контекстів — stack trace, логи і diff вкладаються в одне вікно. Grow2.ai відповідає за промпт-інжиніринг, патерни інструментів і моніторинг поведінки агента.
Хочете таку автоматизацію в своєму бізнесі?
Запишемо безкоштовний аудит — покажемо, як це працюватиме саме для вас.