Год LLM-агентов в ИТ-операциях: итоги 2024

В августе мы запускали первый пилот с CodeLlama и Ansible с осторожным оптимизмом. Сейчас декабрь, позади несколько месяцев реального использования у разных клиентов, и пора честно ответить на вопрос: что из этого осело в рабочем процессе, а что осталось демонстрацией на слайде.

Итоги не триумфальные и не катастрофические. Всё как обычно с инструментами.

Что реально работает и экономит время

Генерация черновиков Ansible-задач. Это, пожалуй, единственное место, где польза ощутима без оговорок. Написать комментарий с описанием задачи и получить скелет YAML с правильными модулями - это несколько минут против лезть в документацию за именами параметров. Инженеры, которые попробовали, в большинстве своём остались с этим инструментом. Ключевое слово - черновик: без ревью запускать нельзя, но ревью готового скелета быстрее, чем писать с нуля.

На типовых задачах - установка пакетов, управление сервисами, базовые шаблоны - Ansible Lightspeed в VSCode ведёт себя прилично. Локальная CodeLlama слабее по точности параметров, зато не требует отправки кода в облако, что для ряда клиентов закрывает вопрос сразу.

Парсинг и первичный анализ логов. Неожиданно полезный сценарий, который мы не планировали как приоритетный. Скормить LLM огрызок из /var/log с просьбой объяснить, что происходит, и получить нормальное человекочитаемое объяснение стектрейса или последовательности ошибок - это работает. Не замена инженеру, но помогает ориентироваться быстрее, особенно когда лог из незнакомой системы и нет времени разбираться в деталях с нуля.

Здесь мы используем локальные модели через простой HTTP-интерфейс - никакого агентного цикла, только «прочитай этот фрагмент и скажи что тут не так». Галлюцинации случаются, но в этом сценарии они относительно безопасны: инженер всё равно смотрит своими глазами, LLM только указывает направление.

Объяснение незнакомого кода и конфигов. GitHub Copilot Chat для этого пользуются несколько инженеров на проектах, где облако допустимо. Попросить объяснить что делает этот Terraform-модуль или что означает эта строчка в nginx.conf - экономит время на поиск в документации. Мелочь, но мелочей таких много.

Что не оправдало ожиданий

Агентные цепочки с автоматическим выполнением действий. Год назад казалось, что «агент, который сам запускает Ansible по описанию задачи» - это то, к чему мы движемся. На практике дошло до осознания: автономное выполнение действий в инфраструктуре без явного подтверждения инженера - это слишком высокая ставка за слишком нестабильное качество решений. Модель может правильно написать плейбук и неправильно понять область применения. Пока всё, что мы используем - это режим «предложи, инженер проверит и запустит».

Генерация сложных плейбуков с ролями. Как и отмечали в августовском пилоте, на задачах с block/rescue, сложными зависимостями ролей, нестандартными инвентарными структурами модели начинают выдавать сырой материал, который править дольше, чем написать. Экономии нет.

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

Code review как полноценная замена ревью инженером. Тестировали LLM-ревью Ansible и Terraform в CI на нескольких проектах. Модель ловит синтаксические проблемы и иногда замечает логические - но пропускает именно тот класс ошибок, который важнее всего: неправильные предположения о состоянии системы, нарушения идемпотентности, сайд-эффекты на смежные сервисы. Это не инструмент «вместо», это инструмент «в дополнение».

Почему оказалось сложнее

Главная причина - контекст. LLM хорошо работает на задачах, для которых достаточно общих знаний об инструменте. Как только задача требует понимания конкретного окружения - начинаются проблемы. Инфраструктурная работа почти всегда контекстно-зависима: «настрой мониторинг» означает разное у каждого клиента.

Второе - дисциплина ревью. В начале года казалось, что это формальность. К концу года убедились: без жёсткого правила «любой сгенерированный код проходит ревью по чеклисту» инструмент накапливает технический долг быстрее, чем экономит время. Усталый инженер запускает плейбук без нормальной проверки - и вот уже расхлёбываем последствия.

Третье - облако против контура. Для клиентов с требованиями по данным выбор инструментов ограничен локальными моделями, которые объективно слабее облачных специализированных решений. Этот разрыв никуда не делся.

Где стоим

Из всего опробованного в рабочий процесс осело примерно следующее: генерация черновиков задач Ansible для типовых сценариев, LLM-объяснение незнакомых логов и конфигов, Copilot Chat для документационных вопросов там, где облако допустимо. Это скромнее, чем ожидалось в начале года, но зато реально работает без постоянных оговорок.

Агентные сценарии с автономными действиями остаются на стадии «интересно, но не сейчас». Не потому что принципиально невозможно, а потому что цена ошибки в инфраструктуре высокая, а качество решений пока не позволяет снизить участие инженера в петле настолько, чтобы это имело смысл.