DBA Agent в действии: 10 тысяч тикетов и 99,6% автоматизации второй линии поддержки

Привет, Хабр! Это четвёртая статья цикла про R&D‑исследование для небольшой команды DBA.

Мы начали с того, что решили упростить мониторинг парка из более чем 800 экземпляров нашей СУБД Platform V Pangolin DB (реляционная СУБД на базе PostgreSQL) с помощью доработки postgres_exporter. А потом и вовсе собрали автономный агент, который сам обрабатывает тикеты: очищает дисковое пространство, выполняет VACUUM/ANALYZE и планирует остановки БД.

В этой статье расскажу, как мы продолжили тестировать гипотезу с агентом: перевели его в режим второй линии поддержки и замеряли реальные результаты. Будут числа, примеры, использование LLM для анализа паттернов, миграция задач из Pipeliner и планы по дальнейшему R&D и превращению агента в полноценную вторую линию поддержки.

Навигация по циклу:

• Часть 1 — доработка postgres_exporter → pangolin_exporter, исправление бага длительности транзакций.

• Часть 2 — автоматическое создание тикетов и ИИ‑отчёты (Monitoring_Checker_TT, Analyze_Pangolin_AI).

• Часть 3 — проектирование автономного агента: монолит, обработчики, лента событий, безопасность, инструкция по созданию.

Важный момент: агент — это продукт Agentic Coding: его код на 80% сгенерирован и отредактирован при помощи LLM. Поэтому повторить наш опыт могут все, кто обслуживает большие парки СУБД и интересуется оптимизацией задач через agentic coding.

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

Изначально автономный агент запустили в тестовых средах (более 800 баз данных) в режиме cron с периодическим сканированием тикетов — там он и продолжает работать.

В первой половине мая нагрузка была невысокой, но затем мы начали постепенно включать полный цикл обработки и добавили новые оповещения, генерирующие тикеты. Это привело к лавинообразному росту задач. Со второй половины мая до начала июня система мониторинга создала тысячи тикетов в сутки из‑за высокой фрагментации, нехватки места на дисках и плановых отключений.

Агент не только выдержал нагрузку, но и показал впечатляющие результаты. Ниже сухие числа и живые примеры:

• 10 182 тикетов обработано за 30 дней — рост +2426% к предыдущему периоду;

• 99,6% автоматически закрыто (StatisticsHandler). Системный autovacuum не справлялся с фрагментацией → агент обслуживал принудительно.

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

StatisticsHandler, флагман VACUUM/ANALYZE

StatisticsHandler — наш флагман. За месяц он закрыл 9671 тикет. Конечно, в процессе отладки мы находили и исправляли ошибки, но сейчас работает стабильно и мы не видим сбоев. Он проверяет мастер, смотрит нагрузку, находит мёртвые строки и выполняет VACUUM/ANALYZE. Мы специально не оптимизировали код, просто дали ему работать и смотрели — и он не подвёл. Но мы всё равно на всякий случай ежедневно проверяем журналы.

📅 Результат обслуживания (тикет обезличен):

Хост: db‑host-01.stands.example
База: sample_db
Таблиц, требующих обслуживания: 50 
✅ Нагрузка низкая (активных: 0, долгих транзакций: 0).
✅ Выполнена оптимизация.
— app_schema.event_entity (dead_tup=86966, требует VACUUM ANALYZE)
— app_schema.role_attribute (dead_tup=2318, требует VACUUM ANALYZE)
… и ещё 30 таблиц. Все операции успешны.

В идеале требуется тонкая настройка autovacuum под нагрузку. Но на тестовых стендах, где стенды постоянно удаляются и создаются заново, агент — быстрое и эффективное решение, закрывающее проблему за минуты.

DiskSpaceHandler, очистка диска с LLM‑планированием

При тикетах о нехватке места агент подключается по SSH, анализирует заполнение и с помощью LLM генерирует безопасный план очистки (только разрешённые паттерны, защита системных каталогов). Затем выполняет удаление или обрезку файлов.

Автоматическая очистка журналов Pangolin (тикет обезличен):

Ротация логов в /pgerrorlogs/ (версия X.X.X): оставлено последних 7 файлов, удалено 135 (было 142), освобождено ~8 360 МБ.
📊 Диагностика: занято до: 92% (8.5G), после: 3% (277M).
✅ Состояние нормализовалось. Тикет закрыт.

PlannedMaintenanceHandler, плановые остановки и запуски БД

Агент извлекает из текста тикета даты, хосты и тип действия, проверяет наличие согласования в комментариях, сохраняет задачу в JSON‑планировщик и в нужный момент выполняет systemctl stop/start. Затем закрывает тикет с полным отчётом.

⚠️ Автоматическая обработка (тикет обезличен)
— Хосты: vm‑host-01, vm‑host-02 
— Действие: stop → start
— Начало: 2026–06-02T14:30:00, Окончание: 2026–06-02T14:35:00 
— Базы данных: sample_db
— Согласование: approver.name [ok]
✅ Выполнена остановка БД (0.1 мин.)
✅ Выполнен запуск БД (0.1 мин.)
Все операции успешны.

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

Мы добавили в агент еженедельную задачу — анализ открытых тикетов с помощью LLM. Модель (GigaChat) категоризирует тикеты по темам, ищет повторяющиеся паттерны и предлагает новые обработчики. За несколько недель мы выявили три устойчивых кластера:

