Операционные процедуры для типовых сценариев: восстановление сервисов, диагностика, ручные действия.
Назначение
- Единый источник шагов для on-call и SRE при реагировании на алерты и инциденты.
- Снижение времени на принятие решений и выполнение действий.
Структура runbook
Для каждого сценария (алерт, тип инцидента) рекомендуется:
- Условие — когда применять (какой алерт, какие симптомы).
- Цель — что нужно достичь (восстановить сервис, собрать данные и т.д.).
- Шаги — пошаговые действия с командами и проверками.
- Эскалация — когда и кому эскалировать (см. Escalation Policy).
- Ссылки — логи, дашборды, документация сервиса.
Примеры сценариев
- Identity service не отвечает — проверка пода в Kubernetes, логов, рестарт при необходимости, эскалация если не помогло.
- Kafka consumer lag растет — проверка потребителей, партиций, ресурсов; при необходимости масштабирование или рестарт consumer’ов.
- Высокая задержка БД — проверка метрик PostgreSQL, активных запросов, индексов; при необходимости оптимизация или эскалация к DBA/владельцу сервиса.
- Утечка памяти в сервисе — сбор дампов/метрик, рестарт для быстрого снятия нагрузки, создание тикета на разбор.
Где хранить
- Runbooks хранятся в репозитории документации (например,
docs/operations/runbooks/) или в общей wiki; ссылки из систем алертинга (Grafana, PagerDuty и т.п.).
Поддержка актуальности
- Runbooks пересматриваются после инцидентов (постмортем) и при изменении архитектуры или процедур деплоя.
Связанные страницы
- Incident Management — процесс инцидентов
- On-call — кто выполняет runbook
- Service Catalog — владельцы сервисов
- Observability — логи и метрики