Автономный ИИ-агент СберТеха обработал 347 тикетов по обслуживанию баз данных за пять дней
Команда «R4C.Support» в экосистеме Сбера продемонстрировала эффективность автономного ИИ-агента для управления рутинными задачами администрирования баз данных PostgreSQL. Тестовый запуск на парк из 800+ тестовых серверов позволил обрабатывать заявки в 12 раз быстрее ручного метода, при этом безопасность обеспечивается многоступенчатой валидацией планов действий модели LLM.
# Автономный ИИ-агент для VACUUM/ANALYZE: реальный опыт эксплуатации
Команда разработчиков Сбера представила результаты исследования по созданию полностью автономного агента, способного самостоятельно решать типовые задачи администрирования баз данных. В фокусе внимания — обслуживание парка PostgreSQL: очистка дискового пространства, выполнение команд вакуумизации и анализ статистики.
Проект был запущен 15 мая в тестовой среде, состоящей из более чем 800 экземпляров СУБД. Результаты за первые пять дней работы опровергли опасения, что алгоритмы не справятся со сложностью распределенных систем. Среднее время реагирования на заявку снизилось с 30 минут до 2,5 минут.
Архитектура и режимы работы системы
Разработанная система функционирует в двух независимых режимах, использующих единую кодовую базу, но имеющих разные цели. Первый режим — интерактивный, где пользователь взаимодействует с агентом через веб-интерфейс (Streamlit), а граф LangGraph orchestrates (управляет) 32 доступными инструментами. Второй режим — автономный, работающий по расписанию через cron-задачи.
Автономный режим запускается раз в пять минут, сканирует системный трекер задач (TaskTracker) на наличие новых тикетов с меткой обслуживания (например, MONITORING_VACUUM_ANALYZE) и передает их обработке.
Роль больших языковых моделей (LLM)
В проекте используется модель GigaChat (или аналогичные решения), которая выступает в роли «мозга» агента. LLM выполняет четыре ключевые функции:
1. Парсинг входящих данных: Извлечение структурированных параметров (хост, точка монтирования, база данных) из текстового описания тикета. 2. Генерация плана: Составление последовательности SQL-команд и действий на основе полученных метрик из Prometheus. 3. Анализ логов: Выявление критических событий, таких как FATAL, PANIC или ситуации блокировок (deadlock), в журналах ошибок. 4. Формирование отчетов: Агрегация данных для человеко-читаемых выводов и рекомендаций.
Важно понимать, что ИИ в данном контексте не является слепым исполнителем. Модель генерирует *план*, но не выполняет команды напрямую. Реализация требует строгого разделения на фазы: анализ, планирование, валидация и выполнение.
Алгоритм обработки заявки: от сканера до выполнения
Процесс работы автономного агента на примере тикета по обслуживанию таблиц выглядит следующим образом:
1. Сканирование и инициализация: Скрипт scanner.py запускается по расписанию, ищет открытые тикеты и назначает обработчик StatisticsHandler. 2. Валидация безопасности (Safety Check): Перед любым действием агент проверяет доступность сервера и уровень текущей нагрузки на базу данных. Если нагрузка критическая, обработка ставится на паузу. 3. Диагностика: Агент собирает метрики мёртвых строк и времени последнего анализа (last_analyze). В тестовом примере агент обнаружил, что у таблицы orders.status_updates накопилось более 150 тысяч мёртвых строк, а автоматическое обслуживание было отключено. 4. Планирование с участием LLM: На основе собранных данных модель формирует план действий. В примере план включал выполнение VACUUM и ANALYZE для семи проблемных таблиц, а также рекомендацию включить автовакуум для конкретной таблицы. 5. Валидация и Dry-Run: Сгенерированный план проходит проверку на соответствие белому списку допустимых операций и существования таблиц. По умолчанию режим выполнения установлен в dry-run (сухой запуск), где действия только фиксируются в логах без изменения данных в базе. В продакшене этот переключатель меняет конфигурацией. 6. Исполнение и отчетность: После подтверждения безопасности агент выполняет SQL-команды. Результат фиксируется в тикете, добавляется комментарий с деталями, а заявка закрывается.
Всего за первые пять дней было обработано 347 тикетов, из которых 89% (309 заявок) пришлось на выполнение задач по вакуумизации и анализу.
Мониторинг и прозрачность действий
Для контроля за работой автономной системы разработана «лента событий» (Event Stream). Это внутренний журнал, куда агенты записывают каждое значимое действие в формате JSONL.
Инженеры могут через веб-интерфейс: * Фильтровать события по уровню важности (INFO, WARNING, ERROR). * Искать по номеру тикета или имени обработчика. * Следить за ходом выполнения в реальном времени.
Пример записи в журнале события: ``json { "timestamp": "2025-04-15T10:23:45", "event_type": "progress", "ticket": "R4CDBA-12345", "handler": "StatisticsHandler", "step": "llm_plan", "message": "LLM план: vacuum orders.status_updates, analyze", "level": "INFO" } ``n Такая детализация позволяет мгновенно выявлять аномалии в поведении агента или сбои в работе LLM, не дожидаясь анализа логов вручную.
Результаты и перспективы
Эксперимент показал высокую адаптивность системы. Даже на тестовых стендах, где конфигурации часто меняются, агент успешно справился с пиковой нагрузкой более чем в 1000 тикетов в сутки, включенной в последующие недели тестирования.
Основные причины отказов агента в первые дни (примерно 3% случаев) свелись к техническим ограничениям доступа (ошибки SSH-ключей) или неполноте данных в описании тикета (например, отсутствие информации о точке монтирования диска). После настройки правил доступа и уточнения шаблонов заявок эффективность выросла.
Команда считает концепцию автономного обслуживания рабочей, особенно для сред, где база данных динамически создаются и уничтожаются, как в случае с тестовыми окружениями. В идеале, такой агент станет частью второй линии поддержки, освобождая специалистов для решения более сложных инцидентов. Полный анализ статистики за месяц работы и графики потребления токенов модели планируется опубликовать в отдельном отчете.