DevOps без ночных дежурств: как ChatGPT берёт на себя Docker, CI/CD и Kubernetes — 10 промтов, которые реально работают

DevOps без ночных дежурств: как ChatGPT берёт на себя Docker, CI/CD и Kubernetes — 10 промтов, которые реально работают

Ночной алерт в Slack, красный пайплайн в 3 часа ночи, под в CrashLoopBackOff — знакомо? DevOps-инженер сегодня — это и архитектор, и дежурный, и психотерапевт для YAML-файлов. По данным исследования DORA (Google Cloud, State of DevOps Report), команды с высокой автоматизацией инфраструктуры деплоят в разы чаще и тратят меньше времени на восстановление после сбоев. Но автоматизация не означает «купить ещё один SaaS». Иногда лучший инструмент — это грамотно сформулированный промт к LLM.

ChatGPT (и другие модели) не заменит вам kubectl, но отлично справляется с рутиной: пишет Dockerfile по требованиям, объясняет, почему пайплайн падает, разбирает вывод kubectl describe, генерирует манифесты и Helm-чарты, помогает с мониторингом. Главное — знать, как спросить. Ниже — 10 промтов, которые я сам использую в работе, с примерами и пояснениями. Копируйте, адаптируйте, применяйте.

Важное предупреждение: любой сгенерированный код и конфиг проверяйте перед применением в проде. Модель может ошибаться в деталях версий API, названий флагов и поведения инструментов. Используйте её как ускоритель мышления, а не как источник истины.

1. Dockerfile с нуля под конкретный стек

Задача: быстро получить рабочий, безопасный и многоступенчатый Dockerfile под ваш проект.

Промт:

Ты — senior DevOps-инженер. Напиши production-ready Dockerfile для [стек: например, Node.js 20 + TypeScript]. Требования:
- multi-stage build, финальный образ на distroless или alpine
- non-root пользователь
- кэширование слоёв зависимостей
- HEALTHCHECK через curl/wget
- .dockerignore тоже предложи
Объясни каждое решение и укажи, какие флаги сборки (`docker build --build-arg`) нужны. Не используй устаревшие инструкции (MAINTAINER и т.п.).

Почему работает: вы задаёте рамки (multi-stage, non-root, healthcheck) — модель не выдаёт «hello world»-сборку, а сразу проектирует под прод. Пример: для Node.js модель предложит npm ci --omit=dev в финальной стадии и USER node. Проверьте, что базовый образ реально существует в Docker Hub.

2. Дебаг упавшего пайплайна по логу

Задача: GitHub Actions / GitLab CI упал, непонятно почему.

Промт:

Ниже лог упавшего CI-пайплайна (GitHub Actions). Проанализируй ошибку, определи корневую причину и предложи фикс. Дай исправленный фрагмент workflow и объясни, почему он решает проблему. Если причина в окружении — подскажи, как это проверить локально.

[вставьте лог]

Почему работает: LLM хорошо распознаёт типовые паттерны ошибок — отсутствующий permissions, неверный actions/checkout@vN, падение из-за set -e в shell-шаге. Пример: ошибка Error: Resource not accessible by integration чаще всего указывает на недостаточные permissions у GITHUB_TOKEN — модель подскажет добавить блок permissions: contents: read.

3. Kubernetes-манифест с реквестами и лимитами

Задача: сгенерировать Deployment + Service + HPA, не забыв про ресурсы и probes.

Промт:

Сгенерируй Kubernetes-манифесты для приложения [описание, образ, порт]. Нужны: Deployment, Service (ClusterIP), HorizontalPodAutoscaler. Обязательно:
- resources.requests и resources.limits
- livenessProbe и readinessProbe (httpGet)
- securityContext: runAsNonRoot, readOnlyRootFilesystem где уместно
- корректная apiVersion для Kubernetes 1.29+
Выведи единым YAML с разделителями `---` и прокомментируй спорные места.

Почему работает: вы фиксируете версию API и требования безопасности — модель не сгенерирует устаревший extensions/v1beta1. Пример: для HPA с autoscaling/v2 модель корректно укажет metrics[].resource.target.type: Utilization. Всегда сверяйте apiVersion с документацией kubernetes.io.

4. Диагностика пода в CrashLoopBackOff

Задача: под не стартует, вывода kubectl describe недостаточно.

Промт:

Под в Kubernetes падает с CrashLoopBackOff. Вот вывод `kubectl describe pod` и последние строки `kubectl logs --previous`. Определи вероятные причины в порядке убывания вероятности. Для каждой — как проверить (конкретная команда kubectl или изменение манифеста). Не предлагай перезапускать кластер.

[вставьте describe и логи]

Почему работает: вы даёте модели два источника данных (события из describe + логи предыдущего контейнера), и она строит гипотезы, а не гадает. Частые корни: проваленная readinessProbe, OOMKilled (видно в Last State: Terminated, Reason: OOMKilled), отсутствующий Secret. Пример: если в логах connection refused к БД, модель подскажет проверить kubectl get endpoints <service> — сервис без эндпоинтов = селектор не совпадает с лейблами подов.

