Как система мониторинга и автоматических исправлений сократила время реакции на инциденты в ZeBrains

ИИ-агенты проверки кода помогают находить несоответствия ещё до того, как изменения попадут в релиз. Но полностью исключить проблемы в работающем продукте невозможно: часть ошибок проявляется только под реальной нагрузкой при взаимодействии нескольких сервисов или после изменения внешних систем.

Раньше за состоянием наших систем следил классический набор инструментов мониторинга и логирования. Prometheus и Grafana показывали отклонения в метриках, ELK собирал логи, Alertmanager отправлял уведомления дежурной команде.

Но после срабатывания алерта начиналась полностью ручная работа.

Инженеру нужно было определить затронутый сервис, собрать связанные логи и метрики, найти трассировку запроса, проверить последние деплои и изменения в GitLab, сопоставить их с ошибкой и только после этого сформулировать гипотезу о причине инцидента.

Особенно дорого это обходилось ночью и во время релизов, когда скорость принятия решения напрямую влияла на доступность продукта. Мы решили перенести agentic dev подход из процесса разработки в эксплуатацию и создать агента, который становится первым участником разбора production-инцидента.

Перед командой стояло несколько связанных проблем:

• Инциденты требовали большого объёма ручной диагностики. После получения алерта инженер самостоятельно собирал информацию из нескольких систем: логов, метрик, GitLab и истории деплоев.
• Значительная часть времени уходила не на исправление проблемы, а на восстановление контекста: что изменилось, какой сервис затронут, когда началась ошибка и какие изменения потенциально могли на неё повлиять.
• Одни и те же классы проблем могли повторяться в разных сервисах, но каждый новый инцидент снова требовал ручного анализа.
• Ночные и внеурочные вызовы создавали дополнительную нагрузку на разработчиков и DevOps-инженеров.
• Полностью автоматическое внесение изменений непосредственно в production создавало слишком высокий риск: ошибка агента при диагностике могла привести к более серьёзному инциденту.

Задача звучала так: максимально автоматизировать диагностику и подготовку исправления, сократить MTTR и нагрузку на дежурную команду, но сохранить контроль человека над изменениями.

Мы внедрили систему автоматического разбора инцидентов, которая подключается сразу после срабатывания мониторинга и выполняет первый цикл диагностики вместо инженера.

Система получает событие из Alertmanager и автоматически собирает связанный контекст:

• метрики сервиса до и после возникновения проблемы;
• связанные ошибки и фрагменты логов;
• информацию о сервисе и его зависимостях;
• последние деплои;
• последние merge request и изменения кода;
• постановки задач из Jira, связанные с этими изменениями;
• документацию по архитектуре и правила эксплуатации сервиса.

На основании этого контекста агент формирует несколько гипотез о причине инцидента и проверяет их на доступных данных.

Например, если после нового релиза резко выросло количество HTTP 500, агент может определить, какой сервис начал генерировать ошибки, найти соответствующую трассировку стека, сопоставить его с изменённым участком кода и связать начало деградации с конкретным релиз.

Дежурный инженер получает карточку инцидента с собранным контекстом:

Что произошло → когда началось → какие сервисы затронуты → какие изменения этому предшествовали → наиболее вероятная причина → что рекомендуется сделать.

Автоматическая подготовка исправления

Если агент определяет, что проблема потенциально находится в коде и может быть исправлена безопасным изменением, запускается второй сценарий.

Система создаёт отдельную ветку от актуальной версии проекта и передаёт агенту задачу на подготовку исправления.

Агент:

1. анализирует участок кода, связанный с ошибкой;
2. формирует изменение;
3. добавляет или изменяет тест, воспроизводящий найденную проблему;
4. запускает существующие unit- и integration-тесты;
5. запускает статический анализ и линтеры;
6. создаёт merge request в GitLab.

В merge request автоматически добавляется описание:

• какой инцидент обнаружен;
• какие симптомы наблюдались;
• что система считает причиной;
• какие изменения предлагаются;
• какие проверки были выполнены;
• какие тесты подтверждают исправление.

После этого решение принимает человек.

Агент не получает прямого доступа на изменение кода и не может самостоятельно выполнить релиз.

Это принципиальное ограничение системы: автоматизируется поиск причины и подготовка решения, но критическое действие остаётся под контролем инженера.

Как это устроено?

Работа начинается с обычного алерта мониторинга — вручную запускать агента не требуется.

После получения события система определяет проект и сервис, к которому относится проблема, после чего запускает несколько специализированных этапов анализа.

• Первый этап — анализ наблюдаемости.

Агент получает логи, метрики и данные о релизе и определяет временную границу возникновения проблемы и затронутые компоненты.

• Второй этап — анализ изменений.

Система получает отчет последних релизов из GitLab и определяет изменения, которые потенциально связаны с наблюдаемой ошибкой.

