Сообщить об ошибкеКороткий ответ
Runbook — это пошаговая инструкция конкретных действий для диагностики и устранения определённого типа инцидента (например, "сервис X недоступен"), написанная так, чтобы по ней мог действовать дежурный даже без глубокого знания внутренностей системы; обычная документация обычно описывает, как система устроена, а не что делать при сбое.
Как это работает подробнее
хороший runbook содержит симптомы/алерт, который его запускает, шаги диагностики (какие команды/дашборды проверить), шаги устранения (что сделать для каждого распространённого корневого случая) и критерии эскалации, если проблема не решается описанными шагами.
Пример / кейс
Ожидаемое поведение: дежурный без глубокого знания сервиса, следуя шагам, может либо устранить типовую причину (откат деплоя), либо корректно эскалировать проблему дальше в установленный срок.
Пример кода
Runbook: "API возвращает 5xx > 5% (алерт HighErrorRate)"
1. Проверить дашборд latency/errors по сервису: <ссылка>
2. Проверить последний деплой: kubectl rollout history deployment/api
3. Если ошибки начались после деплоя — откатить: kubectl rollout undo deployment/api
4. Если ошибки не связаны с деплоем — проверить состояние БД: <ссылка на дашборд БД>
5. Если за 20 минут не решено — эскалировать на SEV2, подключить владельца сервиса.Что использовать на практике
- Практический подход. Runbook тестируют и обновляют после каждого инцидента, где он оказался неполным или неверным — иначе он быстро устаревает и теряет доверие дежурных. Runbook должен быть достаточно конкретным (точные команды, ссылки на дашборды), а не общими рекомендациями типа "проверьте логи".
Подводные камни
- Частые ошибки. Писать runbook один раз и не обновлять после изменений в системе; делать его слишком общим, из-за чего дежурный всё равно не понимает, что конкретно делать; хранить runbook в месте, недоступном во время инцидента (например, только на внутреннем wiki, который сам зависит от упавшего сервиса).