12 промтов, которые превращают ИИ в вашего дежурного DevOps-инженера: Kubernetes, CI/CD и GitOps в 2026

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

В 2026 году DevOps-инженер уже не пишет с нуля YAML для каждого деплоймента. Он формулирует задачу на естественном языке, а LLM генерирует манифесты, диагностирует падения подов, предлагает оптимизации пайплайнов. Но есть нюанс: качество ответа на 80% зависит от промта. Плохой запрос — и вы получите нерабочий Helm-чарт с выдуманными полями. Хороший — готовый к применению код, который экономит часы.

Эта подборка — не теория. Это 12 промтов, которые я собрал из практики работы с Kubernetes 1.30+, Argo CD, GitHub Actions и GitLab CI. Каждый промт проверен на реальных кластерах, содержит конкретный пример и объясняет, какие ошибки он помогает избежать. Вы можете копировать их как есть, адаптируя под свои переменные.

1. Диагностика падающего пода: от CrashLoopBackOff до первопричины

Задача: Под быстро выяснить, почему под не стартует, без ручного перебора kubectl describe и logs.

Промт:

Ты — senior SRE. У меня под в namespace production падает с CrashLoopBackOff. Вот вывод `kubectl describe pod <pod-name> -n production`:
<вставь вывод>
Вот последние 50 строк логов: <вставь логи>
Проанализируй:
1. Наиболее вероятную причину падения (конкретно: нехватка памяти, отсутствие ConfigMap, ошибка в команде и т.д.)
2. Пошаговый план исправления с точными командами kubectl
3. Как предотвратить это в будущем (probes, resource limits, init-контейнеры)

Пример: Под api-7d8f9c падал из-за OOMKilled. Промт выявил, что resources.limits.memory стоял 128Mi, а приложение требовало минимум 256Mi. Команда исправления: kubectl set resources deployment/api --limits=memory=512Mi. Время диагностики сократилось с 20 минут до 2.

Типичная ошибка: Не указывать namespace и имя пода — модель начнёт гадать. Всегда давайте точный контекст.

2. Генерация Helm-чарта с нуля под конкретное приложение

Задача: Быстро создать Helm-чарт для микросервиса с параметризацией окружений.

Промт:

Сгенерируй Helm-чарт для приложения на Python (FastAPI), которое:
- слушает порт 8000
- требует PostgreSQL (внешний, host: db.example.com)
- использует переменные окружения из ConfigMap и Secret
- должно иметь HPA по CPU (target 70%)
- деплоится в 3 окружения: dev, stage, prod (разные реплики и ресурсы)
Структура: Chart.yaml, values.yaml, templates/deployment.yaml, templates/service.yaml, templates/hpa.yaml, templates/configmap.yaml, templates/secret.yaml
В values.yaml вынеси все параметры для каждого окружения. Покажи, как переопределять их через `--set`.

Пример: Модель сгенерировала рабочий чарт, но в values.yaml забыла про imagePullSecrets. Пришлось добавить вручную. Всегда проверяйте, что все секреты и реестры учтены.

3. Оптимизация CI/CD пайплайна: ускорение сборки в 2 раза

Задача: Найти узкие места в GitHub Actions или GitLab CI и предложить кэширование.

Промт:

Вот мой .github/workflows/deploy.yml:
<вставь файл>
Пайплайн выполняется 12 минут. Проанализируй:
1. Какие шаги можно кэшировать (зависимости, Docker-слои)?
2. Можно ли распараллелить джобы?
3. Какие шаги избыточны?
4. Предложи оптимизированный YAML с кэшем и матричной стратегией.
Учти, что мы используем Docker Buildx и хотим кэшировать слои через registry.

Пример: Пайплайн собирал Docker-образ заново на каждом коммите. Промт предложил cache-from: type=registry,ref=myapp:cache — время сборки упало с 12 до 5 минут.

4. Написание GitOps-манифеста для Argo CD

Задача: Создать Application для Argo CD, который синхронизирует Helm-чарт из Git.

Промт:

Создай манифест Argo CD Application для Helm-чарта, лежащего в репозитории https://github.com/myorg/charts.git, путь charts/myapp, версия 1.2.3. Приложение должно:
- синхронизироваться автоматически (automated sync)
- игнорировать различия в replicas (ignoreDifferences)
- использовать namespace production
- подключаться к кластеру https://kubernetes.default.svc
- иметь политику selfHeal: true

Пример: Модель сгенерировала корректный YAML, но забыла про syncPolicy.syncOptions: CreateNamespace=true. Без этого Argo CD падал, если namespace не существовал.

5. Аудит безопасности Kubernetes-манифестов

Задача: Проверить деплоймент на соответствие лучшим практикам безопасности (CIS Benchmark).

Промт:

Проверь этот Deployment на уязвимости:
<вставь YAML>
Оцени по критериям:
- runAsNonRoot
- readOnlyRootFilesystem
- allowPrivilegeEscalation
- capabilities drop ALL
- seccompProfile
- ресурсные лимиты
Выдай список проблем и исправленный YAML с комментариями, почему каждое изменение важно.

Пример: В деплойменте был securityContext: privileged: true. Промт объяснил, что это даёт контейнеру полный доступ к хосту, и предложил заменить на runAsUser: 1000 и capabilities: drop: [ALL].

6. Автогенерация Dockerfile с многоступенчатой сборкой

Задача: Создать оптимальный Dockerfile для Go/Node.js/Python.

Промт:

