Коротко. Runbook — это пошаговая инструкция, по которой дежурный устраняет конкретный тип сбоя, не разбираясь в системе с нуля в три часа ночи. Хороший runbook начинается с симптома («алерт X сработал»), даёт проверки для подтверждения, конкретные команды для починки и условие, когда эскалировать. Цель — превратить панику в чек-лист.
Зачем нужен runbook
В момент инцидента у дежурного нет времени читать архитектурную документацию. Runbook даёт готовый алгоритм для самых частых сценариев.
Runbook — это не замена понимания системы, а способ действовать быстро и одинаково, когда времени на размышления нет. Лучший runbook читается за минуту и применяется без вопросов.
Структура хорошего runbook
- Симптом / триггер — какой алерт или жалоба запускает этот runbook.
- Диагностика — как подтвердить, что проблема именно эта.
- Устранение — конкретные шаги и команды.
- Проверка — как убедиться, что починилось.
- Эскалация — когда и кому передавать дальше.
Шаблон runbook
RUNBOOK: Высокая доля ошибок 5xx на API
== СИМПТОМ ==
Алерт "api-5xx-rate" > 5% за 5 минут.
== ДИАГНОСТИКА ==
1. Проверить дашборд golden signals (латентность, ошибки).
2. Посмотреть, не было ли деплоя:
kubectl rollout history deployment/api
3. Проверить состояние подов:
kubectl get pods -l app=api
== УСТРАНЕНИЕ ==
ЕСЛИ причина — недавний деплой:
kubectl rollout undo deployment/api
ЕСЛИ причина — перегрузка БД:
# увеличить пул соединений до восстановления
kubectl scale deployment/api --replicas=2
== ПРОВЕРКА ==
1. Доля 5xx вернулась < 1% за 5 минут.
2. Латентность p99 в норме.
== ЭСКАЛАЦИЯ ==
Если за 15 минут не стабилизировалось — звонок тимлиду (L2),
объявить major incident, начать постмортем.Чек-лист для каждого runbook
- Начинается ли он с конкретного симптома или алерта?
- Можно ли выполнить шаги, не зная всей системы?
- Все команды актуальны и протестированы?
- Есть ли явное условие эскалации?
- Указано ли, как проверить, что починилось?
Частые ошибки
| Ошибка | Как исправить |
|---|---|
| Устаревшие команды | Ревизия после каждого изменения инфраструктуры |
| Слишком общие шаги | Конкретные команды вместо «перезапустите сервис» |
| Нет условия эскалации | Явный таймаут и контакт L2 |
| Runbook на 10 страниц | Один сценарий — один короткий runbook |
Как enterno.io встраивается в runbook
Многие runbook начинаются с шага «подтвердить, что сервис действительно недоступен снаружи». enterno.io как внешний (synthetic) мониторинг даёт этот ответ: проверки HTTP, SSL, ping и DNS из России, Европы и США показывают, видна ли проблема пользователям или это локальный сбой. Алерты приходят в Telegram, Slack, email, webhook, PagerDuty и Jira — прямо к началу runbook.
Подключите мониторы для подтверждения сбоя, публикуйте статус-страницу, а для cron и очередей включите heartbeat. О дежурстве читайте в статье про on-call.
Частые вопросы
Чем runbook отличается от постмортема?
Runbook — это инструкция до и во время инцидента, как чинить. Постмортем — разбор после, почему случилось и как не повторить.
Сколько runbook нужно команде?
По одному на каждый частый actionable-алерт. Лучше много коротких, чем один огромный документ.
Как поддерживать runbook в актуальном состоянии?
Пересматривать после каждого инцидента и каждого изменения инфраструктуры. Устаревший runbook опаснее его отсутствия.
Можно ли автоматизировать runbook?
Да, частично: повторяющиеся шаги превращаются в скрипты, а сам runbook оставляет человеку решения, требующие контекста.
Добавьте внешнюю проверку в свои runbook. Создайте мониторы на enterno.io/monitors, чтобы первый шаг диагностики занимал секунды.