11 промтов для DevOps, которые убирают ночные дежурства: Docker, Kubernetes, Terraform и CI/CD без рутины

11 промтов для DevOps, которые убирают ночные дежурства: Docker, Kubernetes, Terraform и CI/CD без рутины

Ночное дежурство — это не только бессонные часы, но и постоянный контекст-свитчинг: ты просыпаешься от алерта и должен вспомнить, как выглядит манифест, какой образ собирается, где лежит state Terraform. По данным Google SRE Book, до 50% времени инженера уходит на реактивную работу, а не на улучшение систем. ИИ здесь работает не как замена, а как ускоритель: он генерирует черновики Dockerfile, манифестов, Terraform-модулей и CI/CD-пайплайнов, а ты проверяешь и адаптируешь.

Ниже — 11 промтов, которые закрывают инфраструктурную рутину. Каждый промт написан так, чтобы его можно было скопировать в любой LLM (ChatGPT, Claude, Gemini) и получить рабочий результат. Мы разберём Docker, Kubernetes, Terraform, CI/CD и разбор инцидентов. Важно: ИИ не заменяет инженера, но снимает 60–70% механической работы, если правильно формулировать запросы.

Промты для Docker: от Dockerfile до оптимизации образов

1. Генерация безопасного Dockerfile для Python-приложения

Задача: быстро получить многоступенчатый Dockerfile с non-root пользователем, минимальным базовым образом и кэшированием зависимостей. Подходит для микросервисов на FastAPI, Flask, Django.

Промт:

Ты — senior DevOps-инженер. Сгенерируй production-ready Dockerfile для Python 3.12 приложения на FastAPI. Требования:
- многоступенчатая сборка (builder + runtime)
- базовый образ python:3.12-slim
- non-root пользователь appuser (UID 1000)
- кэширование pip-зависимостей через --mount=type=cache
- HEALTHCHECK на /health
- переменные окружения PYTHONDONTWRITEBYTECODE=1, PYTHONUNBUFFERED=1
- финальный образ < 200 MB
Выведи только Dockerfile с комментариями.

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

# builder
FROM python:3.12-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN --mount=type=cache,target=/root/.cache/pip \
    pip install --user -r requirements.txt

# runtime
FROM python:3.12-slim
RUN useradd -m -u 1000 appuser
WORKDIR /app
COPY --from=builder /root/.local /home/appuser/.local
COPY . .
USER appuser
ENV PATH=/home/appuser/.local/bin:$PATH
HEALTHCHECK CMD curl -f http://localhost:8000/health || exit 1
CMD ["uvicorn", "main:app", "--host", "0.0.0.0"]

Почему работает: промт задаёт жёсткие ограничения (размер, пользователь, healthcheck), и модель не уходит в общие рассуждения. Проверь итоговый образ через docker scan и dive.

2. Оптимизация существующего Dockerfile

Задача: уменьшить размер образа и ускорить сборку. Подходит, когда образ разросся до гигабайтов.

Промт:

Проанализируй Dockerfile ниже. Найди проблемы: лишние слои, отсутствие .dockerignore, копирование ненужных файлов, неоптимальный порядок инструкций. Предложи оптимизированный вариант и объясни каждое изменение. Выведи diff в формате unified.

<вставь Dockerfile>

Пример: для Node.js-приложения модель часто предлагает вынести npm ci перед COPY . ., чтобы кэш не сбрасывался при изменении кода. Это реальный приём из документации Docker.

3. Диагностика ошибки сборки Docker

Задача: быстро понять, почему docker build падает. Подходит для ошибок вида «failed to solve», «no space left on device», конфликтов зависимостей.

Промт:

Ты — эксперт по Docker. Вот лог ошибки сборки:
<вставь лог>

Вот Dockerfile:
<вставь Dockerfile>

Объясни причину ошибки, предложи минимальное исправление и команду для проверки. Не предлагай переписывать всё с нуля.

Промты для Kubernetes: манифесты, отладка, ресурсы

4. Генерация манифеста Deployment + Service + Ingress

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

Промт:

Сгенерируй Kubernetes-манифесты для приложения:
- Deployment: 3 реплики, образ registry.example.com/api:v1.2.3, порт 8080
- ресурсы: requests cpu=100m memory=128Mi, limits cpu=500m memory=512Mi
- livenessProbe и readinessProbe на /health
- Service типа ClusterIP
- Ingress с host api.example.com, TLS через cert-manager
- namespace production
Выведи три файла через ---. Используй apiVersion apps/v1 и networking.k8s.io/v1.

Пример результата (фрагмент):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels: {app: api}
  template:
    metadata:
      labels: {app: api}
    spec:
      containers:
      - name: api
        image: registry.example.com/api:v1.2.3
        ports: [{containerPort: 8080}]
        resources:
          requests: {cpu: 100m, memory: 128Mi}
          limits: {cpu: 500m, memory: 512Mi}
        livenessProbe:
          httpGet: {path: /health, port: 8080}

Почему работает: промт фиксирует версии API и конкретные значения, поэтому манифест проходит kubectl apply --dry-run=server без правок.

5. Отладка падающего пода (CrashLoopBackOff)

Задача: разобрать инцидент, когда под циклически перезапускается. Подходит для ночных алертов.

