Промпт-инжиниринг для DevOps: чек-лист C.L.E.A.R. и библиотека промптов

Промпт-инжиниринг кажется модным словечком ровно до того момента, когда небрежно заданный вопрос съедает час работы. Если ИИ стал частью ежедневной работы с инфраструктурой, на расплывчатый промпт приходит такой же расплывчатый ответ. Иногда ещё и неверный, а в DevOps неверный ответ может обернуться сломанным пайплайном или разрушительной командой kubectl.

Решение простое: относиться к промптам как к коду. Версионировать, тестировать, переиспользовать. Ниже разберём, как это выглядит на примерах из обычной ops-работы.

Почему это важно для эксплуатации

Стихов от модели никто не ждёт. Типичные запросы выглядят так:

• понять, почему падает Terraform plan
• написать bash-скрипт, который не снесёт прод
• ужать 10 000 строк логов до десяти пунктов
• расшифровать невнятную ошибку Kubernetes
• сгенерировать YAML, который пройдёт валидацию

Принцип «мусор на входе — мусор на выходе» работает для промптов так же, как для данных. Умение написать хороший промпт сегодня такой же базовый навык, как знание grep или awk.

Ошибка, которую делают почти все

Обычный промпт звучит примерно как «Почини мою ошибку в Terraform». Ответ приходит общий и бесполезный, и удивляться тут нечему: модель не знает,

• о каком облаке речь (AWS, GCP или Azure)
• что именно написано в сообщении об ошибке
• какая версия Terraform запущена
• что уже пробовали сделать

Без контекста полезного ответа не будет. Всё действительно настолько просто.

Чек-лист, который легко запомнить: C.L.E.A.R.

Пять пунктов покрывают почти любой хороший промпт.

C — Context, контекст. Опишите окружение, например боевой кластер EKS в AWS.

L — Limitations, ограничения. Назовите рамки, скажем stateful-под, который нельзя перезапускать.

E — Expected output, ожидаемый результат. Скажите, в каком виде нужен ответ: например, исправление в одну строку, а не полная переделка.

A — Actual error or data, реальная ошибка или данные. Вставьте настоящий лог или текст ошибки.

R — Role, роль. Попросите модель отвечать как старший SRE на ревью.

Каждый из пяти пунктов стоит разобрать подробнее.

1. Контекст

Слабый вариант: «Почему падает мой под?»

Сильный вариант: под на Node.js в GKE три месяца работал без проблем и ушёл в crash loop сразу после вчерашнего изменения ConfigMap.

Теперь модель знает платформу, тип приложения и вероятную причину. Разница в качестве между этими двумя промптами огромная.

2. Ограничения

Модель не угадает ваши ограничения. Их нужно проговорить явно, например: предложи исправление, но основной узел базы данных нельзя перезапускать в рабочее время.

Если этого не сказать, в ответе, скорее всего, появится небрежное «просто перезапустите». На проде ничего небрежного в этом нет.

3. Ожидаемый результат

Назовите нужный формат. Одна эта привычка заметно сокращает переписку туда-обратно. Несколько полезных просьб о формате:

• только bash-команда, без комментариев
• ответ в виде таблицы
• блок YAML и больше ничего
• коротко, для человека, который дебажит в два часа ночи

4. Реальная ошибка или данные

Этот пункт пропускают чаще всего. Вставляйте то, что есть на самом деле.

Слабый вариант: «У меня падает CI-пайплайн».

Сильный вариант: точный вывод ошибки из джобы.

Код выхода 137 обычно означает, что процесс убили из-за нехватки памяти. Модель заметит это, только если перед ней настоящая ошибка.

5. Роль

Роль меняет и тон, и глубину ответа. Сравните просьбу ответить как старший SRE с десятилетним опытом в Kubernetes и просьбу объяснить новичку. Вопрос тот же, а ответы сильно различаются, и в разные дни нужным может оказаться любой из них.

Промпты, которым место в файле со сниппетами

Некоторые промпты стоит сохранить, как только они заработали.

Отладка Terraform. Задайте роль старшего DevOps-инженера, вставьте ошибку plan, укажите провайдера (AWS) и версию Terraform (1.7) и попросите назвать первопричину одной строкой, а затем дать исправление.

Безопасные скрипты автоматизации. Попросите bash-скрипт, который удаляет Docker-образы старше семи дней. Потребуйте, чтобы по умолчанию он работал в режиме dry-run и ничего не удалял без подтверждения.

Сводки по логам. Отдайте логи Nginx и попросите пять самых частых кодов ошибок, самые нагруженные эндпоинты и подозрительные паттерны IP — всё меньше чем в 100 словах.

Постмортемы инцидентов. Дайте сырые заметки по инциденту и попросите аккуратный документ с разделами Summary, Timeline, Root Cause и Action Items.

Привычки, которые выходят боком

Несколько шаблонов стабильно дают плохой результат:

• впихивать пять несвязанных проблем в один вопрос
• не указывать стек, хотя Terraform, CloudFormation и Pulumi дают совсем разные ответы
• принимать первый ответ за чистую монету, ни разу не спросив «почему»
• забывать упомянуть, что окружение боевое, когда оно боевое
• вставлять вывод модели прямо в прод без ревью

Последняя привычка заслуживает отдельного предупреждения. ИИ — второй пилот, а командир экипажа по-прежнему человек.

Своя библиотека промптов

У команд и так есть библиотеки скриптов и ранбуки, и библиотека промптов отлично встаёт рядом с ними. Простая структура:

/prompts
  ├── terraform-debug.md
  ├── log-summary.md
  ├── incident-postmortem.md
  ├── yaml-validator.md
  └── cost-report-summary.md

В каждом файле лежит переиспользуемый шаблон, поля-заглушки вроде [ERROR], [STACK] и [ENV] и короткая заметка о том, когда его применять. Так написание промптов превращается из набора наугад в выбор подходящего инструмента — так же, как вы берёте нужный скрипт из папки.

Слабый и сильный вариант рядом

Падение CI

• Слабо: «CI сломался, помогите»
• Сильно: «GitHub Actions падает на шаге docker build с кодом выхода 137, вероятно, не хватает памяти. Предложи, как поправить память раннера».

Проблема в Kubernetes

• Слабо: «Под постоянно падает»
• Сильно: «Под на Node.js в GKE со вчерашнего изменения ConfigMap уходит в crash loop. В логах OOMKilled. Предложи, как поправить лимиты ресурсов».

Запрос скрипта

• Слабо: «Напиши скрипт очистки»
• Сильно: «Напиши bash-скрипт, который удаляет Docker-образы старше семи дней, поддерживает флаг dry-run и никогда не удаляет ничего автоматически».

С чего начать

Промпт-инжиниринг — не магия. Это та же точность, что нужна для хорошего тикета или понятного ранбука. Начните с малого, сохраняйте промпты, которые сработали, и используйте их повторно. Обращайтесь с ними как с кодом, потому что сейчас они им, по сути, и являются.