Sre Runbook Author

---
name: sre-runbook-author
description: >
  Создаёт исполняемый runbook для конкретного сценария — алерта, отказа, плановой
  операции. Соблюдает структуру (TL;DR, диагностика, митигация, эскалация),
  предпочитает копипастабельные команды объяснениям. Используй, когда пользователь
  хочет «написать runbook», «оформить ранбук», «инструкцию для дежурного»,
  «процедуру реакции на алерт», «оncall doc».
---

# sre-runbook-author — Автор runbook'ов

Цель: написать runbook, которым реально пользуются в 3 ночи — короткий, исполняемый, без болтовни.

Перед началом прочитай `~/.claude/rules/sre-runbook-template.md` — там полная структура и принципы. Этот скилл — применение шаблона к конкретному сценарию.

## Шаг 1. Зафиксируй scope

Спроси у пользователя:
- **сервис** или **подсистема**, к которому относится runbook
- **конкретный сценарий**: имя алерта, имя ошибки, тип операции (`POD_CrashLoopBackOff`, `Redis: high memory`, «выкатить миграцию», «ротация TLS-сертификата»)
- предполагаемый **severity** (или вилка)

Если scope размытый («runbook по нашему сервису») — **верни на шаг назад** и помоги вычленить конкретный сценарий. Один runbook = один сценарий.

## Шаг 2. Собери информацию

Узнай:
- какие dashboards / метрики смотрят при этом сценарии
- какие команды выполняют для проверки (kubectl, аналоги)
- какие команды выполняют для митигации (rollback, scale, drain)
- кто эскалейтит, через какой канал
- частые причины из прошлого (если есть постмортемы — спроси ссылки)

Если пользователь не помнит — **не выдумывай**. Помоги ему вспомнить вопросами или предложи placeholder с пометкой `TODO: уточнить`.

## Шаг 3. Сформируй runbook по структуре

Используй шаблон из `~/.claude/rules/sre-runbook-template.md`. Ключевые секции:

1. **TL;DR** — одна фраза, что делать в первую очередь. Это первое, что прочитает уставший дежурный.
2. **Когда применять** — алерт-имя или симптом, и явные **исключения** (когда не применим).
3. **Severity guidance** — что по умолчанию, когда поднимать.
4. **Быстрая диагностика (≤ 2 мин)** — 2-4 команды или ссылки на dashboards, ответ на вопрос «всё плохо или показалось?»
5. **Митигация** — последовательность шагов **с копипастабельными командами**. Митигация первой, root cause потом.
6. **Root cause investigation** — куда смотреть, частые причины с диагностикой и фиксом.
7. **Эскалация** — кому и как.
8. **После инцидента** — что обновить.
9. **История изменений** — таблица.

## Шаг 4. Стиль команд

Команды — **готовые к копипасту**:

Плохо:
```
kubectl logs <your-pod> -n <namespace>
```

Хорошо:
```
# Найди упавший под:
kubectl -n payments get pod -l app=api --field-selector status.phase!=Running

# Логи последнего контейнера:
kubectl -n payments logs <pod-name> --previous --tail=200
```

Если параметр действительно вариативен — объясни **где его взять**:
```
# <pod-name> — из вывода предыдущей команды (колонка NAME)
```

## Шаг 5. Покажи и спроси

Покажи драфт. Спроси:
1. Принять и сохранить (куда — `runbooks/`, wiki, или указать)
2. Поправить (что именно)
3. Добавить раздел (history of incidents, ссылки на related runbooks)

## Шаг 6. Куда сохранить

После подтверждения — спроси путь. Если у пользователя есть конвенция (см. структура репозитория с runbook'ами) — соблюди её. Если нет — предложи `runbooks/<service>/<scenario>.md` в формате kebab-case.

## Чего не делать

- Не пиши «check the logs» — пиши **какую команду** запустить
- Не описывай архитектуру сервиса внутри runbook — это design doc, не runbook
- Не клади весь runbook в один большой блок — структура помогает в стрессе
- Не используй `<placeholder>` без объяснения, чем заполнить
- Не пиши runbook на ситуацию, которой у пользователя никогда не было — это спекуляция, а не runbook