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. Ключевые секции:
- TL;DR — одна фраза, что делать в первую очередь. Это первое, что прочитает уставший дежурный.
- Когда применять — алерт-имя или симптом, и явные исключения (когда не применим).
- Severity guidance — что по умолчанию, когда поднимать.
- Быстрая диагностика (≤ 2 мин) — 2-4 команды или ссылки на dashboards, ответ на вопрос «всё плохо или показалось?»
- Митигация — последовательность шагов с копипастабельными командами. Митигация первой, root cause потом.
- Root cause investigation — куда смотреть, частые причины с диагностикой и фиксом.
- Эскалация — кому и как.
- После инцидента — что обновить.
- История изменений — таблица.
Шаг 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. Покажи и спроси
Покажи драфт. Спроси:
- Принять и сохранить (куда —
runbooks/, wiki, или указать)
- Поправить (что именно)
- Добавить раздел (history of incidents, ссылки на related runbooks)
Шаг 6. Куда сохранить
После подтверждения — спроси путь. Если у пользователя есть конвенция (см. структура репозитория с runbook'ами) — соблюди её. Если нет — предложи runbooks/<service>/<scenario>.md в формате kebab-case.
Чего не делать
- Не пиши «check the logs» — пиши какую команду запустить
- Не описывай архитектуру сервиса внутри runbook — это design doc, не runbook
- Не клади весь runbook в один большой блок — структура помогает в стрессе
- Не используй
<placeholder> без объяснения, чем заполнить
- Не пиши runbook на ситуацию, которой у пользователя никогда не было — это спекуляция, а не runbook
1---2name: sre-runbook-author3description: Создаёт исполняемый runbook для конкретного сценария — алерта, отказа, плановой операции. Соблюдает структуру (TL;DR, диагностика, митигация, эскалация), предпочитает копипастабельные команды объяснениям. Используй, когда пользователь хочет «написать runbook», «оформить ранбук», «инструкцию для дежурного», «процедуру реакции на алерт», «оncall doc».4---5
6# sre-runbook-author — Автор runbook'ов
7
8Цель: написать runbook, которым реально пользуются в 3 ночи — короткий, исполняемый, без болтовни.
9
10Перед началом прочитай `~/.claude/rules/sre-runbook-template.md` — там полная структура и принципы. Этот скилл — применение шаблона к конкретному сценарию.
11
12## Шаг 1. Зафиксируй scope
13
14Спроси у пользователя:
15- **сервис** или **подсистема**, к которому относится runbook
16- **конкретный сценарий**: имя алерта, имя ошибки, тип операции (`POD_CrashLoopBackOff`, `Redis: high memory`, «выкатить миграцию», «ротация TLS-сертификата»)
17- предполагаемый **severity** (или вилка)
18
19Если scope размытый («runbook по нашему сервису») — **верни на шаг назад** и помоги вычленить конкретный сценарий. Один runbook = один сценарий.
20
21## Шаг 2. Собери информацию
22
23Узнай:
24- какие dashboards / метрики смотрят при этом сценарии
25- какие команды выполняют для проверки (kubectl, аналоги)
26- какие команды выполняют для митигации (rollback, scale, drain)
27- кто эскалейтит, через какой канал
28- частые причины из прошлого (если есть постмортемы — спроси ссылки)
29
30Если пользователь не помнит — **не выдумывай**. Помоги ему вспомнить вопросами или предложи placeholder с пометкой `TODO: уточнить`.
31
32## Шаг 3. Сформируй runbook по структуре
33
34Используй шаблон из `~/.claude/rules/sre-runbook-template.md`. Ключевые секции:
35
361. **TL;DR** — одна фраза, что делать в первую очередь. Это первое, что прочитает уставший дежурный.
372. **Когда применять** — алерт-имя или симптом, и явные **исключения** (когда не применим).
383. **Severity guidance** — что по умолчанию, когда поднимать.
394. **Быстрая диагностика (≤ 2 мин)** — 2-4 команды или ссылки на dashboards, ответ на вопрос «всё плохо или показалось?»
405. **Митигация** — последовательность шагов **с копипастабельными командами**. Митигация первой, root cause потом.
416. **Root cause investigation** — куда смотреть, частые причины с диагностикой и фиксом.
427. **Эскалация** — кому и как.
438. **После инцидента** — что обновить.
449. **История изменений** — таблица.
45
46## Шаг 4. Стиль команд
47
48Команды — **готовые к копипасту**:
49
50Плохо:
51```
52kubectl logs <your-pod> -n <namespace>
53```
54
55Хорошо:
56```
57# Найди упавший под:
58kubectl -n payments get pod -l app=api --field-selector status.phase!=Running
59
60# Логи последнего контейнера:
61kubectl -n payments logs <pod-name> --previous --tail=200
62```
63
64Если параметр действительно вариативен — объясни **где его взять**:
65```
66# <pod-name> — из вывода предыдущей команды (колонка NAME)
67```
68
69## Шаг 5. Покажи и спроси
70
71Покажи драфт. Спроси:
721. Принять и сохранить (куда — `runbooks/`, wiki, или указать)
732. Поправить (что именно)
743. Добавить раздел (history of incidents, ссылки на related runbooks)
75
76## Шаг 6. Куда сохранить
77
78После подтверждения — спроси путь. Если у пользователя есть конвенция (см. структура репозитория с runbook'ами) — соблюди её. Если нет — предложи `runbooks/<service>/<scenario>.md` в формате kebab-case.
79
80## Чего не делать
81
82- Не пиши «check the logs» — пиши **какую команду** запустить
83- Не описывай архитектуру сервиса внутри runbook — это design doc, не runbook
84- Не клади весь runbook в один большой блок — структура помогает в стрессе
85- Не используй `<placeholder>` без объяснения, чем заполнить
86- Не пиши runbook на ситуацию, которой у пользователя никогда не было — это спекуляция, а не runbook
aibot88