Промты для Kubernetes и CI/CD в 2026: 15 сценариев, которые заменят дежурного SRE в 3 часа ночи
Ночной алерт в 03:14: CrashLoopBackOff на проде, падает payments-api. Ты открываешь ноутбук, тянешься к kubectl describe pod, потом к логам, потом к дашборду Grafana. Знакомо? По опыту команд, которые ведут on-call, до 40% времени дежурства уходит не на починку, а на сбор контекста: какие были последние деплои, что изменилось в манифестах, какие лимиты у подов, не упал ли нод-пул.
Эта подборка — не про «магию ИИ». Это рабочие промты, которые DevOps-инженеры реально используют в 2026 году, чтобы превратить хаотичный дебаг в структурированный разбор. Каждый сценарий ниже — с примером входа, ожидаемым результатом и объяснением, какую рутину он снимает. Все примеры используют настоящий синтаксис Kubernetes, Helm, Terraform, GitHub Actions и GitLab CI.
Важно понимать: LLM не имеет доступа к вашему кластеру. Промт работает как «второй мозг» — вы передаёте ему вывод команд и манифесты, а он структурирует гипотезы и предлагает следующие шаги. Ниже — 15 сценариев, отсортированных от ночного инцидента к плановой оптимизации.
1. Диагностика CrashLoopBackOff за один проход
Классика ночного дежурства: под рестартует, kubectl logs показывает обрывок ошибки, а describe — гору событий. Промт заставляет модель пройтись по чек-листу причин вместо гадания.
Промт:
Ты — SRE с 10-летним опытом. Ниже вывод `kubectl describe pod` и последние 50 строк логов.
Разбери инцидент по шагам:
1. Определи тип сбоя (OOMKilled, ConfigError, ImagePullBackOff, dependency timeout).
2. Укажи конкретную строку/событие как доказательство.
3. Предложи 3 гипотезы в порядке вероятности.
4. Для каждой — команду проверки (kubectl/exec) и фикс (правка манифеста).
Не предлагай перезапуск пода как решение, если причина не устранена.
Пример входа: события Back-off restarting failed container, лог connection refused 10.96.0.45:5432, Last State: Terminated, Reason: Error, Exit Code: 1.
Что снимает: вы больше не читаете логи в 3 часа ночи «глазами» — модель связывает Exit Code: 1 с недоступностью Postgres Service и подсказывает проверить kubectl get endpoints postgres. Экономия — десятки минут на сбор контекста.
2. Генерация Helm-чарта из требований
Ручное написание values.yaml и шаблонов с {{ .Values }} — источник опечаток с отступами (YAML-ад). Промт генерирует структуру чарта, а вы ревьюите.
Промт:
Сгенерируй Helm chart для stateless-сервиса на Go.
Требования: 3 реплики, liveness/readiness probes на /healthz,
HPA по CPU 70%, resources requests/limits, Service ClusterIP,
Ingress с TLS, ConfigMap для переменных окружения.
Верни структуру файлов и содержимое Chart.yaml, values.yaml, templates/deployment.yaml, templates/_helpers.tpl.
Используй apiVersion apps/v1 и корректные отступы YAML.
Результат: готовый скелет чарта с helm template-совместимым выводом. Инженер проверяет helm lint и helm template . | kubectl apply --dry-run=server -f -.
Что снимает: рутину копипасты между чартами. По оценкам команд, стандартизация чартов через шаблоны сокращает время онбординга нового сервиса с дней до часов.
3. Разбор алерта Prometheus и снижение шума
Alertmanager шлёт десятки уведомлений об одном и том же. Промт помогает разобрать expr правила и найти причину флаппинга.
Промт:
Вот правило Prometheus:
expr: (sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/ sum(rate(http_requests_total[5m])) by (service)) > 0.05
for: 2m
Алерт срабатывает ночью при низком трафике. Объясни, почему
отношение может флапать при малом числе запросов, и перепиши expr
с использованием min request rate (порог) и, при необходимости, `unless`.
Дай финальный вариант с комментариями.
Что снимает: вы получаете правило, устойчивое к low-traffic окнам, вместо ночных ложных страниц. Это прямая экономия дежурных часов.
4. GitHub Actions: сборка, тесты, деплой
Промт собирает пайплайн с кэшем и матрицей, а не «hello world» пример из документации.
Промт:
Напиши .github/workflows/ci.yml для Go-сервиса:
- триггеры: push в main, pull_request
- job build: setup-go с кэшем модулей, go vet, go test ./..., сборка бинарника
- job docker: сборка и пуш образа в GHCR только на push в main, тег = sha
- job deploy: needs docker, деплой через helm upgrade --install в staging
Используй actions/checkout@v4, actions/setup-go@v5, docker/build-push-action@v6.
Добавь concurrency, чтобы отменять устаревшие прогоны.
Что снимает: написание YAML с нуля и поиск актуальных версий actions. Вы ревьюите логику, а не синтаксис.
5. GitLab CI: stages, cache, rules
Промт:
Сгенерируй .gitlab-ci.yml со stages: build, test, deploy.
- build: docker build, кэш через cache:key:files и Docker layer cache
- test: параллельные job'ы unit и integration, artifacts: reports: junit
- deploy: rules — только на тег вида v*.*.*, environment: production, when: manual
Покажи, как вынести общие настройки в extends/.base.
Что снимает: разбор синтаксиса rules vs only/except и настройку кэша, которые чаще всего ломают пайплайны.
6. Terraform-модуль для VPC
Промт:
Напиши переиспользуемый Terraform-модуль (>= 1.6) для AWS VPC:
- переменные: cidr_block, azs (list), enable_nat_gateway (bool)
- ресурсы: aws_vpc, aws_subnet (public/private), aws_internet_gateway,
aws_nat_gateway + aws_eip, route tables и ассоциации
- outputs: vpc_id, public_subnet_ids, private_subnet_ids
Добавь валидацию CIDR через validation в variable. Прокомментируй,
почему NAT Gateway создаётся только если enable_nat_gateway = true.
Что снимает: написание повторяющегося кода и забытые ассоциации route table — типовую причину «нет интернета в приватной подсети».
7. Terraform plan: объясни изменения перед apply
Промт:
Ниже вывод `terraform plan`. Раздели изменения на:
- безопасные (in-place update)
- требующие внимания (replace, destroy)
Объясни, почему ресурс помечен `forces replacement`, и предложи способ
избежать простоя (например, create_before_destroy в lifecycle).
Не выполняй apply — только анализ.
Что снимает: риск случайного destroy продакшн-ресурса из-за незамеченного изменения атрибута.
8. Оптимизация Dockerfile
Связанный материал — промты для Docker, но здесь фокус на размер и кэш.
Промт:
Оптимизируй Dockerfile. Цель: уменьшить образ и ускорить сборку.
Текущий: node:20, COPY . ., RUN npm install, CMD node index.js.
Требования: multi-stage build, кэш зависимостей через COPY package*.json,
non-root USER, HEALTHCHECK, .dockerignore.
Сравни размер до/после (объясни, за счёт чего экономия).
Что снимает: «толстые» образы и медленные сборки. Multi-stage и правильный порядок слоёв — стандартная практика, описанная в официальной документации Docker.
9. HPA и ресурсы: подбор requests/limits
Промт:
Сервис потребляет ~200m CPU в покое и до 1.5 CPU под нагрузкой, память 256Mi стабильно.
Предложи requests/limits для Deployment и параметры HPA (targetCPUUtilizationPercentage).
Объясни связь между requests и работой HPA: почему без requests автоскейлинг не работает корректно.
Что снимает: неверные лимиты, из-за которых HPA не масштабирует или поды падают по OOM.
10. Разбор логов в формате JSON
Промт:
Вот 30 строк JSON-логов сервиса. Найди паттерн ошибок, сгруппируй по полю `error.type`,
посчитай частоту, укажи первый и последний таймстамп каждой группы.
Предложи, какие метрики добавить, чтобы ловить это алертом, а не по логам.
Что снимает: ручной grep. Модель агрегирует и подсказывает переход от логов к метрикам (observability best practice).
11. NetworkPolicy: разрешить только нужный трафик
Промт:
Напиши NetworkPolicy (networking.k8s.io/v1) для namespace `payments`:
разрешить ingress только от namespace `frontend` на порт 8080,
разрешить egress к `kube-system` DNS (порт 53) и к базе в namespace `data` (5432).
По умолчанию запретить всё остальное. Поясни, как проверить политику.
Что снимает: ошибки в селекторах podSelector/namespaceSelector, из-за которых сервис внезапно теряет связь.
12. RBAC: минимальные права для CI-сервисаккаунта
Промт:
Создай ServiceAccount, Role и RoleBinding для CI, которому нужно только
обновлять Deployment в namespace `staging`. Принцип наименьших привилегий.
Покажи, какие verbs и resources необходимы, и почему `*` — плохая идея.
Что снимает: избыточные права CI-токенов — типовую находку аудитов безопасности.
13. Дебаг ImagePullBackOff и приватных registry
Промт:
Под в статусе ImagePullBackOff. Объясни пошаговый чек-лист:
имя образа и тег, imagePullSecrets, права service account, доступность registry из нод,
размер образа и rate limits.
Для каждого пункта — конкретная команда проверки.
Что снимает: цикл «пересоздал секрет — не помогло». Структурированный чек-лист вместо перебора.
14. Снижение стоимости кластера
Промт:
Вот список workloads с requests/limits и текущая утилизация нод.
Предложи план снижения стоимости: rightsizing requests, Cluster Autoscaler /
Karpenter, spot-ноды для stateless, удаление idle-ресурсов.
Для каждого шага укажи риск и способ отката.
Что снимает: переплату за неиспользуемые ресурсы. Rightsizing — самый частый быстрый выигрыш без изменения архитектуры.
15. Postmortem после инцидента
Промт:
Составь blameless postmortem по инциденту. Данные: таймлайн из логов и алертов,
затронутые сервисы, время детекта и восстановления.
Структура: summary, impact, timeline, root cause (5 Whys), action items
с owner и приоритетом. Тон — без обвинений, фокус на системных причинах.
Что снимает: часы на написание документа после ночного дежурства. Вы получаете черновик, который остаётся дополнить фактами.
Как использовать это на практике
| Сценарий | Когда применять | Что экономит |
|---|---|---|
| Диагностика подов | Ночной алерт | Время сбора контекста |
| Helm / Terraform генерация | Новый сервис, модуль | Копипасту и отступы |
| CI/CD пайплайны | Настройка репозитория | Поиск версий actions |
| Prometheus / логи | Флаппинг алертов | Ложные страницы |
| Оптимизация (Docker, HPA, cost) | Плановые ревью | Ресурсы и деньги |
Ключевое правило: модель не заменяет ваши инструменты, а ускоряет мышление. Всегда проверяйте вывод командами kubectl --dry-run, terraform plan, helm template и actionlint. Документацию по Kubernetes, Helm, Terraform и провайдерам стоит сверять в первоисточниках — официальных доках проектов.
Если хотите глубже — изучите официальные best practices по Kubernetes, Terraform и GitHub Actions. Промты — лишь ускоритель поверх фундаментальных знаний. Начните с одного сценария сегодня: возьмите пункт про CrashLoopBackOff и прогоните его на следующем дежурстве. Через неделю добавите Helm, через месяц — cost-оптимизацию. Так рутина дежурства постепенно превращается в набор отработанных реакций.
Comments