Агент на второй линии: как автоматизируют не разговор с клиентом, а рутину администратора баз данных

Что сделали в Сбере. Команда DBA развила автономного агента для своей СУБД Platform V Pangolin DB, совместимой с PostgreSQL. После перевода в режим второй линии поддержки агент обработал около 10 тысяч тикетов и закрыл 99,6% задач. Ключевое здесь не цифра, а список того, что агент реально делает: очистка дискового пространства, обслуживание VACUUM/ANALYZE и планирование остановок базы данных. Это три узких, заранее известных класса операций, а не «поддержка вообще». Языковая модель используется для анализа паттернов обращений, часть задач мигрировала из Pipeliner, прежнего инструмента. Источник: Habr, статья «DBA Agent в действии: 10 тысяч тикетов и 99,6% автоматизации второй линии поддержки».

Первый урок: агенту отдают то, что можно проверить автоматически. Возьмите очистку дискового пространства: у операции есть однозначный критерий успеха - сколько места освободилось. Результат видно сразу, и его не нужно защищать в переписке. Такую задачу можно поручить агенту и почти не перепроверять. Сравните с планированием остановок базы данных: там появляются окна согласования, зависимые команды, риск задеть чужой релиз. Формально это тот же агент, но цена ошибки и число участников другие. Обобщение простое: прежде чем отдавать операцию ИИ, спросите, сможет ли система сама определить, что всё прошло хорошо. Если ответ «нет, надо посмотреть глазами», вы автоматизируете не работу, а подготовку отчёта о работе.

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

Третий урок: 99,6% - это метрика предела, а не метрика успеха. За 0,4% задач, закрытых людьми, обычно спрятано самое дорогое: редкие инциденты, нестандартные конфигурации, случаи, где формального регламента нет. Гнаться за 100% в таких системах дороже, чем оставить хвост человеку. Планируя бюджет автоматизации, заранее определите, где вы останавливаетесь и кто закрывает остаток. Проект, который обещает ноль ручных операций, почти наверняка либо лукавит в отчётности, либо перекладывает ручной труд на этап, который в отчётность не попал.

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

1. Проверяемость важнее интеллекта. Начинайте с операций, у которых есть однозначный автоматический критерий результата: освободилось место, завершилось обслуживание, применилось обновление.
2. Начинайте со второй линии: разобранный и классифицированный архив обращений даёт и материал для обучения, и точный список сценариев для автоматизации.
3. Заранее определите, где остановитесь: оставленный человеку «хвост» редких случаев дешевле, чем попытка добить автоматизацию до 100%.
4. Не создавайте второй контур учёта: агент должен жить в той же системе заявок, что и люди, иначе вы добавите ручной работы.
5. Разделяйте роли модели и скриптов: LLM пусть разбирает паттерны и классифицирует, а действия выполняет проверяемый код.