ChatGPT как DevOps-напарник: 10 промтов, которые не дадут уронить прод

Каждый DevOps-инженер знает: рутина съедает время, а ошибка в манифесте или пайплайне может стоить часов простоя. ChatGPT уже умеет генерировать Dockerfile, Helm-чарты и GitHub Actions, но без правильного промта результат часто требует переписывания. В этой подборке — проверенные запросы, которые превращают LLM в аккуратного ассистента, а не в источник инцидентов. Мы собрали 10 промтов разного уровня: от базовой генерации манифестов до экспертного анализа логов упавшего пода. Каждый пример сопровождается реальным кодом и объяснением, какую рутину он снимает. Главный принцип: ИИ предлагает — человек ревьюит и применяет.

Базовые промты: автоматизация повседневных задач

1. Генерация Dockerfile с учётом лучших практик

Задача: быстро получить безопасный и оптимизированный Dockerfile для Python-приложения.

Промт:

Ты — опытный DevOps-инженер. Напиши Dockerfile для Python 3.12 приложения на FastAPI. Требования:
- multi-stage сборка
- использование непривилегированного пользователя
- кэширование зависимостей через requirements.txt
- минимальный базовый образ (slim)
- HEALTHCHECK
- комментарии к ключевым шагам

Пример результата:

# Stage 1: builder
FROM python:3.12-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --user -r requirements.txt

# Stage 2: runtime
FROM python:3.12-slim
WORKDIR /app
COPY --from=builder /root/.local /home/appuser/.local
COPY . .
RUN useradd -m appuser && chown -R appuser:appuser /app
USER appuser
ENV PATH=/home/appuser/.local/bin:$PATH
HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8000/health || exit 1
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Что снимает: ручное написание и оптимизацию Dockerfile, проверку на типичные ошибки (запуск от root, раздутый образ).

2. Создание Kubernetes Deployment и Service

Задача: сгенерировать манифесты для stateless-сервиса с probes и resource limits.

Промт:

Сгенерируй Kubernetes Deployment и Service для приложения с образом myapp:1.2.3. 3 реплики, порт 8080. Добавь liveness и readiness probes, requests/limits CPU и памяти, securityContext с readOnlyRootFilesystem. Используй namespace production.

Пример результата:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.2.3
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1000
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: production
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080

Что снимает: написание boilerplate-манифестов, забытые probes и limits.

3. Пайплайн GitHub Actions для сборки и пуша образа

Задача: автоматизировать CI-сборку Docker-образа с тегом по коммиту.

Промт:

Напиши workflow GitHub Actions, который собирает Docker-образ и пушит в GitHub Container Registry при пуше в main. Используй docker/build-push-action, кэширование слоёв, тег образа = sha коммита. Добавь шаг сканирования уязвимостей через Trivy.

Пример результата:

name: Build and Push
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: docker/setup-buildx-action@v3
    - uses: docker/login-action@v3
      with:
        registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}
    - uses: docker/build-push-action@v5
      with:
        push: true
        tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
        cache-from: type=gha
        cache-to: type=gha,mode=max
    - name: Scan image with Trivy
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: ghcr.io/${{ github.repository }}:${{ github.sha }}
        format: 'table'
        exit-code: '1'
        severity: 'CRITICAL'

Что снимает: ручное написание YAML, забытые шаги сканирования.

Продвинутые промты: отладка и оптимизация

4. Анализ логов упавшего пода

Задача: быстро найти причину CrashLoopBackOff по логам.

Промт:

Ты — SRE. Проанализируй лог пода Kubernetes и определи причину падения. Предложи шаги исправления. Лог:
2026-10-17T10:00:00Z ERROR: failed to connect to database: dial tcp 10.0.0.5:5432: connect: connection refused
2026-10-17T10:00:01Z FATAL: application startup failed

Пример результата:

Причина: приложение не может подключиться к PostgreSQL по адресу 10.0.0.5:5432 — соединение отклонено. Вероятные причины:
1. Сервис базы данных не запущен или недоступен.
2. Неправильный хост/порт в конфигурации.
3. Сетевые политики блокируют трафик.
Шаги:
- Проверьте статус пода с БД: kubectl get pods -n <namespace> -l app=postgres
- Убедитесь, что сервис существует: kubectl get svc postgres
- Проверьте endpoint'ы: kubectl get endpoints postgres
- Если БД в другом namespace, проверьте DNS-имя и NetworkPolicy.

Что снимает: ручной grep по логам и поиск известных ошибок.

5. Отладка Helm-чарта с ошибкой рендеринга

Задача: исправить ошибку Error: rendered manifests contain a resource that already exists.

Промт:

При выполнении helm install возникла ошибка: "rendered manifests contain a resource that already exists. Unable to continue with install: ServiceAccount \"myapp\" in namespace \"prod\" exists and cannot be imported into the current release". Объясни причину и предложи решение, включая возможные риски.

Пример результата:

Причина: Helm пытается создать ресурс, который уже существует в кластере и не управляется текущим релизом. Это часто случается, если ресурс был создан вручную или другим релизом.
Решения:
1. Удалить существующий ресурс (если он не нужен) и повторить установку.
2. Импортировать ресурс в релиз с помощью аннотации `meta.helm.sh/release-name` и `meta.helm.sh/release-namespace` (потребует правки).
3. Использовать `--force` (рискованно, может привести к пересозданию).
Рекомендация: проверить, кто создал ресурс, и при необходимости удалить перед установкой.

Что снимает: поиск решения по форумам и документации.

6. Оптимизация ресурсов в Kubernetes

Задача: подобрать requests/limits на основе метрик.

Промт:

У меня есть метрики использования CPU и памяти для пода за последние 7 дней: среднее CPU 200m, пиковое 800m; средняя память 300Mi, пиковая 900Mi. Предложи оптимальные requests и limits для Deployment, учитывая, что приложение чувствительно к OOM. Объясни выбор.

Пример результата:

Рекомендация:
requests: cpu: 250m, memory: 350Mi
limits: cpu: 1000m, memory: 1Gi
Обоснование: requests немного выше среднего, чтобы гарантировать ресурсы; limits с запасом выше пиков, чтобы избежать троттлинга и OOM. Память: лимит 1Gi покрывает пик 900Mi с запасом ~10%. CPU лимит 1000m предотвращает излишнее потребление, но позволяет справиться с пиками.

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

Экспертные промты: безопасность и сложные сценарии

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

Задача: выявить потенциальные уязвимости в манифесте.

Промт:

Проведи аудит безопасности следующего Kubernetes Deployment. Укажи все нарушения best practices (CIS Benchmark, Pod Security Standards). Предложи исправления.

(далее манифест)

Пример результата:

Нарушения:
1. Не указан securityContext: контейнер может работать от root.
2. Отсутствует readOnlyRootFilesystem: true.
3. Нет ограничения capabilities (добавьте drop: ["ALL"]).
4. Не задан automountServiceAccountToken: false.
5. Не указаны seccompProfile и appArmorProfile.
Исправленный фрагмент securityContext:
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Что снимает: ручную проверку по чеклистам, забытые настройки безопасности.

8. Генерация политики NetworkPolicy

Задача: ограничить трафик между микросервисами.

Промт:

Сгенерируй NetworkPolicy для namespace 'backend', разрешающую входящий трафик только от подов с меткой app=frontend на порт 8080 и исходящий только к подам с меткой app=database на порт 5432. Запрети весь остальной трафик.

Пример результата:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

Что снимает: сложное написание сетевых политик, риск открытого доступа.

9. Расследование инцидента: под в состоянии OOMKilled

Задача: понять причину OOM и предотвратить повтор.

Промт:

Под в Kubernetes постоянно перезапускается с причиной OOMKilled. Известно, что приложение на Java, Xmx не задан. Предложи шаги диагностики и исправления, включая настройку JVM и ресурсов.

Пример результата:

Шаги:
1. Проверьте логи предыдущего контейнера: kubectl logs <pod> --previous.
2. Убедитесь, что JVM видит лимиты памяти: Java 10+ автоматически учитывает cgroup limits, но лучше явно задать -Xmx.
3. Установите -Xmx в 50-70% от limit памяти, например, при limit 1Gi: -Xmx700m.
4. Увеличьте limits памяти, если приложение действительно требует больше.
5. Настройте liveness probe с большим initialDelay, чтобы избежать перезапусков при долгом старте.

Что снимает: время на диагностику типовых проблем.

10. Генерация Terraform для EKS с безопасными настройками

Задача: создать инфраструктуру для кластера EKS с приватными нодами.

Промт:

Напиши Terraform код для создания EKS кластера с приватными worker-нодами, включённым логированием control plane, и использованием managed node groups. Добавь комментарии по безопасности.

Пример результата:

module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  cluster_name    = "my-cluster"
  cluster_version = "1.29"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnets

  cluster_enabled_log_types = ["api", "audit", "authenticator"]

  eks_managed_node_groups = {
    private = {
      instance_types = ["t3.medium"]
      min_size       = 2
      max_size       = 5
      desired_size   = 2
      # Ноды размещены в приватных подсетях, доступ из интернета отсутствует
    }
  }
}

Что снимает: ручное написание Terraform, забытые настройки логирования и приватности.

Как использовать промты безопасно

ИИ генерирует код быстро, но ошибается в деталях. Всегда проверяйте:
- Синтаксис и версии API (например, apps/v1 для Deployment).
- Соответствие политикам безопасности вашей организации.
- Влияние на продакшн: сначала тестируйте в dev/staging.

Используйте промты как черновик, а не как истину. Ревью человеком обязательно.

Подборка из 10 промтов покрывает основные задачи DevOps: от создания Dockerfile до расследования инцидентов. Начните с базовых, постепенно переходите к экспертных. Помните: ChatGPT — это ускоритель, но ответственность за прод лежит на вас.