Промт:

Под в CrashLoopBackOff. Вот вывод команд:
kubectl describe pod <name>
kubectl logs <name> --previous
kubectl get events --sort-by=.lastTimestamp

<вставь вывод>

Определи наиболее вероятную причину, предложи 3 гипотезы в порядке вероятности и команды для проверки каждой. Не предлагай удалять под без объяснения.

Пример: модель часто указывает на OOMKilled (проверяется через kubectl describe pod — Reason: OOMKilled) и предлагает поднять limits. Это соответствует официальной документации Kubernetes по диагностике.

6. Настройка Horizontal Pod Autoscaler

Задача: автоматическое масштабирование по CPU и кастомным метрикам. Подходит для сервисов с переменной нагрузкой.

Промт:

Создай HPA для Deployment api в namespace production. Требования:
- minReplicas 2, maxReplicas 10
- масштабирование по CPU 70% и по кастомной метрике http_requests_per_second (target 1000)
- поведение scaleDown: стабилизация 300 секунд
Используй autoscaling/v2. Поясни, зачем нужна стабилизация.

Промты для Terraform: инфраструктура как код

7. Генерация Terraform-модуля для AWS VPC

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

Промт:

Напиши Terraform-модуль для AWS VPC. Требования:
- CIDR 10.0.0.0/16
- 2 публичные и 2 приватные подсети в разных AZ
- Internet Gateway, NAT Gateway для приватных подсетей
- route tables и associations
- outputs: vpc_id, public_subnet_ids, private_subnet_ids
- переменные: env, region
Используй провайдер hashicorp/aws версии ~> 5.0. Добавь пример вызова модуля.

Пример вызова:

module "vpc" {
  source = "./modules/vpc"
  env    = "prod"
  region = "eu-central-1"
}

Почему работает: промт задаёт точные CIDR и версию провайдера — это снижает риск несовместимости. Проверь план через terraform plan перед apply.

8. Импорт существующего ресурса в state

Задача: добавить в Terraform уже созданный вручную ресурс. Подходит при миграции на IaC.

Промт:

У меня есть S3-бакет my-prod-logs, созданный вручную. Напиши:
1. Блок resource aws_s3_bucket с нужными настройками (versioning, encryption)
2. Команду terraform import с корректным адресом
3. Как проверить, что state совпадает с реальностью
Учти, что бакет в регионе eu-central-1.

9. Рефакторинг Terraform: вынос в модули

Задача: разбить монолитный main.tf на модули. Подходит, когда конфигурация разрослась до 1000+ строк.

Промт:

Вот main.tf на 800 строк. Предложи разбиение на модули по доменам: network, compute, database, monitoring. Для каждого модуля укажи inputs и outputs. Покажи структуру директорий и пример перемещения ресурсов без пересоздания (terraform state mv).

<вставь код>

Промты для CI/CD и инцидентов

10. Генерация GitHub Actions пайплайна

Задача: собрать, протестировать и задеплоить приложение. Подходит для типового Python/Node.js проекта.

Промт:

Сгенерируй .github/workflows/deploy.yml. Требования:
- триггер: push в main
- шаги: checkout, setup Python 3.12, кэш pip, запуск pytest, сборка Docker-образа, push в GHCR, деплой в Kubernetes через kubectl set image
- секреты: GHCR_TOKEN, KUBE_CONFIG
- concurrency: отмена предыдущих запусков
Добавь комментарии к неочевидным шагам.

Пример фрагмента:

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: true
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: {python-version: '3.12'}
      - run: pip install -r requirements.txt && pytest

11. Разбор инцидента и post-mortem

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

Промт:

Ты — SRE. Вот таймлайн инцидента:
<вставь события с timestamps, алерты, действия>

Составь post-mortem по шаблону Google SRE:
- Impact (что и кого затронуло)
- Root cause (корневая причина)
- Detection (как обнаружили)
- Resolution (что сделали)
- Action items (3–5 конкретных задач с приоритетами)
Без обвинений, только факты.

Почему работает: структура post-mortem из Google SRE Book — отраслевой стандарт, и модель следует ей, если задать шаблон явно.

Как встроить промты в рабочий процесс

Сохрани эти промты в отдельный файл (например, prompts/devops.md) или в сниппеты IDE. Ключевое правило: всегда указывай версии (Python, Terraform, API Kubernetes) и ограничения (размер образа, регион, бюджет). Чем конкретнее вход, тем меньше правок на выходе. ИИ не заменит инженера, но снимет механическую работу: черновики манифестов, boilerplate Terraform, типовые пайплайны. А ночные дежурства станут реже — потому что инфраструктура будет описана кодом, а не памятью.

Попробуй начать с одного промта — например, с генерации Dockerfile или разбора CrashLoopBackOff. Если хочешь системно прокачать навыки работы с ИИ в инфраструктуре, посмотри материалы и курсы на asibiont.com — там есть практические разборы по автоматизации и IaC.

Полезные ссылки:
- Docker docs: https://docs.docker.com/develop/develop-images/multistage-build/
- Kubernetes docs: https://kubernetes.io/docs/tasks/debug/
- Terraform docs: https://developer.hashicorp.com/terraform/language/modules
- Google SRE Book: https://sre.google/sre-book/table-of-contents/