Промпт-інжиніринг для 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 і ніколи нічого не видаляє автоматично».

З чого почати

Промпт-інжиніринг — не магія. Це та сама точність, що потрібна для доброго тікета чи зрозумілого ранбука. Почніть із малого, зберігайте промпти, які спрацювали, і використовуйте їх повторно. Поводьтеся з ними як із кодом, бо зараз вони ним, по суті, і є.