Que hace
AI-агент чергує разом із черговим інженером: читає алерти зі Slack і стеку спостережуваності, збирає діагностичний контекст і готує пул-реквест з виправленням. Він не замінює чергового, а першим реагує на інцидент — щоб до моменту ескалації був зібраний контекст і у відомих випадках вже запропоноване виправлення.
У продуктивному режимі це знімає з команди 675 годин на місяць і закриває 28 PR без участі людини.
Що робить агент
- Слухає канал чергових і вебхуки моніторингу — ловить новий алерт за секунди, а не після того як інженер відкриє сповіщення.
- Витягує стек-трейс, метрики, посилання на пов'язані дашборди і останні деплої, щоб зібрати повну картину.
- Шукає схожі інциденти в історії Slack-тредів і сценаріях реагування — витягує знання, які зазвичай залишаються в головах досвідчених інженерів.
- Формулює гіпотезу про причину інциденту і публікує її в тред першим повідомленням із зазначенням рівня впевненості.
- Якщо інцидент відповідає відомому паттерну — відкриває пул-реквест з виправленням і призначає рев'юерів.
- Прикріплює до PR докази: логи, трейс, посилання на схожі випадки, diff з попередніми фіксами.
- Залишається в треді й відповідає на уточнення чергового, поки інцидент не закрито — одне джерело правди замість ручного копіювання контексту.
- Після резолюції пише коротку чернетку розбору інциденту і фіксує новий паттерн для майбутніх інцидентів — база знань поповнюється автоматично.
Черговий перемикає контекст рідше: замість ланцюжка «алерт → метрики → код → Slack → репозиторій» він читає готове зведення і приймає рішення. За даними референсного впровадження, 66% пропозицій агента отримують позитивний відгук, вартість однієї взаємодії — $0,30.
Чого агент НЕ робить
- Не мержить пул-реквест без підтвердження людини — всі зміни проходять стандартне рев'ю коду і CI.
- Не гасить інциденти, для яких немає задокументованого сценарію реагування або схожого попереднього випадку — ескалює черговому з вже зібраним контекстом.
- Не приймає архітектурних рішень, не рефакторить компоненти і не чіпає код поза дозволеними сервісами — лише точкові фікси за відомими паттернами.
Como funciona
Агент побудований на патерні багатокрокової оркестрації: LLM керує циклом «спостереження → гіпотеза → дія → перевірка» до тих пір, поки не знайде рішення або не прийме рішення ескалювати. Ядро — мовна модель з використанням інструментів через агентний фреймворк.
Архітектура
Агент працює в трьох інтеграційних шарах, кожен зі своїми викликами інструментів:
Шар | Що дає агенту | Приклади операцій |
|---|---|---|
Спостережуваність / моніторинг | Сигнал та метрики | Читання алертів, отримання метрик за instance/service, вивантаження стек-трейсів |
Репозиторій коду | Код та історія змін | Пошук файлу за помилкою, перегляд останніх комітів, створення гілки та PR |
Комунікації | Контекст команди | Читання Slack-тредів за інцидентом, запис відповіді, згадка чергового |
Потік обробки інциденту
- Подія-тригер. Алерт з системи спостережуваності потрапляє до Slack-каналу чергових. Вебхук передає подію агенту з даними: рівень критичності, сервіс, метрика.
- Збір контексту. Агент робить серію викликів інструментів: читає останні рядки логів, графік метрики за 24 години, історію деплоїв за останні 6 годин.
- Пошук патернів. Агент векторним пошуком по історії Slack-інцидентів та сценаріїв реагування знаходить схожі випадки з їхніми резолюціями.
- Гіпотеза. LLM формулює гіпотезу виду «підвищена затримка на сервісі X спричинена релізом Y — відкат або хотфікс Z» з оцінкою впевненості.
- Діагностичне повідомлення. Агент публікує перше повідомлення в тред: зведення, гіпотеза, посилання на докази. Черговий бачить зведення, а не сирі логи.
- Шлях усунення. Якщо патерн відомий і рівень впевненості високий — агент створює гілку, застосовує виправлення за шаблоном, відкриває PR з описом і призначає рев'юерів. Якщо ні — зупиняється і просить чергового підтвердити напрямок.
- Людина в процесі. Черговий читає PR, приймає або запитує зміни. Агент реагує на коментарі: додає логи, виправляє помилку, пояснює вибір.
- Чернетка розбору інциденту. Після інциденту агент збирає хронологію подій — що сталося, що зроблено, скільки часу — і кладе чернетку в канал для редагування.
Як розгортається на проекті
- Підключення системи спостережуваності: вебхук з Datadog, Grafana, New Relic, Sentry або Prometheus Alertmanager на сервіс агента.
- Інтеграція з репозиторієм: GitHub App або GitLab токен доступу з правами створення гілки, відкриття PR, читання історії комітів.
- Встановлення Slack-бота в канал чергових: читання подій, запис відповідей, гілкування повідомлень.
- Імпорт історичних інцидентів: парсинг Slack-тредів та наявних сценаріїв реагування у векторний індекс — ядро знань агента.
- Визначення патернів автовиправлення: список типів інцидентів, де агенту дозволено відкривати PR (відкат деплою, зміна функціонального прапорця, підвищення лімітів).
- Запобіжники: список сервісів та репозиторіїв, де агент лише читає, і окремий список, де може писати.
- Пілот: тиждень у режимі «агент пише лише діагностику, без PR». Команда оцінює якість гіпотез.
- Розширення: після стабільного позитивного відгуку вмикаються патерни автовиправлення по одному.
Де криється цінність
Агент перетворює три пари рук на одного першого респондера, який завжди онлайн. За даними референсного впровадження, 28 PR на місяць мерджаться без участі людини — це низькоризикові фікси, які раніше займали час старших інженерів і витягували їх із поточних завдань.
Requisitos previos
Для запуску чергового AI-агента команді потрібні три групи готовності: доступи, історичні дані та операційний процес. Без них пілот іде у відлагодження інтеграцій замість реальної роботи з інцидентами.
Доступи та інтеграції
- Стек спостережуваності з вебхуками: Datadog, Grafana, New Relic, Sentry або Prometheus Alertmanager.
- Git-репозиторій з налаштованим CI та рев'ю коду (GitHub, GitLab, Bitbucket).
- Slack або аналог з каналом чергових та правом встановлення бота.
- Технічне узгодження: лише для читання для більшості репозиторіїв, запис (створення гілки + відкриття PR) для списку дозволених.
Історичні дані
- Slack-треди щодо інцидентів за останні 6–12 місяців — чим більше, тим точніше працює паттерн-матчинг.
- Сценарії реагування у будь-якому форматі (Confluence, Notion, markdown у репозиторії).
- Список відомих патернів автовиправлення: які типи інцидентів команда готова довірити агенту (відкат, перемикання функціонального прапорця, підвищення лімітів).
Готовність команди
- Ротацію чергових вже налагоджено: є черговий та процес ескалації.
- Рев'ю коду обов'язкове для всіх PR — агент не мержить сам.
- Виділений власник: старший SRE або техлід, який валідує паттерни та розбирає хибні спрацювання у перші тижні.
Терміни впровадження
Комплексність — середня. Повний запуск від контракту до продакшну — 6–10 тижнів:
- Тижні 1–2: інтеграції, доступи, індексація історії інцидентів.
- Тижні 3–5: пілот у діагностичному режимі, налаштування паттернів.
- Тижні 6–8: увімкнення автоматичного усунення за одним паттерном, калібрування.
- Тижні 9–10: передача команді та регламент власника.
Problemas
- Conocimiento en cabezas, no en documentos
- Cambio constante de contexto
- Respuesta lenta a clientes
FAQ
Скільки часу займає впровадження?
Повний запуск — 6–10 тижнів. Перші 2 тижні йдуть на інтеграції зі спостережуваністю, репозиторієм і Slack. Наступні 3–4 тижні — пілот у режимі «тільки діагностика», де команда калібрує якість гіпотез. Останні 2–4 тижні — увімкнення автовиправлення за одним патерном і передача власнику. Діагностичну частину можна запустити швидше, якщо інциденти добре задокументовані в Slack-тредах.
У нас немає актуальних runbook'ів — чи спрацює агент?
Частково. Агент компенсує відсутність runbook'ів історією Slack-тредів: якщо команда обговорює інциденти в каналах, цих даних достатньо для патерн-матчингу. У перші тижні агент частіше ескалює замість автовиправлення, зате поповнює базу знань. Через 1–2 місяці роботи з'являється структурований індекс інцидентів — листування перетворюється на runbook-аналог автоматично.
Які ризики і що може піти не так?
Головний ризик — хибні гіпотези, які ведуть чергового в неправильному напрямку. Тому агент показує рівень впевненості і докази, а автовиправлення вмикається лише для патернів з історією успіху. Другий ризик — PR з некоректним fix'ом, але code review і CI зупиняють такі зміни. Агент не мержить сам і не торкається коду поза дозволеними сервісами.
Чи підходить автоматизація для нашої галузі?
Основний профіль — SaaS і Tech, де є стек спостережуваності і on-call ротація. Підходить також для e-commerce, fintech, gaming — скрізь, де продакшн потребує чергування. Не підходить командам без моніторингу або без процесу code review. Галузева специфіка зашивається в патерни автовиправлення: для fintech важливі перевірки відповідності вимогам, для gaming — швидкість відкату.
Чи замінить агент чергового інженера?
Ні. Агент — перший респондер, а не заміна. Він збирає контекст, пропонує гіпотезу і в простих випадках відкриває PR, але рішення залишаються за людиною. Референсне впровадження показує 66% позитивних відгуків і 28 PR на місяць без втручання людини — це низькоризиковані фікси, які раніше забирали час старших інженерів. Складні інциденти агент ескалює із вже зібраним контекстом.
Чи можна запустити лише діагностичну частину без автовиправлення?
Так, це типовий старт. У діагностичному режимі агент пише зведення, гіпотезу і посилання на докази, але не відкриває PR. Так знімається основний біль — контекст-світчинг і пошук схожих інцидентів — без ризику втручання в код. Автовиправлення вмикається окремим етапом, після 1–2 місяців пілоту, коли команда бачить стабільну якість гіпотез.
На якій моделі працює агент?
Ядро — LLM з tool use через agent framework. Модель керує циклом «спостереження → гіпотеза → дія» і робить виклики до системи спостережуваності, репозиторію і Slack. Вибір обумовлений якістю code-reasoning і стійкістю довгих контекстів — стек-трейс, логи і diff вкладаються в одне вікно. Grow2.ai відповідає за промпт-інжиніринг, патерни інструментів і моніторинг поведінки агента.
Quieres esto en tu negocio?
Reserva una auditoria gratuita — te mostraremos como funcionara esta automatizacion para ti.