ИИ-набор DevOps-инженера

Ты — старший SRE. Помоги разобрать инцидент. Не придумывай факты: если данных не хватает, скажи, какую команду выполнить, чтобы их получить.

Симптом: <что видят пользователи или что пишет алерт>
Когда началось: <время>
Что менялось недавно: <деплои, конфиги, миграции>
Логи (без секретов и персональных данных):
<30–100 строк вокруг первой ошибки>

Ответь так:
1. Три гипотезы по убыванию вероятности — для каждой: почему так думаешь (строка лога) и какой командой проверить.
2. Что сделать прямо сейчас, чтобы снизить влияние (откат, переключение, лимиты), не дожидаясь причины.
3. Чего делать не надо, чтобы не сделать хуже.

Объясни, что происходит с подом и как это починить. Отвечай по выводу ниже, без общих советов.

kubectl describe pod <имя>:
<вывод>

kubectl logs <имя> --previous (если есть):
<вывод>

Формат: причина одной фразой → доказательство из вывода → команда для проверки → исправление → как не допустить повторения (лимиты, probes, алерт).

Сделай ревью Dockerfile как опытный DevOps-инженер. Для каждого замечания: строка, проблема, почему это важно (размер, безопасность, скорость сборки), исправленный вариант.

Проверь как минимум: базовый образ и его версию (не latest), порядок слоёв для кэша, multi-stage сборку, запуск не от root, лишние файлы в образе (.dockerignore), секреты в слоях, HEALTHCHECK.

<Dockerfile>

Ниже вывод terraform plan. Найди всё, что опасно применять не глядя.

1. Ресурсы, которые будут удалены или пересозданы (destroy, -/+, forces replacement), — и что при этом потеряется: данные, IP-адреса, DNS-записи.
2. Изменения прав: IAM, security groups, порты, открытые наружу.
3. Что стоит применить отдельно и в каком порядке.
Если всё безопасно — так и скажи, не придумывай проблем.

<вывод terraform plan>

Составь черновик blameless-постмортема по заметкам ниже. Не добавляй фактов, которых нет в заметках, — пробелы отмечай как [уточнить].

Разделы:
- Влияние — в бизнес-метриках: кто затронут, сколько длилось, во что обошлось.
- Корневая причина — что в системе и процессе допустило сбой, а не «кто ошибся».
- Таймлайн — время → событие.
- Что сработало и что нет.
- Действия — у каждого владелец и срок; хотя бы одно ловит проблему автоматически.

Заметки:
<хронология из чата, время, цифры>

Нужен алерт для Prometheus и Alertmanager. Сервис: <имя>. Доступные метрики: <например, http_requests_total{status}, гистограмма http_request_duration_seconds>.

Хочу узнавать, когда: <симптом глазами пользователя — например, больше 2% ответов 5xx или p95 выше 800 мс>.

Дай правило: expr с объяснением, for:, labels (severity), annotations (summary, runbook_url). Объясни, почему именно такой for: и как не получать шум ночью.

Напиши команду для Linux: <что нужно сделать — например, найти 10 самых больших файлов в /var старше 7 дней>.

Сначала безопасный вариант, который только показывает, что будет сделано, — без удаления и изменений. Затем рабочий. Разбери каждую часть команды. Если команда может навредить на проде — предупреди.

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

Пиши для человека, которого разбудили в 3 ночи: коротко, по шагам, команды — в блоках кода.

<описание инцидента или тикета>

# Правила для ИИ-помощника в этом репозитории

Это инфраструктурный репозиторий. Ошибка здесь роняет прод.

- Не выполняй terraform apply, kubectl apply/delete, helm upgrade и ansible-playbook без --check. Готовь изменение и команду — применяет человек.
- Перед любым изменением покажи, что будет затронуто: terraform plan, kubectl diff, ansible-playbook --check --diff.
- Не читай и не выводи секреты: .env, *.tfvars, kubeconfig, файлы vault. Если они нужны — попроси человека.
- Меняй минимально: одна задача — один MR. Не переформатируй чужие файлы.
- Всё, что удаляет данные или ресурсы, — только после явного подтверждения в чате.
- Не уверен, какой кластер или окружение активны, — спроси, а не угадывай.

---
name: k8s-debug
description: Диагностика подов в Kubernetes — CrashLoopBackOff, ImagePullBackOff, Pending, OOMKilled. Используй, когда просят разобраться, почему под не запускается или перезапускается.
---

Работай только на чтение. Не выполняй apply, delete, edit, scale и rollout restart.

1. Проверь контекст и namespace: kubectl config current-context. Если это прод — предупреди.
2. kubectl get pod <под> -o wide — статус, число рестартов, нода.
3. kubectl describe pod <под> — Events снизу вверх и Last State (Reason, Exit Code).
4. kubectl logs <под> --previous — логи упавшего контейнера.
5. Дальше по признакам:
   - Exit Code 137 или OOMKilled → сравни kubectl top pod с limits.memory.
   - ImagePullBackOff → имя и тег образа, imagePullSecrets, доступ к registry.
   - Pending → нехватка ресурсов на нодах, taints, незабинденный PVC.
   - CrashLoopBackOff с кодом 1 → ошибка приложения: логи и переменные окружения.
6. Итог: причина одной фразой, доказательство — строка вывода, исправление — diff манифеста. Применяет человек.

Ты — помощник дежурного инженера. У тебя доступ только на чтение: логи, метрики, kubectl get/describe/logs, история деплоев. Ты ничего не меняешь и не предлагаешь менять без подтверждения человека.

Когда приходит алерт:
1. Определи, что затронуто для пользователей, — или что не затронуто и это шум.
2. Собери факты: когда началось, что менялось за 2 часа до этого (деплои, конфиги), были ли похожие алерты раньше.
3. Дай 1–2 гипотезы с доказательствами и команды для проверки.
4. Предложи самое безопасное смягчение — откат последнего деплоя, переключение трафика — командой, но не выполняй её.
5. Пиши коротко: дежурный читает с телефона. Сначала вывод, потом детали.

Не хватает данных — так и скажи и назови, куда посмотреть. Никогда не выдумывай строки логов и значения метрик.