Почему инфраструктурные промты — это не «магия», а инструмент дисциплины
Kubernetes, Terraform и пайплайны CI/CD ломаются не от «плохого YAML», а от нехватки контекста: кто-то забыл resource limits, кто-то не выставил prevent_destroy, кто-то запушил секрет в репозиторий. LLM не заменит kubectl, но может стать «второй парой глаз», если давать ей точные, ограниченные задачи.
Ниже — 10 готовых промтов, которые я использую как шпаргалку. Каждый сформулирован так, чтобы модель не фантазировала: мы явно задаём входные данные, формат ответа и границы. Синтаксис Kubernetes и Terraform проверяйте по официальной документации (kubernetes.io/docs, developer.hashicorp.com/terraform) — модель может ошибаться в деталях, но с правильным промтом ошибок становится на порядок меньше.
1. Аудит манифеста Deployment перед мержем
Задача: поймать отсутствующие probes, limits и стратегию обновления до ревью.
Промт:
Ты — SRE-ревьюер Kubernetes. Проверь манифест Deployment ниже по чек-листу:
1) liveness/readiness/startup probes; 2) resources.requests/limits;
3) securityContext (runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation);
4) strategy и maxUnavailable; 5) корректность image tag (не latest).
Для каждого пункта: PASS/FAIL + конкретная строка YAML с исправлением.
Не придумывай поля, которых нет в API apps/v1.
Манифест:
<вставь YAML>
Пример: после такого прогона на манифесте с image: nginx:latest и без resources модель вернула три FAIL и готовые патчи. Время ревью упало с 15 минут до 2.
2. Диагностика CrashLoopBackOff по логам и событиям
Задача: превратить сырой вывод kubectl describe и логи в гипотезы.
Промт:
Ниже — вывод `kubectl describe pod` и последние 100 строк логов.
Составь таблицу:
| гипотеза | доказательство в данных | проверочная команда |.
Отсортируй по вероятности. Не предлагай действий, не подтверждённых выводом.
Если данных не хватает — явно перечисли, какие команды запустить.
Данные:
<вставь вывод>
Пример: в одном сервисе проблема оказалась в OOMKilled — модель заметила Last State: Terminated, Reason: OOMKilled в описании, хотя в логах было тихо. Проверочная команда kubectl top pod подтвердила.
3. Генерация NetworkPolicy из описания трафика
Задача: не писать «разрешить всё» из лени.
Промт:
Сгенерируй NetworkPolicy для namespace prod по описанию:
- frontend -> backend: TCP 8080
- backend -> postgres: TCP 5432
- всё остальное запрещено
Формат: apiVersion networking.k8s.io/v1, default-deny + разрешающие политики.
Добавь комментарии, объясняющие селекторы. Не используй несуществующие поля.
Пример: получили три политики (default-deny + две разрешающие). После kubectl apply --dry-run=server — без ошибок валидации.
4. Ревью Terraform-плана на разрушительные изменения
Задача: не удалить базу случайно.
Промт:
Вот вывод `terraform plan`. Найди все действия destroy и replace.
Для каждого ресурса: тип, имя, причина замены (атрибут из Forces replacement).
Отметь ресурсы с stateful-данными (БД, диски, бакеты) и предложи либо lifecycle.prevent_destroy, либо план миграции.
Вывод плана:
<вставь plan>
Пример: модель поймала replace у aws_db_instance из-за смены engine_version — это классический сценарий простоя. Добавили lifecycle { prevent_destroy = true } и прошли через blue-green.
5. Разбор ошибки Terraform state lock
Задача: быстро понять, кто держит лок и что делать.
Промт:
Ошибка: «Error acquiring the state lock». Объясни причину и дай пошаговый безопасный план:
1) как проверить, жив ли процесс; 2) когда `force-unlock` допустим, а когда нет;
3) как настроить DynamoDB-локинг для S3-бэкенда.
Дай команды с пояснениями. Не советуй force-unlock первым шагом.
Пример: в команде лок «завис» после падения CI-раннера. Промт помог аккуратно проверить Lock Info (LockID, Who) и снять лок только после подтверждения, что пайплайн мёртв.
6. Оптимизация Dockerfile под кэш слоёв
Задача: ускорить сборки без потери безопасности.
Промт:
Перепиши Dockerfile: multi-stage, кэширование зависимостей, non-root user, фиксированные версии базовых образов.
Покажи diff и объясни, какие слои теперь кэшируются.
Не добавляй секретов в образ. Предложи .dockerignore.
Dockerfile:
<вставь файл>
Пример: перенос COPY package*.json перед COPY . . сократил пересборку при изменении кода с ~3 минут до секунд на кэше.
7. Сканер секретов в диффе перед коммитом
Задача: не дать утечь ключам.
Промт:
Проверь git diff на секреты: API-ключи, токены, приватные ключи, пароли, connection strings.
Для каждой находки: файл, строка, тип секрета, рекомендация (удалить из истории, ротация, pre-commit hook).
Не пересказывай сам секрет целиком.
Diff:
<вставь diff>
Пример: модель нашла AWS_SECRET_ACCESS_KEY в .env.example. Рекомендация — ротация ключа и добавление gitleaks в pre-commit.
8. Генерация GitHub Actions workflow с кэшем и матрицей
Задача: собрать пайплайн, который не пересобирает всё каждый раз.
Промт:
Сгенерируй GitHub Actions workflow для Go-сервиса:
- триггеры: push в main, PR;
- матрица go 1.22/1.23;
- кэш модулей и build-кэш;
- шаги: lint, test, build образа, push только на main.
Используй actions/checkout@v4, actions/setup-go@v5, actions/cache@v4.
Прокомментируй каждый шаг. Не выдумывай несуществующие action'ы.
Пример: сгенерированный workflow прошёл валидацию через actionlint; push образа ограничили условием if: github.ref == 'refs/heads/main'.
9. Промт для Helm values: проверка на «тихие» дефолты
Задача: найти значения, которые переопределяют чарт неожиданно.
Промт:
Сравни values.yaml с дефолтами чарта (приведены ниже). Найди ключи, которые:
1) переопределяют securityContext; 2) отключают probes; 3) задают огромные requests;
4) меняют image tag на нестабильный.
Выведи таблицу
| ключ | значение | риск | рекомендация |.
Values и дефолты:
<вставь>
Пример: обнаружили resources.requests.memory: 8Gi — сервис просил в 8 раз больше нужного, из-за чего pod'ы не планировались на нодах.
10. Постмортем по инциденту из таймлайна
Задача: превратить хаос чатов и алертов в структурированный разбор.
Промт:
Ниже — таймлайн инцидента (алерты, действия, время).
Составь постмортем: 1) impact; 2) timeline; 3) root cause (с доказательствами);
4) что сработало; 5) action items с owner и приоритетом.
Не придумывай факты, отсутствующие в таймлайне. Помечай предположения как «гипотеза».
Таймлайн:
<вставь>
Пример: из 40 сообщений в чате модель собрала чёткий таймлайн и три action item, включая «добавить alert на p99 latency для checkout».
Как не превратить промты в новый источник риска
Три правила, которые я выработал: (1) всегда давайте модели реальные данные — YAML, plan, diff, логи; (2) требуйте формат ответа и явную пометку «гипотеза», если данных мало; (3) проверяйте результат валидаторами — kubectl apply --dry-run=server, terraform validate, actionlint, hadolint. LLM ускоряет ревью и диагностику, но последнее слово остаётся за инструментами и человеком.
Начните с одного промта — аудита Deployment или ревью terraform plan — и встройте его в чек-лист перед мержем. Через пару спринтов вы заметите, что дежурные ночи становятся скучнее, а инциденты — короче.
Комментарии