Хороший runbook описывает симптом, возможные причины, владельца сервиса, ссылки на dashboards, команды диагностики, безопасные действия, опасные действия, правила rollback, критерии успеха, контакты для эскалации и что нужно записать в тикет или incident report.
Для DevOps AI-агента runbook должен быть основным источником remediation-предложений. Агент не должен импровизировать с production-командами. Он должен найти подходящий runbook, объяснить причину alert, предложить проверки, подготовить команды или черновик действия и указать, где нужен человек.
Runbook отличается от обычной документации тем, что он написан для конкретной ситуации и быстрого действия. Документация объясняет систему в целом, а runbook отвечает на вопрос "что делать прямо сейчас, если случилось вот это".
Runbook может быть полностью ручным, полуавтоматическим или автоматизированным. Ручной вариант просто описывает шаги. Полуавтоматический дает команды и запросы, которые оператор запускает сам. Автоматизированный может быть связан с workflow, но опасные действия вроде rollback, удаления данных, масштабирования production или перезапуска критичного сервиса лучше проводить через approval workflow.
Главный риск - устаревший runbook. Если команды, dashboards, владельцы или архитектура изменились, инструкция может навредить. Поэтому runbook нужно регулярно проверять после инцидентов, деплоев и изменений инфраструктуры.
Практическое правило: runbook должен быть коротким, проверяемым и конкретным. Если человек на дежурстве не может по нему за 5-10 минут понять, что проверить и кому эскалировать, значит инструкция требует доработки.
Примеры
- Alert "API latency p95 выше 2 секунд" открывает runbook: проверить Grafana dashboard, recent deploys, slow queries, очередь задач и только потом решать, нужен ли rollback.
- Runbook для падения worker описывает команды проверки очереди, логи контейнера, безопасный restart и критерии, когда нужно эскалировать владельцу сервиса.
- AI-агент получает alert от Prometheus, находит связанный runbook, собирает контекст из логов и предлагает дежурному три проверки без автоматического изменения production.
- После инцидента команда обновляет runbook: добавляет новый симптом, ссылку на dashboard и шаг проверки, который помог найти причину.
Где используется
- incident response
- дежурства on-call
- мониторинг и DevOps
- IT Service Desk
- rollback после деплоя
- диагностика alerts
- обучение новых инженеров
- AI-агент для эксплуатации
Связанные термины
Частые вопросы
Зачем нужен runbook?
Он помогает быстро и одинаково реагировать на известные alerts и инциденты: что проверить, какие действия безопасны, когда делать rollback и кому эскалировать проблему.
Что должно быть в runbook?
Симптом, возможные причины, владелец сервиса, ссылки на dashboards, команды диагностики, безопасные действия, опасные действия, правила эскалации, критерии успеха и шаги после инцидента.
Чем runbook отличается от playbook?
В разговорной практике термины часто смешивают. Обычно runbook более конкретен и описывает шаги для сервиса или alert, а playbook может быть шире: процесс реагирования, роли и правила команды.
Можно ли дать AI-агенту выполнять runbook автоматически?
Можно для низкорисковых действий: собрать логи, проверить метрики, создать тикет, подготовить summary. Действия с production-эффектом - rollback, restart, удаление данных, изменение лимитов - лучше подтверждать человеком.
Как поддерживать runbook актуальным?
Проверяйте его после инцидентов, деплоев и изменений инфраструктуры. У runbook должен быть владелец, дата обновления, ссылки на актуальные dashboards и понятные критерии, когда инструкция больше не работает.
