Что такое DBA-агент на базе LLM и зачем он нужен
DBA-агент на базе LLM — это автономная система, которая сама разбирает и закрывает тикеты второй линии поддержки баз данных. Команда DBA из Сбера разработала такого агента в R&D-проекте для парка из более чем 800 экземпляров Platform V Pangolin DB, реляционной СУБД на базе PostgreSQL. Агент запущен в тестовых средах и работает в режиме cron: периодически сканирует очередь тикетов, определяет тип проблемы и применяет готовый сценарий. Как это устроено, команда подробно описала в разборе на Habr.
Задача выросла из потока инцидентов. Во второй половине мая и начале июня система мониторинга создавала тысячи тикетов в сутки: сказывались высокая фрагментация таблиц, нехватка места на дисках и плановые отключения. Ручная обработка такого объёма упирается в размер дежурной смены, поэтому ставку сделали на автоматику.
Ключевая особенность архитектуры — точечное использование LLM. GigaChat вызывается примерно в 10% случаев, когда обращение требует разбора естественного языка. Остальное закрывают регулярные выражения и детерминированная логика обработчиков. Такой подход даёт предсказуемость и низкую стоимость: за 30 дней суммарный расход составил около 2,6 млн токенов, менее 260 токенов на тикет.
Отдельный сюжет — как писался сам агент. Его код на 80% сгенерирован и отредактирован при помощи LLM, то есть проект стал продуктом Agentic Coding: человек формулировал задачи и проверял результат, рутинную часть кода писала модель.
Архитектура обработчиков: как агент решает типовые DBA-задачи
В эксплуатации три обработчика. Каждый отвечает за свой класс тикетов и работает по общей схеме: запуск по cron, чтение очереди, классификация запроса, выбор сценария, выполнение и закрытие тикета с комментарием. Если ни один сценарий не подошёл, обработчик возвращает NO_AUTO_RESOLVE и передаёт обращение человеку.
Разбор опирается на регулярные выражения. Тикеты от системы мониторинга приходят в предсказуемом формате, поэтому в большинстве случаев достаточно вытащить имя базы, метрику и порог срабатывания. LLM подключается только там, где текст не укладывается в шаблон.
Логика оркестрации здесь близка к любой агентной системе: набор инструментов, маршрутизация запроса, обработка ошибок и понятные критерии остановки. Практические детали такого пайплайна, включая память и обработку сбоев, мы разбирали в материале про самописного AI-агента на Python.
StatisticsHandler: флагманский обработчик для VACUUM/ANALYZE
StatisticsHandler закрыл 9671 тикет за месяц и стал главным источником автоматизации. Он выполняет принудительный VACUUM/ANALYZE, когда фрагментация выходит за допустимые значения. Причина появления обработчика практичная: системный autovacuum не справлялся с обслуживанием парка из 800+ баз, и таблицы разрастались быстрее, чем успевали очищаться.
Сигналы для решения команда получает из мониторинга, для которого дорабатывался postgres_exporter, чтобы упростить наблюдение за сотнями экземпляров СУБД. Если метрика выходит за порог, агент запускает обслуживание и закрывает тикет с отчётом о выполнении.
Автоматизация сняла с дежурных повторяющиеся операции и убрала задержку между появлением фрагментации и её устранением. Для баз, которые быстро растут, эта задержка напрямую влияет на скорость запросов.
Очистка дискового пространства и планирование остановок БД
Второй обработчик освобождает место на дисках, чтобы инцидент не успел превратиться в отказ. Третий отвечает за плановые остановки и запуски баз: проверяет заявку, выполняет действие и фиксирует результат в тикете.
Обе задачи раньше шли через Pipeliner и руки дежурного DBA. Сейчас они постепенно переезжают в агент с ускорением выполнения в два и более раза. Полный цикл обработки включали не сразу, а пошагово, по мере проверки сценариев в тестовых средах.
Точечное использование LLM: почему GigaChat вызывается только в 10% случаев
Выбор между regex и LLM здесь решает экономика. Тикет от системы мониторинга содержит фиксированный набор полей, поэтому разбор шаблоном занимает миллисекунды и не стоит ничего. Модель нужна там, где формулировка свободная или где требуется сопоставить несколько сигналов сразу.
По данным команды, LLM задействуется примерно в 10% случаев. Итог за 30 дней: около 2,6 млн токенов на 10 182 тикета, менее 260 токенов на одно обращение. Арифметика сходится: 10 182 умножить на 260 даёт примерно 2,65 млн. Если бы каждый тикет уходил в модель с промптом на 1–2 тыс. токенов, счёт шел бы на десятки миллионов токенов в месяц. Цифры и детали архитектуры команда привела в своём разборе.
У LLM в проекте две роли. Первая — разбор нестандартных обращений, которые не попали в шаблон. Вторая — аналитика: модель просматривает паттерны открытых тикетов и подсказывает, какие сценарии имеет смысл автоматизировать следующими.
Побочная выгода такой схемы — предсказуемость. Regex-правило легко протестировать и объяснить, а его поведение не меняется от версии модели. LLM остаётся изолированным инструментом для узкого класса задач, и её ошибки не влияют на массовую обработку.
Результаты за 30 дней: 10 182 тикета и 99,6% автоматизации
| Метрика | Значение |
|---|---|
| Обработано тикетов за 30 дней | 10 182 |
| Рост к предыдущему периоду | +2426% |
| Автоматически закрыто | 99,6% |
| Закрыто обработчиком StatisticsHandler | 9671 |
| Расход токенов | около 2,6 млн |
| Токенов на тикет | менее 260 |
| Доля обращений с вызовом LLM | около 10% |
| Парк под управлением | более 800 экземпляров |
Все эти цифры относятся к тестовым средам, где работает более 800 баз данных. Рост в 2426% объясняется не взрывным увеличением инцидентов, а тем, что агент забрал на себя поток, который раньше обрабатывали вручную. В пиковые периоды второй половины мая и начала июня счёт шёл на тысячи тикетов в сутки, и именно тогда стало понятно, что без автоматики очередь не разгрести. Команда опубликовала сводку по проекту.
Структура обращений тоже показательна: 9671 тикет из 10 182 закрыл один обработчик. Основная нагрузка была сосредоточена в одной категории задач, а не размазана по десяткам сценариев.
Механизм эскалации NO_AUTO_RESOLVE и ограничения решения
Автоматизация не отменяет дежурного. Обработчик возвращает статус NO_AUTO_RESOLVE, если тикет не совпал ни с одним сценарием или действие требует человеческого решения. Такое обращение уходит на вторую линию с контекстом: что агент проверил и почему не стал действовать. Разница между 99,6% и 100% — это как раз такие случаи.
Ограничения команда называет прямо. Агент запущен в тестовых средах и продолжает там работать. Полный цикл обработки включали постепенно. В процессе отладки находили и исправляли ошибки. Метрики 10 182 тикета и 99,6% автоматизации относятся к конкретному 30-дневному окну, в другие периоды они будут другими.
Есть и менее очевидный риск. Агент, который закрывает тикеты молча, легко создаёт иллюзию благополучия: сводка зелёная, а часть обращений уходит в эскалацию или закрывается формально. Как ловить такие сбои на живом трафике и связывать их с реальным качеством, разбирали в статье про двухуровневый мониторинг продакшн-агентов.
Как LLM помогает находить новые сценарии автоматизации
Открытые тикеты — это карта того, что пока не автоматизировано. LLM анализирует их тексты, группирует по смыслу и показывает повторяющиеся сценарии. Дальше команда решает, что дешевле: расширить regex-правила или написать отдельный обработчик.
Цикл получается замкнутым. Обработчик снимает поток однотипных тикетов, модель находит в остатке новую массовую категорию, под неё появляется следующий обработчик. Тот же поток обращений о фрагментации, нехватке места и плановых отключениях, который в мае и июне исчислялся тысячами в сутки, сейчас закрывают специализированные сценарии.
Практическая ценность здесь в приоритизации. Автоматизировать всё подряд бессмысленно: выгоднее закрыть одну категорию с сотнями тикетов в месяц, чем десять редких случаев.
Миграция задач из Pipeliner и ускорение выполнения
Pipeliner остаётся в процессе. Типовые операции (VACUUM/ANALYZE, очистка дисков, остановка и запуск БД) постепенно переезжают в агент, где выполняются в два и более раза быстрее. За Pipeliner остаются более сложные и редкие сценарии.
По смыслу это перераспределение нагрузки, а не замена инструмента. Дежурный занимается нетривиальными инцидентами, рутина уходит в автоматику. Для команды выгода двойная: сокращается время реакции и освобождается время на задачи, которые действительно требуют квалификации.
Практические выводы: кому подходит такой подход и что учесть
Подход воспроизводим, но не в любом масштабе. Три условия: парк из сотен экземпляров, где ручная обработка становится узким местом; стабильный поток однотипных тикетов от системы мониторинга; готовность держать основную логику на regex, а LLM подключать точечно.
Что учесть при внедрении:
- Начинать в изолированной тестовой среде и включать обработчики по одному.
- Заранее определить, какие действия агент может выполнять сам, а какие требуют подтверждения человека.
- Следить за долей NO_AUTO_RESOLVE: её рост сигнализирует о новых категориях задач.
- Считать расход токенов на тикет, а не общий: так видно, где модель реально нужна.
- Помнить, что код на 80% сгенерирован LLM, но проверка, отладка и ответственность остаются на инженере.
Коробочного продукта здесь нет. Это внутренний R&D-проект под конкретный парк, стек мониторинга и процессы, поэтому переносить его один в один в другую инфраструктуру не получится. Полезнее взять схему: минимум LLM там, где хватает шаблона, постепенное наращивание покрытия и анализ открытых тикетов как источник новых сценариев. Похожий сюжет про внедрение агента в контуре с жёсткими требованиями и его реальную пользу разбирали в статье про ИИ-агента, который стал помощником аналитиков.