Как мы автоматизировали работу DBA: 10 000 тикетов и 99,6% успеха

Это очередной материал из цикла, посвященного нашему R&D-исследованию в сфере администрирования баз данных. Ранее я рассказывал, как мы оптимизировали мониторинг парка из 800+ экземпляров СУБД Pangolin DB и спроектировали автономного агента для выполнения рутинных задач. В этой статье я поделюсь результатами эксплуатации системы в режиме второй линии поддержки.

Наш агент стал настоящим инструментом класса Agentic Coding: около 80% кода было создано и доработано с помощью LLM. Мы перевели систему в боевой режим, замерили показатели нагрузки, проанализировали эффективность взаимодействия с ИИ и наметили векторы для дальнейшего масштабирования. Этот опыт будет полезен всем, кто управляет крупными инфраструктурами СУБД и ищет способы снижения операционной нагрузки.

От концепции к реальной нагрузке

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

Итоги работы за 30 дней впечатляют: агент обработал 10 182 тикета, что означает рост нагрузки на 2426% по сравнению с предыдущим периодом. Показатель автоматизации в рамках модуля StatisticsHandler достиг 99,6%, что позволило полностью снять с команды DBA рутинные операции по принудительному обслуживанию баз.

Три обработчика в эксплуатации: разбор примеров

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

StatisticsHandler: флагман обслуживания

Этот модуль стал самым востребованным, закрыв за месяц 9671 тикет. Его задача — мониторинг мастера, анализ нагрузки и запуск VACUUM/ANALYZE при обнаружении критического количества «мертвых» строк. Несмотря на отсутствие сложной оптимизации кода, обработчик работает стабильно. В условиях тестовых стендов, которые постоянно пересоздаются, такой подход стал идеальным решением: агент устраняет проблемы с производительностью за считанные минуты без участия инженера.

DiskSpaceHandler: LLM-планирование очистки

При поступлении жалоб на нехватку места агент подключается по SSH, сканирует накопители и формирует план очистки. С помощью LLM он определяет безопасные для удаления файлы, строго соблюдая заданные паттерны. Это позволяет, например, выполнять ротацию логов Pangolin: агент оставляет нужное количество последних записей, удаляя устаревшие и освобождая гигабайты пространства.

PlannedMaintenanceHandler: автоматизация остановок

Этот компонент берет на себя плановые работы. Он парсит текст тикета, извлекая хосты, даты и тип операции, проверяет наличие согласований в комментариях и вносит задачу в JSON-планировщик. В заданное время агент выполняет systemctl stop/start, после чего формирует итоговый отчет и закрывает заявку.

LLM-анализ: агент сам подсказывает, что автоматизировать дальше

Мы внедрили еженедельный анализ открытых тикетов с помощью GigaChat. Модель группирует заявки по паттернам, что позволило выявить три направления для развития: подготовку модуля ProvisioningHandler для первичной настройки БД, создание BackupHandler для бэкапов и систему авто-уточнения данных для некорректных запросов.

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

Миграция типовых DBA задач из Pipeliner в агента

Раньше рутина (статистика, логи, диски) выполнялась через Ansible-скрипты в Pipeliner, что приводило к очередям и зависимости от CI/CD. Сейчас мы переносим эти сценарии в автономного агента. Исполнение команд напрямую через SQL или SSH позволило ускорить процессы в два и более раза, устранить лишние слои инфраструктуры и консолидировать логирование в единой ленте событий.

Интерактивный режим: чат-бот и ручные инструменты

Помимо автоматического режима, мы предусмотрели чат-бот на базе Streamlit WebUI. Через него инженеры могут в ручном режиме запускать инструменты: скачивать логи с ИИ-анализом ошибок, собирать отчеты pg_profile (аналог AWR для PostgreSQL) или генерировать диагностические отчеты по состоянию CPU и памяти через Prometheus. Любая активность пользователя также попадает в общую ленту, обеспечивая прозрачность всех действий.

Потребление токенов LLM

За месяц работы агент потребил около 2,6 млн токенов. При этом LLM привлекалась лишь в 10% случаев: в остальных задачах мы обходимся регулярными выражениями. Высокая экономичность достигается за счет приоритетного использования regex, кеширования метаданных и использования модуля llm_analysis_cache.py с TTL в 30 минут. В среднем на один обработанный тикет уходит менее 260 токенов.

Вторая линия поддержки: итоги и дальнейшие шаги

Агент успешно занял нишу второй линии поддержки. Сложные кейсы, требующие архитектурного вмешательства, по-прежнему передаются людям с пометкой NO_AUTO_RESOLVE, однако основной объем рутины закрывается автоматически. Мы достигли 24-кратного роста нагрузки без расширения штата, экономя более 500 человеко-часов в месяц.

В ближайшие кварталы мы сфокусируемся на создании полноценного дашборда эффективности, полной миграции оставшихся Ansible-сценариев и реализации интеллектуальных комментариев к заявкам. Эксперимент показал, что простая архитектура на базе монолита, Python и ThreadPool работает надежнее многих сложных систем, что дает нам отличную базу для дальнейшего R&D.