5. Объяснение и рефакторинг чужого YAML/Helm

Задача: пришли в проект, где 500 строк values.yaml и никто не помнит, что где.

Промт:

Разбери этот Helm-чарт (values.yaml + шаблоны). Объясни назначение каждого блока, укажи неиспользуемые или дублирующиеся параметры, предложи рефакторинг с сохранением обратной совместимости. Отметь места, где значения по умолчанию опасны для прода (например, отключённые лимиты, `latest`-теги).

[вставьте файлы]

Почему работает: модели хорошо даётся «чтение» конфигов и поиск аномалий. Пример: она отметит image.tag: latest и resources: {} как риск и предложит зафиксировать тег и задать лимиты. Используйте это как онбординг-инструмент для новых членов команды.

6. Генерация шагов CI/CD под конкретный сценарий

Задача: нужен пайплайн с тестами, сборкой образа, сканированием и деплоем.

Промт:

Составь GitHub Actions workflow для проекта [стек] со стадиями: lint → test → build Docker-образ → scan (Trivy) → push в GHCR → деплой в Kubernetes через `kubectl set image`. Используй официальные actions (actions/checkout, docker/build-push-action, aquasecurity/trivy-action). Добавь кэширование и запуск только для main и PR. Укажи нужные secrets и permissions.

Почему работает: вы явно называете инструменты и порядок стадий — модель собирает пайплайн из проверенных компонентов вместо изобретения велосипеда. Пример: docker/build-push-action@v6 с cache-from: type=gha и cache-to: type=gha,mode=max. Сверьте актуальные мажорные версии actions в их репозиториях.

7. Промт для написания PromQL-запросов и алертов

Задача: настроить мониторинг, но PromQL забывается между задачами.

Промт:

Ты — SRE. Напиши PromQL-запросы для Prometheus и правила алертов (PrometheusRule) для сценариев:
1) сервис возвращает 5xx чаще 1% за 5 минут;
2) p95 латентности выше 500 мс;
3) под рестартует чаще 3 раз за 15 минут.
Для каждого — объясни логику, порог и что делать дежурному по алерту. Используй rate() и histogram_quantile() корректно.

Почему работает: PromQL коварен синтаксисом, и модель его знает. Пример для 5xx: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01. Для латентности: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 0.5. Всегда проверяйте метрики в вашем окружении через promtool check rules.

8. Промт-ревьюер инфраструктурного PR

Задача: проверить Terraform/Ansible/манифесты перед мержем.

Промт:

Выступи в роли ревьюера инфраструктурного PR. Проверь изменения на: безопасность (открытые порты, широкие IAM-права), идемпотентность, отсутствие хардкода секретов, корректность зависимостей ресурсов. Дай список замечаний с приоритетом (blocker/major/minor) и конкретным предложением фикса. Не переписывай весь файл — только проблемные участки.

[вставьте diff]

Почему работает: вы задаёте роль, критерии и формат вывода — получаете структурированное ревью, а не поток сознания. Пример: модель отметит 0.0.0.0/0 в security group как blocker и предложит сузить CIDR. Это не заменяет человеческое ревью, но ловит очевидное до мержа.

9. Объяснение незнакомой технологии «на пальцах»

Задача: нужно быстро разобраться в инструменте, с которым раньше не работали.

Промт:

Объясни [технология, например, Argo CD] DevOps-инженеру, который знает Kubernetes, но не сталкивался с GitOps. Дай: 1) какую проблему решает; 2) ключевые концепции (Application, sync, drift); 3) минимальный пример манифеста; 4) типичные грабли при внедрении. Без маркетинга, по делу.

Почему работает: вы задаёте уровень аудитории — модель не скатывается в базовые объяснения. Пример: для Argo CD она корректно опишет Application CRD и разницу между auto-sync и manual-sync. Сверяйте детали с официальной документацией argo-cd.readthedocs.io.

10. Постмортем и чек-лист на будущее

Задача: инцидент закрыт, нужно извлечь уроки и не повторить.

Промт:

Помоги написать blameless-постмортем по инциденту. Дано: [краткое описание, таймлайн, что сломалось]. Структура: сводка, влияние, таймлайн, корневая причина, что сработало, что нет, action items с владельцами и приоритетом. Формулируй без обвинений людей, фокус — на системных улучшениях.

Почему работает: модель помогает структурировать хаос и не забыть action items. Пример: если инцидент вызван ручным изменением в проде, action item — внедрить policy-as-code (например, OPA/Gatekeeper) и запретить прямой доступ. Это превращает боль в процесс.

Что важно помнить

Эти 10 промтов не сделают вас DevOps-инженером, но снимут рутину: Dockerfile, пайплайны, манифесты, диагностика, мониторинг и постмортемы — всё это ускоряется в разы, когда знаешь, как спросить. Начните с одного-двух промтов на этой неделе, адаптируйте под свой стек и сохраните в командную вики — через месяц коллеги будут спрашивать, откуда столько свободного времени.