В команде DBA больше 800 экземпляров СУБД Platform V Pangolin DB (реляционная база на основе PostgreSQL). Рутины много: фрагментация, переполнение дисков, плановые остановки. В четвёртой статье цикла DBA-команда описала, как их автономный агент месяц работал второй линией поддержки и обработал 10 182 тикета, из которых 99,6% закрыл StatisticsHandler. Полезно разобрать, как устроены границы автоматизации в среде, где агент имеет дело с продом.
Что агент делает сам
За месяц 10 182 тикета, рост нагрузки к предыдущему периоду составил +2426%. У агента три готовых обработчика, и каждый закрывает свой класс задач.
- StatisticsHandler, флагман, закрыл 9671 тикет. Проверяет мастер, смотрит нагрузку, находит мёртвые строки и принудительно выполняет VACUUM/ANALYZE. Системный autovacuum на фрагментированных базах не справлялся, и агент закрывал проблему за минуты.
- DiskSpaceHandler занимается очисткой диска. Подключается по SSH, оценивает заполнение, LLM генерирует план очистки с защитой системных каталогов и удаляет только разрешённые паттерны. В одном из примеров ротация логов в /pgerrorlogs/ удалила 135 файлов и освободила около 8 360 МБ: занято до 92%, после 3%.
- PlannedMaintenanceHandler отвечает за плановые остановки и запуски БД. Извлекает из текста тикета хосты, даты и тип действия, проверяет согласование в комментариях, кладёт задачу в JSON-планировщик и в нужный момент вызывает systemctl stop/start. В одном примере остановка и запуск заняли по 0,1 минуты.
Доступ к проду сделан через SSH и прямые SQL-запросы. Раньше часть этих операций шла через Ansible-сценарии из Pipeliner, получались очереди и зависимость от доступности слейвов. После переноса скорость выполнения выросла минимум вдвое, а инфраструктура CI/CD для рутины больше не нужна.
Где остаётся человек
Граница простая: если агент не справился (нет данных, ошибка, нужно архитектурное решение), задача уходит специалисту с пометкой NO_AUTO_RESOLVE. В ленте событий сотрудник видит все попытки агента и решает сам. Авторы называют долю ручной обработки около 3%.
Команда продолжает ежедневно проверять журналы, не потому что агент сыплет ошибками, а «на всякий случай». Это и есть реалистичная защита: автоматизация высокая, но контроль остаётся.
Зачем внутри LLM и где она экономит
LLM вызывалась только в ≈10% случаев, там, где регулярных выражений не хватало. Суммарно за 30 дней около 2,6 млн токенов, в среднем 2 500 на вызов. На один обработанный тикет получается менее 260 токенов. Экономия достигается тремя приёмами.
- Сначала regex, LLM как fallback. Больше 95% тикетов StatisticsHandler обходятся без модели.
- Кеш разбора llm_analysis_cache.py с TTL 30 минут и кеш метаданных вроде версий Pangolin.
- Узкие задачи для модели: извлечение сущностей из свободного текста, поиск временных индикаторов, генерация плана очистки диска и еженедельная категоризация тикетов по темам.
Эта же LLM раз в неделю анализирует открытые тикеты и сама подсказывает, какие обработчики добавить дальше. У команды уже три устойчивых кластера: первичная настройка БД, запросы на резервные копии и некорректные запросы на очистку без указания координат. Для первых двух кластеров готовят ProvisioningHandler и BackupHandler.
Где споткнулись
- При включении полного цикла обработки и новых оповещений нагрузка лавинообразно выросла: в пике система мониторинга создавала тысячи тикетов в сутки из-за фрагментации, нехватки места и плановых отключений.
- В процессе отладки в StatisticsHandler находили и исправляли ошибки. Сейчас обработчик работает стабильно, сбоев не видят.
- В обработчик планового обслуживания заложили проверку согласования в комментариях тикета.
- На тестовых стендах базы постоянно создаются и удаляются заново, поэтому вместо тонкой настройки autovacuum под каждую нагрузку проще держать агентский VACUUM/ANALYZE.
Как повторить
- Разделите рутину на узкие классы задач и сделайте под каждый отдельный обработчик: один тип действия, один модуль с предсказуемой логикой.
- Сначала regex и кеширование, LLM подключайте только там, где регулярные выражения не справляются.
- Научите агента извлекать сущности из свободного текста тикета (хосты, mountpoint, даты) и сразу сверять их с актуальным реестром, чтобы не выполнять операцию по устаревшим данным.
- Любое деструктивное действие в проде (удаление файлов, остановка БД) пропускайте через проверку согласования в комментариях или через явное подтверждение, а в ленту событий пишите все попытки.
- Добавьте еженедельный LLM-разбор открытых тикетов: модель категоризирует их и сама подсказывает, какие новые обработчики нужны.
- Оставьте человеку право вмешаться в любой момент и видимость всех попыток агента через единую ленту событий. Контроль журналов становится ежедневной задачей.
- Замеряйте долю автоматически закрытых тикетов и расход токенов на один тикет: это два числа, по которым видно и эффект, и экономику.