• Первичная настройка БД (тикеты CORESUP-55751, -55321, -54515 и др.) → потенциальный ProvisioningHandler.

• Запросы на резервные копии (CORESUP-55070) → BackupHandler.

• Некорректные запросы на очистку данных без указания координат → авто‑уточнение через LLM (в планах).

Сейчас LLM используем в агенте для:

• извлечения хоста со сверкой с актуальным реестром, mountpoint, дат и времени из свободного текста тикета (fallback, когда regex не срабатывает);

• определения наличия временных индикаторов в тикетах планового обслуживания;

• генерирования плана очистки диска (DiskSpaceHandler);

• категоризации тикетов по темам (диск, вакуум, производительность, настройка);

• формирования рекомендаций администратору, если автоматическая очистка не освободила место.

Ближайший план: научить агента создавать в тикете развёрнутый комментарий с указанием причин проблемы (из журналов) и конкретными рекомендациями для разработчиков, при нарушении констрейнтов, долгих блокировках и так далее.

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

Ранее многие рутинные операции (обновление статистики, ротация журналов, проверка мест на дисках) выполнялись через Ansible‑сценарии, запускаемые из Pipeliner (аналог Jenkins). Результат — очереди, зависимость от доступности слейвов и накладные расходы.

Сейчас мы постепенно переносим эти задачи в агент. Они выполняются напрямую через SSH или SQL, без промежуточных слоёв. Результат:

• скорость выполнения выросла в два и более раз;

• устранена зависимость от инфраструктуры CI/CD;

• единое журналирование и контроль через ленту событий агента;

• лёгкость добавления новых сценариев без настройки задач.

В планах полностью перенести в агент обновление версий Pangolin и другие рутинные операции, оставив Pipeliner только для сложных оркестровок.

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

Помимо автономного сканера агент доступен в виде чат‑бота через Streamlit WebUI. Пользователи могут напрямую вызывать инструменты, минуя создание тикетов. Среди наиболее востребованных:

• Скачать журнал СУБД с хоста с опциональным ИИ‑анализом ошибок (GigaChat выделяет критические события).

• pg_profile: отчёты и снэпшоты, аналог AWR для PostgreSQL/Pangolin.

• ИИ‑отчёт analyze_pangolin_ai собирает метрики из Prometheus и генерирует выводы по CPU, памяти, дискам, блокировкам.

• Установить или удалить pg_profile на хост с подтверждением и перезапуском БД.

• Поставить/снять хост(ы) на мониторинг через интеграцию с Pipeliner (требует подтверждения).

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

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

За 30 дней (4 мая — 2 июня) агент обработал 10182 тикета. Однако LLM вызывалась лишь в ≈10% случаев, там, где регулярных выражений было недостаточно. Статистика по обработчикам:

Суммарное потребление токенов за 30 дней составило около 2,6 млн с учётом разовых вызовов и кеширования. Средний расход на один вызов LLM — 2 500 токенов.

Экономия достигнута с помощью:

• приоритетного использования regex (больше 95% тикетов StatisticsHandler не требуют LLM);

• встроенного кеширования (llm_analysis_cache.py, TTL 30 минут);

• кеширования версий Pangolin и других метаданных.

Автономный агент остаётся экономичным: менее 260 токенов на один обработанный тикет.

Вторая линия поддержки: как это работает сегодня и что дальше

Агент занял позицию второй линии поддержки. Типовые задачи (VACUUM/ANALYZE, очистка диска, плановые остановки) решаются полностью автоматически. Если агент не справился (нет данных, ошибка, требуется архитектурное решение) или тикет содержит сложную логику, то задача передаётся специалисту с пометкой NO_AUTO_RESOLVE. Сотрудник видит в ленте событий все попытки агента и может принять решение.

• 99,6% автоматизации в StatisticsHandler, агент готов к масштабированию на всю команду DBA.

• 24-кратный рост нагрузки без увеличения ручного труда, экономия >500 человеко‑часов в месяц.

Планы развития (ближайшие кварталы):

• Реализация ProvisioningHandler и BackupHandler — на основе выявленных LLM паттернов.

• Интеллектуальные комментарии в тикетах — агент будет анализировать журналы при нарушении ограничений и указывать разработчикам точную причину ошибки и рекомендации.

• Уточнение параметров через LLM для запросов без явных координат (например, «почини базу» → уточнить, какую именно).

• Полная миграция оставшихся Ansible‑сценариев в агент (обновление Pangolin, управление расширениями).

• Дашборд эффективности — витрина с KPI, трендами, предсказанием переполнения дисков.

Все описанные улучшения уже находятся в работе.

Заключение

Автономный DBA‑агент, который мы собрали как R&D‑эксперимент, пережил 10 тысяч тикетов за месяц. Он не лёг, не завис, не накосячил (ну, почти — 3% тикетов мы отдали людям). Монолитная архитектура с ThreadPool и точечной LLM оказалась надёжнее, чем мы предполагали.

Мы не строили супер‑инфраструктуру, не разворачивали Kubernetes, не писали микросервисы. Просто cron, Python и пара обработчиков. Идём дальше: готовим дашборд эффективности и новые обработчики. Если интересно — делитесь мнением в комментариях!