LLM-агенты в ИТ-операциях: запускаем пилот с CodeLlama и Ansible

Тема LLM в автоматизации инфраструктуры стала заметно громче этим летом. Red Hat продвигает Ansible Lightspeed на базе IBM Watson Code Assistant, GitLab Duo пишет CI-пайплайны по описанию - всё это облачные сервисы, которые требуют уходить кодом и контекстом за периметр. Для клиентов с требованиями по обработке данных внутри контура это сразу закрытая дверь. Мы решили проверить, что можно сделать локально.

Что именно тестировали

Пилот простой по задумке: берём CodeLlama 34B, поднимаем на GPU-сервере в изолированном контуре, подключаем к нему простой HTTP-обёртку, и просим генерировать черновики Ansible-плейбуков по текстовому описанию задачи. Инженер описывает что хочет сделать - модель отдаёт yaml, инженер его просматривает и правит.

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

GPU-сервер - стандартная машина с одной картой уровня A100 (или аналог, есть в парке у клиента), модель запущена через llama.cpp с квантизацией Q4_K_M, инференс работает приемлемо для интерактивного использования.

Первые наблюдения по качеству

Прогнали несколько десятков разных задач - от банального «установи nginx на группу web-серверов» до «настрой logrotate для всех сервисов в /etc/rsyslog.d/».

Простые задачи - хорошо. Установка пакетов, управление сервисами, создание пользователей, базовые шаблоны конфигов - модель пишет синтаксически корректный yaml, правильно использует модули apt/yum/dnf, не путает become с become_user. Для таких задач черновик реально ускоряет работу: не надо лезть в документацию за именами параметров, скелет готов.

Средняя сложность - переменно. Задачи с условиями, with_items, block/rescue - модель справляется, но стабильности нет. Иногда пишет чисто, иногда смешивает синтаксис loop и with_items в одном таске, что не работает. Иногда придумывает модули, которых не существует - ansible.builtin.template_vars какой-нибудь. Это не катастрофа, но требует внимательного ревью.

Сложные плейбуки с ролями - слабо. Когда задача требует понимания структуры roles/, defaults/, handlers/ - модель начинает галлюцинировать структуру каталогов и неправильно расставлять include_tasks. Здесь экономии времени нет, скорее наоборот.

Идемпотентность - красная зона. Это оказалось самым неприятным. Модель не всегда обеспечивает идемпотентность там, где это важно. Может написать shell-таск без creates/removes, который будет выполняться каждый раз. Или использовать command вместо модуля с встроенной идемпотентностью. Для продакшн-плейбуков это критично, и руками это надо проверять всегда.

Риски, которые надо держать в голове

Главный риск - доверие. Если инженер устал или торопится, он может запустить сгенерированный плейбук без нормального ревью. Yaml синтаксически корректный, ansible-lint может пройти, но логика будет неправильной.

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

Третий - версии модулей. CodeLlama обучена на данных до определённой даты, и знает синтаксис Ansible, который был актуален тогда. Deprecated-параметры иногда пролезают. ansible-lint с актуальными правилами это ловит, но только если не забыть прогнать.

Сравнение с облачными альтернативами

Ansible Lightspeed в Red Hat Ansible Automation Platform - очевидно более зрелый продукт, натренированный специально на Ansible-контент. По качеству он должен быть лучше нашего CodeLlama на общих весах. Но это облако, это Red Hat subscription, и это данные, которые уходят наружу - даже если Red Hat говорит, что не хранит запросы.

GitLab Duo - другой сценарий, больше про CI/CD и code review, чем про плейбуки. Интересно, но нерелевантно для нашей задачи прямо сейчас.

Локальная модель - хуже по качеству, но в контуре. Для клиентов с КИИ это часто единственный допустимый вариант вообще попробовать LLM в операциях.

Где мы сейчас

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

Следующий шаг - попробовать fine-tuning на нашем репозитории плейбуков, чтобы модель усвоила наши соглашения. Это требует времени и данных, но направление интересное.

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