Содержание
Sber перевёл автономного агента в режим второй линии поддержки для парка из более чем 800 экземпляров PostgreSQL-совместимой СУБД Platform V Pangolin DB. Вместо ручной обработки тикетов агент самостоятельно выполняет VACUUM, очищает место на дисках и планирует остановки. За 30 дней он закрыл 10 182 обращения, причём 99,6 % — без участия человека. Это позволяет команде DBA сосредоточиться на задачах, которые действительно требуют экспертизы. Для руководителей и инженеров, решающих, стоит ли внедрять подобное решение, важно понимать, что агент не заменяет первую линию и не работает полностью автономно в нестандартных ситуациях: ежедневный просмотр логов и возможность ручного вмешательства остаются обязательными.
Обработка типовых проблем без участия инженера
Агент состоит из нескольких независимых обработчиков, каждый из которых отвечает за конкретный класс тикетов. StatisticsHandler проверяет нагрузку на мастере, подсчитывает мёртвые строки и при необходимости запускает VACUUM ANALYZE. VACUUM ANALYZE — это операция, которая удаляет устаревшие версии строк и обновляет статистику планировщика запросов. За месяц он обработал 9671 обращение, причём в тестовых средах, где autovacuum не успевает за частыми пересозданиями стендов, это решает проблему за минуты. Autovacuum — встроенный фоновый процесс PostgreSQL, который автоматически выполняет очистку, но в динамичных тестовых контурах его возможностей часто недостаточно. Для команд, оценивающих внедрение, важно, что такой обработчик снижает риск раздувания таблиц и деградации производительности без постоянного участия человека.
DiskSpaceHandler подключается по SSH, анализирует заполнение и с помощью LLM составляет план очистки, который затрагивает только разрешённые каталоги. SSH обеспечивает защищённый удалённый доступ к серверам, а LLM (большая языковая модель) генерирует понятный план действий на основе описания проблемы. В одном из примеров он удалил 135 старых файлов логов и освободил 8,3 ГБ, снизив заполнение с 92 % до 3 %. При принятии решения о внедрении стоит учитывать, что доступ по SSH требует жёстких ограничений прав и белых списков команд, чтобы исключить риск воздействия на продуктивные данные.
PlannedMaintenanceHandler извлекает из текста тикета даты, хосты и тип действия, проверяет согласование и выполняет остановку или запуск через systemctl. Такая модульная структура позволяет добавлять новые обработчики, не переписывая весь агент. При этом код на 80 % сгенерирован и доработан с помощью LLM, что снижает порог входа для команд, которые хотят повторить подход. Для оценки применимости важно, что модульность упрощает поддержку и масштабирование, но требует начальной настройки прав доступа и правил аудита, чтобы все действия оставались контролируемыми.
Анализ паттернов и расширение автоматизации
Раз в неделю агент запускает LLM-анализ открытых тикетов. Модель группирует обращения по темам и предлагает новые обработчики. За несколько итераций выявились устойчивые кластеры: первичная настройка баз, запросы резервных копий и ошибки миграций. Это дало приоритетные направления для следующих обработчиков — ProvisioningHandler и BackupHandler. Такой подход превращает агента из набора жёстких скриптов в систему, которая сама указывает, что ещё можно автоматизировать. При этом все действия логируются, а тикеты закрываются с отчётом, что упрощает аудит и разбор инцидентов. Руководителям, решающим о внедрении, следует оценить, насколько прозрачная отчётность и возможность ручного контроля соответствуют внутренним требованиям безопасности и compliance.
Применимость в российских инфраструктурах
Pangolin DB — это российская сборка PostgreSQL, поэтому опыт напрямую переносится на другие PG-совместимые СУБД, используемые в РФ. Агент не требует облачных сервисов и работает в изолированных контурах, где доступны только SSH и локальные утилиты. Главное ограничение — необходимость точной настройки прав и белых списков команд, чтобы избежать случайного воздействия на продуктив. Для команд, которые поддерживают сотни экземпляров PostgreSQL, внедрение такого агента снижает нагрузку на вторую линию поддержки в десятки раз. При этом остаётся возможность ежедневного просмотра логов и ручного вмешательства при нестандартных ситуациях. Дальнейшее развитие планируют в сторону полноценной второй линии, где агент будет принимать решения по более широкому кругу задач без участия человека. При оценке решения важно взвесить выгоду от сокращения рутинных тикетов против затрат на начальную настройку прав и мониторинг, а также убедиться, что существующие политики безопасности допускают автоматизированные действия через ограниченные SSH-доступы.
Источник
Это краткий разбор материала Сбер. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Агент для второй линии DBA — 10 тысяч тикетов за месяц.
Курс по теме — Каталог курсов Школы Больших Данных


