Финуслуги запустили ночных AI-агентов: они нашли потери в 1600 регистрациях без алертов

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

Команда регистрации Финуслуг каждую неделю вручную проходила один и тот же маршрут: Grafana, потом логи в OpenSearch, потом поиск проблемной бизнес-операции и связанного кода. На это уходило от четырёх до восьми часов в неделю, и это до того, как инженер вообще начинал думать, что чинить. Автоматизировать решили именно эту часть: не принятие решений, а сбор фактов и подготовку гипотезы.

Как устроен ночной контур

По расписанию (в Multica это Autopilot) создаётся задача, которую подхватывает OpenCode. Дальше работает lead-agent: через MCP он читает в Confluence каталог бизнес-операций и правила контроля для каждой. В базовом сценарии для Prometheus таких операций 21. Lead-agent раздаёт их семи дочерним агентам по три штуки, и те проверяют свои участки параллельно.

Диагностика намеренно разбита на два этапа. На первом агент-сборщик работает в одном контуре наблюдаемости и отвечает на узкий вопрос: есть ли отклонение и насколько оно серьёзное. Он сравнивает факты с SLA и baseline и присваивает статус OK, WARNING или BREACH. На выходе короткая карточка: операция, фактическое значение, SLA, baseline и подтверждающие данные. Только WARNING и BREACH попадают к analyst-agent'у. Он открывает связанный репозиторий и формулирует гипотезу причины.

Если отклонение подтвердилось, Multica собирает черновик Jira-задачи. В нём бизнес-операция, значения метрик, нарушение SLA, технический контекст, причина и предложение по исправлению. Ключевое слово здесь «черновик»: в backlog задачу переводит инженер, проверив выводы.

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

Соблазн понятен: «посмотри все сервисы, метрики, логи и код и найди что-нибудь подозрительное». На практике такой запрос упирается во время выполнения, размер контекста и качество ответа. Чем разнороднее данные, тем труднее понять, на чём держится гипотеза.

Поэтому SLA и observability сначала сужают поиск, а подзадача становится одновременно единицей параллелизма и границей контекста. Получается несколько практических плюсов: детерминированные расчёты не смешиваются с рассуждениями LLM, упавшую часть можно перезапустить отдельно, а качество проверяется на уровне конкретной роли и артефакта.

Три источника, три слоя проблем

Систему наращивали последовательно, и каждый источник отвечал на свой вопрос.

• Prometheus показывает, где что-то изменилось: failrate, latency и соблюдение SLA по операциям. Первая версия на метриках и коде нашла проблемы примерно в 1000 регистраций.
• OpenSearch объясняет, что именно произошло: HTTP-коды, сообщения об ошибках, stack traces. Это добавило ещё около 600 регистраций. Если причина в чужом сервисе, агент может зайти в репозиторий смежной команды при наличии доступа, связь определяется по вызовам Feign.
• Sentry принёс новый класс сигналов: frontend-ошибки и скорость загрузки страниц. Страница без ошибок, но грузящаяся минуту, для пользователя не работает, а backend failrate этого не покажет.

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

Ограничения и что делать на практике

Failrate нельзя считать одной формулой. 500-е и 401/403/422 имеют разную семантику, у ожидаемых ошибок вроде истёкшей сессии свой допустимый уровень, а у отдельных операций есть собственные исключения. Агент полезен ровно настолько, насколько точно команда описала операции, SLA, baseline и смысл сигналов. ИИ не заменяет модель наблюдаемости, а опирается на неё.

Диагностический контур сам становится production-системой, поэтому за ним тоже нужен мониторинг: стабильность запусков, доля ложных срабатываний, полезность отчётов. Разбирайте и путь, которым агент пришёл к выводу. Ложное срабатывание значит, что надо уточнить SLA или формулу. Не хватило данных: доработайте observability или skill сбора контекста. Выбрал не тот репозиторий: улучшайте skill исследования зависимостей. Отчёт шумный: ужесточайте контракт.

Если хотите повторить подход, начните не с агента. Сначала формализуйте, что считается проблемой и с чем сравнивать сигналы, иначе LLM просто воспроизведёт вашу неопределённость. Финальный отчёт зафиксируйте как контракт: операция, severity, факты, влияние, код, гипотеза, уровень уверенности, следующее действие.

Команда планирует сокращать путь от гипотезы до исправления: типовые фиксы и MR вместо черновика Jira. Но чем ближе агент к изменению production, тем важнее проверка человеком, контроль доступа и воспроизводимость. Пока выигрывает не автономный «AI-инженер», а узкие роли, чёткие границы и человек в точке принятия решения.