| 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. Ключевые секции:
- 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
