Автономный DBA-агент Сбербанка: 10 тысяч тикетов и 99,6% автоматизации второй линии поддержки
Команда исследователей и разработчиков Сбера перевела экспериментальный DBA-агент в режим реального времени, доведя автоматизацию рутинных задач поддержки баз данных до 99,6%. В период с мая по июнь агент самостоятельно обработал более 10 тысяч тикетов, включая очистку дисков, оптимизацию таблиц (VACUUM/ANALYZE) и планирование остановок сервисов, используя гибридную архитектуру из простых скриптов и локальных LLM-вызовов.
# Автономный DBA-агент Сбербанка: 10 тысяч тикетов и 99,6% автоматизации
В экосистеме крупных технологических компаний нагрузка на базы данных часто становится узким местом. Команда Сбера, обслуживающая парк из более чем 800 экземпляров реляционной СУБД Platform V Pangolin DB (на базе PostgreSQL), столкнулась с необходимостью оптимизировать процесс работы DBA. Вместо создания сложных микросервисных архитектур, специалисты выбрали путь agentic coding, разработав монолитного автономного агента, способного самостоятельно реагировать на инциденты.
От тестовых стендов к реальной нагрузке
Разработка агента начиналась с упрощения мониторинга, а затем эволюционировала в полноценную систему обработки заявок. Изначально инструмент работал в тестовых средах по расписанию (cron), сканируя состояние баз данных. Однако, начиная со второй половины мая, нагрузка на систему мониторинга резко возросла из-за фрагментации данных и нехватки дискового пространства. Система мониторинга сгенерировала тысячи тикетов в сутки.
Важно: Этот проект является частью цикла R&D-исследований. Код агента на 80% был сгенерирован и отредактирован с помощью языковых моделей. Это доказывает, что оптимизацию задач в больших парках СУБД может повторить любая команда, имеющая доступ к инструментам agentic coding.
За 30 дней активной эксплуатации агент обработал 10 182 тикета. Ключевым итогом стало то, что 99,6% из них были решены автоматически. Остальные 0,4% сложных кейсов или случаев с отсутствием необходимых данных передавались специалистам для ручного вмешательства. Для сравнения: система autovacuum, работающая штатно, не справлялась с такой степенью фрагментации без вмешательства агента.
Техническая реализация: три главных обработчика
Архитектура агента строится вокруг модульных обработчиков, каждый из которых решает конкретную задачу. Использование искусственного интеллекта здесь не является универсальным решением, а применяется выборочно — только тогда, когда регулярных выражений недостаточно.
1. Обработка фрагментации данных (StatisticsHandler)
Это флагманский модуль системы. За месяц работы он закрыл 9671 тикет. Алгоритм проверяет состояние базы, анализирует нагрузку, ищет "мёртвые" строки (dead tuples) и выполняет команды VACUUM и ANALYZE.
* Пример эффективности: На одном из тестовых хостов агент за минуты обработал более 50 таблиц, освобождая место и обновляя статистику оптимизатора. В идеале такие настройки требуют долгого тонкого подбора, но агент решает задачу итеративно и стабильно.
2. Очистка дискового пространства (DiskSpaceHandler) При критическом заполнении дисков агент подключается к серверу через SSH. Здесь он подключает возможности LLM (в частности, GigaChat) для анализа текста заявки. Модель помогает сгенерировать безопасный план очистки, исключая удаление системных каталогов и позволяя удалять только временные или лог-файлы.
* Результат: Агент автоматически удалял старые логи (pgerrorlogs), освобождая от 8 до 8 ГБ пространства. Операция нормализует состояние хоста без участия человека.
3. Плановое обслуживание (PlannedMaintenanceHandler)
Модуль отвечает за плановые остановки баз данных. Он извлекает из текста тикета даты, хосты и тип действий, проверяет наличие согласований от руководителей и сохраняет задачу в планировщик. В назначенное время агент выполняет команды systemctl stop/start и закрывает заявку отчетом.
Экономия ресурсов и роль LLM
Одним из главных вопросов при внедрении ИИ является стоимость токенов. Статистика за 30 дней (с 4 мая по 2 июня) показывает умеренное потребление: суммарно было использовано около 2,6 млн токенов. Это в среднем менее 260 токенов на один обработанный тикет.
Такая экономия достигнута благодаря стратегии "regex-first": регулярные выражения обрабатывают более 95% стандартных ситуаций (например, в StatisticsHandler). LLM вызывается лишь в 10% случаев для извлечения сложных данных из текстовых описаний или генерации планов очистки.
Перенос задач из CI/CD Ранее рутинные операции выполнялись через сценарии Ansible в системе Pipeliner (аналог Jenkins). Это создавало очереди задач и зависимость от инфраструктуры сборки. Агент выполнил эти операции напрямую через SSH или SQL, что ускорило реакцию в два и более раза, устранило зависимость от слейвов и упростило добавление новых сценариев.
Интерактивный режим и будущее развитие
Помимо автономного сканирования, агент доступен как чат-бот через веб-интерфейс на базе Streamlit. Администраторы могут напрямую вызывать инструменты: скачивать журналы с анализом ошибок, генерировать отчеты по профилированию производительности (pg_profile), анализировать метрики ресурсов (CPU, память, диски).
Планы развития на ближайшие кварталы: * Внедрение обработчиков для первичной настройки (ProvisioningHandler) и резервного копирования (BackupHandler). * Создание интеллектуальных комментариев в тикетах: агент будет анализировать журналы при ошибках и давать разработчикам конкретные рекомендации. * Автоматическое уточнение параметров в запросах, где отсутствуют координаты. * Полный переход Ansible-сценариев на прямую работу агента, оставив Pipeliner только для сложных оркестровок.
Команда продолжает развивать дашборд эффективности, превращая эксперимент в полноценную вторую линию поддержки, способную обслуживать тысячи инцидентов без увеличения штата специалистов.