• Третий этап — анализ причины.

Агент сопоставляет логи, метрики, архитектурный контекст и изменения кода и формирует гипотезу о первопричине.

• Четвёртый этап — поиск сценария восстановления.
Система определяет наиболее безопасное действие: передать диагностику инженеру, предложить откат к предыдущей версии либо подготовить исправление кода.
• Пятый этап — проверка исправления.

Если подготовлены исправления, они обязательно проходят CI/CD пайплайн и отдельную агентную проверку кода до того, как merge request передаётся человеку.

Таким образом, один агент не проверяет собственное решение сам у себя: генерация исправления и его проверка разделены на независимые этапы.

Безопасность и контроль данных

Мы настроили систему так, чтобы под каждый проект и каждый этап работы можно было выбрать подходящую языковую модель и правила обработки данных. Внешним провайдерам передаются только фрагменты кода и логов, необходимые для диагностики, и только после автоматической очистки от секретов и персональных данных. Если данные нельзя выводить за пределы периметра компании, они обрабатываются на локальной модели. Автоматического переключения на внешний сервис в таком случае не происходит.

Выбор модели под задачу

Модель выбирается по результатам сравнения на реальных исторических инцидентах. Мы оцениваем качество диагностики и исправлений, скорость ответа и стоимость. Это позволяет подобрать оптимальный вариант под требования конкретного проекта и менять его без перестройки всей системы.

Безопасная проверка исправлений

Каждое предложенное исправление проверяется в изолированной временной среде. Даже если агент ошибся, это не повлияет на работающий продукт.

Надёжность самого процесса

Система рассчитана на сбои и нештатные ситуации: разбор инцидента не теряется при перезапуске сервисов, учитывает тайм-ауты и ожидание результатов проверок. Кроме того, предусмотрена защита от дублей: один и тот же инцидент не приведёт к созданию нескольких веток и merge request.

Уровни автоматизации

Мы сознательно не сделали систему полностью автономной.

Для каждого инцидента определяется уровень действий, которые разрешено выполнить автоматически.

• Низкая уверенность — система только собирает контекст и передаёт инженеру несколько возможных причин.
• Средняя уверенность — система определяет наиболее вероятную причину и предлагает способ восстановления.
• Высокая уверенность и типовой сценарий — система дополнительно готовит исправление, тесты и merge request.

Изменения production-среды требуют подтверждения человека.

Такой подход позволил автоматизировать наиболее дорогую часть работы — диагностику и подготовку решения — без передачи агенту неконтролируемого доступа к production.

Что происходит после инцидента

Каждый закрытый инцидент становится новым примером для системы.

Мы сохраняем:

• исходный алерт;
• собранный контекст;
• гипотезу агента;
• фактическую root cause;
• предложенное исправление;
• решение инженера;
• итоговый результат.

Если инженер отклоняет гипотезу или исправление агента, причина отклонения также сохраняется.

Эти данные используются не для автоматического дообучения production-модели, а как база для регрессионного тестирования новых версий системы.

Перед обновлением модели, промптов или логики агентов новая версия повторно проходит исторические инциденты с уже известными причинами. Только после сравнения результатов она может быть переведена в production.

Так мы контролируем, чтобы развитие системы не ухудшало качество диагностики.

После внедрения системы мы изменили сам процесс реакции на инциденты.

• До 5 минут требуется системе, чтобы после срабатывания алерта собрать связанный контекст: логи, метрики, последние деплои и изменения кода — и сформировать первичную гипотезу о причине проблемы.
• Вместо пустого алерта — готовый контекст инцидента. Дежурный инженер получает информацию о затронутом сервисе, времени возникновения проблемы, связанных изменениях и возможной причине.
• Типовые программные ошибки доходят до инженера уже с подготовленным исправлением. Если агент может воспроизвести проблему и предложить безопасное изменение, он создаёт отдельную ветку, добавляет тест и открывает merge request.
• 100% автоматически подготовленных исправлений проходят CI/CD и дополнительную проверку до передачи человеку. Агент не может самостоятельно отправить изменение в production.
• История инцидентов стала частью процесса контроля качества. Реальные production-ошибки используются как регрессионный набор для проверки новых моделей и версий агентов.
• Режим обработки данных выбирается под требования проекта. Система поддерживает внешние модели через API и локальные инстансы для отдельных проектов или этапов. Контекст с запретом на передачу за периметр остаётся в локальной инфраструктуре.

Главный результат — изменилась роль дежурного инженера. Вместо ручного сбора информации из нескольких систем он получает уже подготовленную диагностику, а в типовых случаях — проверенный вариант исправления.

Система не заменяет инженера в принятии критических решений. Она сокращает путь от «у нас что-то сломалось» до «мы понимаем причину и знаем, что нужно изменить».