ИИ в DevOps у Финуслуг: ночные агенты нашли сбои, задевшие около 1600 регистраций

Речь о сбоях, которые не похожи на аварию. Графики зелёные, алерты (автоматические оповещения) молчат, а на одном шаге пользовательского пути растёт доля неудачных операций или время ответа. Раньше команда каждую неделю вручную шла по цепочке Grafana, логи в OpenSearch, поиск бизнес-операции и связанного кода. Ниже по шагам описано, как эту цепочку переложили на агентов. Схема подойдёт любой команде, которая думает про ИИ в DevOps (связке разработки и эксплуатации сервисов).

Что понадобится для ночного контура?

• Multica, где задачи создаются по расписанию. В терминах Multica эта функция называется Autopilot.
• OpenCode: он подхватывает задачу и запускает агентов.
• Confluence с каталогом бизнес-операций и правилами контроля для каждой из них.
• Источники данных: Prometheus (метрики), OpenSearch (логи), Sentry (ошибки и скорость фронтенда, то есть видимой пользователю части сервиса).
• MCP, протокол, через который ИИ-агент подключается к внешним системам вроде Confluence.
• Jira для черновиков задач и доступ агента к репозиториям с кодом.

Какую языковую модель использует команда, в материале не сказано.

Пошаговая инструкция: от сигнала до черновика задачи

1. Опишите в Confluence каталог бизнес-операций и правила контроля для каждой. Для каждой операции задайте SLA (договорённый порог качества) и baseline (обычный уровень показателя). Без этих двух опор агенту не с чем сравнивать.
2. Настройте расписание. Autopilot ночью создаёт задачу, OpenCode её подхватывает, и управление получает lead-agent, то есть агент-координатор.
3. Координатор через MCP читает каталог и делит анализ на независимые дочерние задачи. В базовом сценарии для Prometheus у команды 21 бизнес-операция, их распределяют между семью дочерними агентами, по три на каждого.
4. Дочерние агенты (probe или collector) отвечают на один узкий вопрос: есть ли отклонение и насколько оно существенно. Причину они не угадывают. Каждый работает только с одним источником данных:
5. Prometheus: failrate (доля неуспешных операций), ошибки и latency (время ответа);
6. OpenSearch: сводка по кодам ответа сервера, сообщения об ошибках, примеры trace (следа запроса через сервисы);
7. Sentry: ошибки фронтенда и время загрузки страниц.
8. Каждая операция получает статус OK, WARNING или BREACH, а агент возвращает короткую карточку. Ниже шаблон по полям, которые перечисляет команда:

Бизнес-операция: <название>
Фактическое значение: <метрика>
SLA: <порог>
Baseline: <обычный уровень>
Статус: OK / WARNING / BREACH
Подтверждающие данные: <логи, trace, графики>

1. Карточки со статусами WARNING и BREACH уходят агенту-аналитику (analyst-agent). Он открывает связанный репозиторий и формирует гипотезу причины. Если проблема в коде соседней команды, агент переходит туда, когда у него есть доступ. Связь он находит по техническим зависимостям, например по вызовам Feign (механизма обращений между сервисами).
2. Когда отклонение подтверждено, Multica собирает черновик Jira-задачи: операция, фактические метрики, нарушение SLA, технический контекст, причина и предложение по исправлению. Инженер проверяет выводы и только потом переносит задачу в backlog, общую очередь задач команды.

Обратите внимание на порядок подключения источников. Команда начала с метрик, затем добавила логи и только потом фронтенд. Каждый источник отвечает на свой вопрос: где отклонение, что произошло, что видит пользователь.

Почему нельзя просто отдать модели все логи?

Первое желание: написать промпт вроде «Посмотри все сервисы, метрики, логи и код, найди что-нибудь подозрительное и напиши отчет». Команда пишет, что такой сценарий упирается во время выполнения, размер контекста и качество ответа. Чем разнороднее данные, тем труднее понять, на каких фактах построена гипотеза.

Поэтому мониторинг и правила SLA сначала сужают поиск, а подзадача служит одновременно единицей параллельной работы и границей контекста. Команда называет такие плюсы:

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

Что делать с этим прямо сейчас, по ролям?

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

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

Предпринимателю в РФ и СНГ. Финтех-стек из материала типичен для российских команд, а языковую модель можно выбрать под свои требования. Из доступных в РФ вариантов есть YandexGPT и GigaChat.