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