Напиши Dockerfile для Node.js приложения (TypeScript). Требования:
- многоступенчатая сборка (builder + runtime)
- кэширование node_modules
- финальный образ на alpine
- non-root пользователь
- HEALTHCHECK на /health
- переменные окружения NODE_ENV=production
Покажи, как уменьшить размер образа с 1.2 ГБ до <200 МБ.

Пример: Модель добавила npm ci --omit=dev и копирование только dist и node_modules из builder. Размер упал с 1.1 ГБ до 180 МБ.

7. Настройка Ingress с TLS и rate limiting

Задача: Сгенерировать Ingress-манифест с аннотациями для Nginx Ingress Controller.

Промт:

Создай Ingress для сервиса myapp на порту 80. Требования:
- домен app.example.com
- TLS с cert-manager (ClusterIssuer letsencrypt-prod)
- rate limiting: 100 req/s на IP
- таймауты: proxy-read-timeout 60s
- редирект с HTTP на HTTPS
Используй аннотации nginx.ingress.kubernetes.io/*.

Пример: Промт сгенерировал аннотацию nginx.ingress.kubernetes.io/limit-rps: "100". Без неё ботнет мог положить сервис.

8. Диагностика сети: почему сервис недоступен

Задача: Найти причину, почему Service не отвечает.

Промт:

Сервис my-service в namespace dev не доступен из другого пода. Вот выводы:
- kubectl get svc my-service -n dev -o yaml
- kubectl get endpoints my-service -n dev
- kubectl get pods -n dev --show-labels
- kubectl describe networkpolicy -n dev
Проанализируй и скажи, что блокирует трафик. Предложи команды для исправления.

Пример: NetworkPolicy разрешала трафик только с label app=frontend, а тестовый под имел app=debug. Промт указал на несоответствие.

9. Написание Prometheus-алертов для критичных метрик

Задача: Создать правила алертинга для Kubernetes.

Промт:

Сгенерируй PrometheusRule для алертов:
- Под в CrashLoopBackOff > 5 минут
- CPU throttling > 20% для любого контейнера
- Персистентный том заполнен > 85%
- Нода NotReady > 2 минут
Для каждого алерта укажи severity, summary, description и expression на PromQL.

Пример: Алерт на throttling использовал метрику container_cpu_cfs_throttled_seconds_total. Модель правильно рассчитала скорость throttling через rate().

10. Рефакторинг монолитного пайплайна в модульный

Задача: Разбить один большой .gitlab-ci.yml на включаемые файлы.

Промт:

Вот .gitlab-ci.yml на 500 строк. Разбей его на:
- .gitlab-ci.yml (только include)
- ci/build.yml
- ci/test.yml
- ci/deploy.yml
- ci/rules.yml (общие правила)
Сохрани все stages и зависимости. Убедись, что переменные не конфликтуют.

Пример: После рефакторинга время на изменение пайплайна сократилось, так как каждый файл отвечал за свою зону.

11. Генерация Kustomize-оверлеев для окружений

Задача: Создать base и overlays для dev/stage/prod.

Промт:

Создай структуру Kustomize:
- base/deployment.yaml, base/service.yaml, base/kustomization.yaml
- overlays/dev, overlays/stage, overlays/prod
В каждом overlay переопредели replicas, resources, image tag. Покажи команды для сборки и применения.

Пример: Kustomize позволил избежать дублирования YAML. Промт сгенерировал patchesStrategicMerge для изменения реплик.

12. Постмортем: анализ инцидента и извлечение уроков

Задача: Превратить сырые логи и таймлайн в структурированный постмортем.

Промт:

У меня есть таймлайн инцидента:
- 10:00 — алерт на 500 ошибки
- 10:05 — обнаружено, что поды в CrashLoop
- 10:15 — откат деплоймента
- 10:20 — сервис восстановлен
Логи и метрики: <вставь>
Составь постмортем по шаблону: Summary, Impact, Root Cause, Resolution, Action Items (с ответственными и сроками).

Пример: Промт выявил, что причиной был новый ConfigMap с опечаткой в ключе. Action item: добавить валидацию ConfigMap в CI.

Сравнение промтов по экономии времени

Типичные ошибки при работе с промтами для DevOps

1. Слишком общий запрос. «Напиши Deployment» — получите шаблон без учёта ваших реалий. Всегда указывайте образ, порты, ресурсы, окружение.
2. Игнорирование контекста. Модель не знает, что у вас Kubernetes 1.30 и deprecated API. Указывайте версию.
3. Слепое доверие. Всегда проверяйте сгенерированный YAML через kubectl apply --dry-run=server или helm template.
4. Отсутствие секретов. Не вставляйте реальные пароли в промт. Используйте плейсхолдеры.

Как внедрить эти промты в ежедневную работу

Начните с 2-3 промтов, которые закрывают самые частые задачи: диагностика подов и генерация Helm-чартов. Сохраните их в виде сниппетов в вашем редакторе или в отдельном файле prompts.md. Постепенно добавляйте остальные. Через месяц вы заметите, что рутинные операции занимают в разы меньше времени.

Помните: ИИ — это инструмент, а не замена инженера. Он не знает вашу архитектуру, не несёт ответственности за инциденты и не может принимать стратегические решения. Но он отлично справляется с рутиной, если дать ему чёткие инструкции.

Попробуйте первый промт прямо сейчас: возьмите любой падающий под и скопируйте запрос из раздела 1. Результат может удивить.