Инфраструктура ломается не по расписанию. Ошибка в Dockerfile всплывает в 3 часа ночи, поды в Kubernetes уходят в CrashLoopBackOff прямо перед демо, а пайплайн падает на шаге деплоя из-за забытого секрета. И в эти моменты меньше всего хочется гуглить синтаксис kubectl describe или вспоминать, как правильно написать restartPolicy. Именно здесь LLM превращается из игрушки в полноценного напарника: он не «думает за вас», но генерирует рабочие конфиги, объясняет ошибки и предлагает варианты, которые вы проверяете одной командой.
Ниже — 12 проверенных промтов, которые реально экономят время DevOps-инженеру и разработчику. Каждый — готов к копипасту, с пояснением задачи и примером. Важно: всегда валидируйте вывод (docker build, kubectl apply --dry-run=server, terraform plan) перед применением в проде. LLM ошибается, но ошибается быстро — а это уже половина победы.
1. Ревью Dockerfile и оптимизация образа
Задача: уменьшить размер образа и убрать типичные ошибки (запуск от root, лишние слои, отсутствие .dockerignore).
Промт:
Ты — Senior DevOps-инженер. Проверь мой Dockerfile по чек-листу: (1) multi-stage build, (2) запуск от non-root, (3) минимальный базовый образ, (4) кэширование слоёв, (5) отсутствие секретов в слоях, (6) healthcheck. Для каждой проблемы дай строку «было → стало» и объясни в одном предложении, почему это важно. В конце предложи .dockerignore.
Dockerfile:
[вставьте свой Dockerfile]
Пример: для Python-сервиса на python:3.12 промт предложит перейти на python:3.12-slim, добавить USER app, вынести pip install перед COPY . . для кэша и `HEALTHCHECK CMD curl -f http://localhost:8000/health
|| exit 1. Проверка:docker build -t app . && docker images | grep app`.
2. Диагностика падающего пода в Kubernetes
Задача: быстро разобрать CrashLoopBackOff, OOMKilled или ImagePullBackOff.
Промт:
Под в Kubernetes в состоянии [состояние, например CrashLoopBackOff]. Вот вывод `kubectl describe pod` и последние 50 строк `kubectl logs --previous`:
[вставьте вывод]
Дай: (1) три наиболее вероятные причины в порядке убывания, (2) конкретные команды для проверки каждой, (3) что поменять в манифесте. Не предлагай перезапускать кластер.
Пример: для OOMKilled промт укажет на несоответствие resources.limits.memory и реального потребления, предложит kubectl top pod и правку limits. Это быстрее, чем читать документацию по 20 разделам.
3. Генерация манифеста Deployment + Service + Ingress
Задача: собрать связку с нуля под конкретные требования.
Промт:
Сгенерируй Kubernetes-манифесты (Deployment, Service, Ingress) для приложения:
- образ: [registry/image:tag]
- порт контейнера: [порт]
- 3 реплики, rolling update maxSurge=1 maxUnavailable=0
- requests/limits: CPU [x], RAM [y]
- liveness и readiness probes на /health
- Ingress с TLS через cert-manager (cluster-issuer: letsencrypt-prod)
Верни один YAML с разделителями --- и комментариями к ключевым полям.
Пример: один ответ даёт готовый набор, который проходит kubectl apply --dry-run=server -f app.yaml без правок.
4. Дебаг пайплайна GitHub Actions / GitLab CI
Задача: найти причину падения джобы по логу.
Промт:
Мой CI-пайплайн упал. Вот конфиг и лог ошибки:
[конфиг]
[лог]
Объясни ошибку простыми словами, укажи строку конфига, которую надо исправить, и дай исправленный фрагмент. Если проблема в кэше или секретах — покажи, как это проверить.
Пример: частая ошибка permission denied при docker push решается добавлением permissions: packages: write или логином в registry — промт покажет оба варианта.
5. Terraform: ревью и поиск дрейфа
Задача: проверить конфиг на антипаттерны до terraform apply.
Промт:
Ты — эксперт по Terraform. Проверь конфиг на: (1) отсутствие remote state, (2) hardcoded секреты, (3) отсутствие version pinning у провайдеров, (4) ресурсы без lifecycle, (5) потенциальный дрейф. Дай diff-предложения и объясни риск каждого пункта.
[вставьте main.tf]
Пример: промт укажет на provider "aws" {} без version = "~> 5.0" и предложит бэкенд на S3 + DynamoDB для блокировок. Проверка — terraform validate и terraform plan.
6. Написание Helm-чарта с параметрами
Задача: превратить набор манифестов в переиспользуемый чарт.
Промт:
Создай структуру Helm-чарта для приложения [название]. Нужны: values.yaml с параметрами (image, replicas, resources, ingress), шаблоны deployment.yaml, service.yaml, ingress.yaml, _helpers.tpl. Используй правильные конструкции {{ .Values.* }} и {{ include }}. Верни дерево файлов и содержимое каждого.
Пример: результат проходит helm lint и helm template . без ошибок.
7. Политика безопасности и сканирование образов
Задача: внедрить проверки в пайплайн.
Промт:
Предложи шаг CI для сканирования Docker-образа через Trivy и блокировки сборки при CRITICAL-уязвимостях. Дай YAML-шаг для GitHub Actions, объясни флаги и как настроить исключения (.trivyignore).
Пример: шаг с trivy image --exit-code 1 --severity CRITICAL $IMAGE останавливает пайплайн до деплоя.
8. Объяснение сложной ошибки «на пальцах»
Задача: разобраться в незнакомой ошибке без часов чтения.
Промт:
Объясни ошибку так, будто я мидл-разработчик, но не инфраструктурщик. Разбей на: что произошло, почему, как чинить, как предотвратить. Ошибка:
[текст ошибки]
Пример: context deadline exceeded в Kubernetes часто означает сетевую проблему или зависший webhook — промт разложит по шагам проверки.
9. Генерация скрипта бэкапа и восстановления
Задача: автоматизировать бэкапы state и данных.
Промт:
Напиши bash-скрипт для бэкапа Kubernetes-кластера: etcd snapshot, дампы PVC через velero, ротация 7 дней, логирование. Добавь обработку ошибок (set -euo pipefail) и проверку свободного места. Прокомментируй каждую строку.
Пример: скрипт запускается по cron и логирует статус в /var/log/backup.log.
10. Аудит CI/CD на узкие места
Задача: ускорить пайплайн.
Промт:
Проанализируй мой CI-пайплайн и найди узкие места: последовательные шаги, которые можно параллелить, лишние сборки, отсутствие кэша зависимостей. Дай план оптимизации с ожидаемым эффектом.
[вставьте конфиг]
Пример: промт предложит матричную стратегию для тестов и actions/cache для pip/npm.
11. Сравнение инструментов под задачу
Задача: выбрать стек обоснованно.
Промт:
Сравни [инструмент A] и [инструмент B] для задачи [описание]. Дай таблицу: критерий, A, B. Учти: сложность внедрения, стоимость, поддержка сообщества, совместимость с Kubernetes. В конце — рекомендация под мой контекст: [команда, масштаб, бюджет].
Пример: сравнение Argo CD и Flux CD по модели pull/push, UI и порогу входа.
12. Постмортем инцидента
Задача: превратить факап в документ и предотвратить повтор.
Промт:
Составь постмортем по инциденту. Данные: [что случилось, таймлайн, затронутые сервисы, как починили]. Формат: краткое резюме, таймлайн, root cause, влияние, что сработало, action items с owner и дедлайном. Без обвинений, фокус на процессах.
Пример: готовый шаблон в Markdown для Confluence или Notion.
| Промт | Когда использовать | Что проверять |
|---|---|---|
| Ревью Dockerfile | Перед мержем | docker build |
| Дебаг пода | Инцидент | kubectl describe |
| Манифесты | Новый сервис | --dry-run=server |
| CI-дебаг | Пайплайн упал | Локальный прогон |
| Terraform | Перед apply | terraform plan |
| Helm | Рефакторинг | helm lint |
| Trivy | Безопасность | --exit-code 1 |
| Бэкапы | Регулярно | Тестовое восстановление |
Ключевое правило: LLM — это ускоритель, а не источник истины. Он генерирует черновик за секунды, но финальное слово за вами и за plan/dry-run. Начните с двух-трёх промтов из списка — например, ревью Dockerfile и дебага пода — и вы заметите, что рутины становится меньше, а времени на архитектуру больше. Сохраните подборку в закладки и адаптируйте формулировки под свой стек: чем конкретнее входные данные, тем полезнее ответ.
Комментарии