Что делает
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 отвечает за промпт-инжиниринг, паттерны инструментов и мониторинг поведения агента.
Хотите такую автоматизацию в своём бизнесе?
Запишем на бесплатный аудит — покажем, как это будет работать именно у вас.