Перейти к содержанию

🟢 Статус: Conceptually stable · v0.1

Концепция устойчива, проверена опытом, литературой и практикой.

Что происходит после того, как Zabbix настроен и шаблоны разложены. Runbook для реальной ночной смены, а не для аудита. SLA, которые опираются на накопленные данные, а не на обещания. Дашборды под конкретную аудиторию, а не «все графики на одном экране». Операционная модель, делающая мониторинг функцией, а не разовым проектом. Эта часть отвечает на вопрос «и что теперь?».

09. Runbook

Что такое runbook — одна строчка

Runbook — инструкция «что делать дежурному, когда сработал этот конкретный алерт». Не общее описание системы, не архитектурный документ — именно пошаговый ответ на конкретную ситуацию.

Разница: - Wiki-статья «как работает Exchange DAG» — это документация - «Что делать если Exchange DAG split-brain в 3 ночи» — это runbook

Как runbook привязывается к триггеру в Zabbix

Ссылка на runbook хранится в поле Menu entry URL триггера (в старых версиях — просто URL). В шаблоне нотификации ссылка выводится через макрос {TRIGGER.URL}. Алерт в Telegram/email/Mattermost — там сразу кликабельная ссылка. Дежурный не ищет в голове «что делать».

Настройка: Data collection → Templates → открыть шаблон → Triggers → открыть триггер → поле «Menu entry URL». Название и расположение поля зависят от версии интерфейса.

Структура хорошего runbook

Минималистичная версия, которая реально работает:

# RUNBOOK: <Название алерта>

**Ответственный:** <команда/роль, не имя сотрудника>
**Последняя проверка:** <дата>
**Следующая проверка:** <дата, рекомендуется раз в квартал>
**Проверено на:** <версия ПО / окружение>
**Применимо к:** <сервис, хост-группа, шаблон>
**Триггер Zabbix:** <название триггера + ссылка>
**Требуемые доступы:** <что нужно: SSH, Zabbix admin, AD, 1С-RAS>

## Коротко (для тех, кто читает в 3 ночи)
Скорее всего: <причина 1> — выполни <X>
Если не помогло: эскалируй на <имя, телефон>

## Severity и SLA
P1 / реакция 15 мин / восстановление 4 часа

## Влияние на бизнес
Одна строчка — что не работает для пользователей.

## Диагностика (шаги по порядку)
1. Проверь <что> командой/ссылкой
2. Проверь <что ещё>
3. ...

## Типовые причины и решения
| Причина | Признак | Решение |
|---------|---------|---------|
| ... | ... | ... |

## Эскалация
- 15 мин не восстановилось → дежурный L2 <роль/дежурная группа, не имя конкретного человека>
- 30 мин → CIO + DR-план
- Контакты — через дежурную ротацию/матрицу эскалации (отдельный документ, не в runbook)

## Связанные runbook
## Постмортем
<ссылка на последний>

Главный раздел — Коротко. Если человек сонный и в панике — он прочитает первые три строчки. Они должны закрывать 80% случаев.

Чего runbook не должен содержать

  • ❌ Команды без условий проверки (rm -rf, DROP TABLE, iisreset без проверки, что сервис действительно перестал отвечать)
  • ❌ Пароли, API-токены, секреты — только ссылки на хранилище секретов или роль
  • ❌ Failover, перезапуск сервисов в промышленной среде, откат — без явного согласования и плана отката
  • ❌ «Сделай X, потом Y» без указания что делать если X не сработало
  • ❌ Безусловные деструктивные операции (удаление данных, сброс конфигурации)

Runbook должен вести к решению или эскалации — не к новым проблемам.

Критерии качества runbook

Runbook «покрыт» — это не «файл создан». Чек-лист качества:

  • Ссылка из поля Menu entry URL триггера Zabbix работает и ведёт на актуальный документ
  • Ответственный назначен (роль/команда, не имя уволившегося сотрудника)
  • Команды проверены на актуальной версии ПО
  • Требуемые права доступа указаны и дежурный ими обладает
  • Путь эскалации ведёт на живых людей (дежурная ротация, не личный телефон)
  • План отката описан для деструктивных операций
  • Дата последней проверки не старше квартала для P1/P2 сервисов

Готовые runbook — где брать

Готовые репозитории

PagerDuty Incident Response https://response.pagerduty.com/ Лучший открытый источник. Не столько готовые runbook под конкретный стек, сколько фреймворк и шаблоны — как писать, структура, процессы. Читать обязательно.

SRE Book от Google https://sre.google/sre-book/being-on-call/ Не runbook, но философия — как думать про дежурство и документирование инцидентов. Стоит прочесть главу.

Prometheus Operator Runbooks https://runbooks.prometheus-operator.dev/ Живой пример технических runbook: алерт → возможные причины → шаги диагностики. Полезно как образец структуры даже вне Kubernetes.

Готовые runbook под конкретные стеки

Это то, что реально полезно: поиск под конкретный инструмент.

Стек Где искать
PostgreSQL pghero — скорее диагностический дашборд, не библиотека runbook; для runbook искать postgresql runbook + материалы Microsoft Learn по диагностике Azure PostgreSQL как структурный образец
Windows / AD материалы Microsoft Learn по диагностике Windows Server — не называются runbook, но по сути они
Exchange Microsoft Exchange Troubleshoot Analyzer + docs, раздел High Availability
Zabbix Готовых нет, но в шаблонах сообщества часто есть описание со шагами
Linux/системное https://github.com/danluu/post-mortems — постмортемы крупных компаний, из них вытекают runbook
Kubernetes https://runbooks.prometheus-operator.dev/ — примеры runbook для правил алертов Kubernetes/Prometheus
Сеть (Cisco) Cisco Troubleshooting Guides — официальная документация, структура как у runbook

Коммерческие/SaaS-источники

Atlassian https://www.atlassian.com/incident-management Хорошая база по управлению инцидентами: роли, процессы, постмортем и операционные практики. Структуру можно адаптировать под runbook.

Datadog https://docs.datadoghq.com/notebooks/ Notebooks часто используют как живые документы для диагностики: графики, запросы, текстовые шаги и ссылки в одном месте. Идея хорошо переносится на runbook.

Blameless / Incident.io / FireHydrant Это SaaS-платформы для управления инцидентами, у всех есть блоги с примерами runbook реальных компаний. Ищите по запросу [название] runbook examples.

Где хранить

Инструмент Подходит ли Заметки
Bookstack ✅ хорошо Иерархия книг, поиск, Markdown
Confluence ✅ хорошо Если уже есть, использовать
Git (Markdown) ✅ отлично Версионирование, ссылки из Zabbix
Wiki в Zabbix ❌ нет такого Только описание триггера, не полноценно
Notion/SharePoint ⚠️ можно Хуже с поиском и версионированием
Word-файлы в папке ❌ нет Умирают, теряются, не ищутся

Главное правило хранения: runbook должен быть найден за 30 секунд. Если человек в 3 ночи не может найти — runbook не существует.

Сколько их нужно

Не нужно сразу 200 штук. Реалистичный подход:

  • Месяц 1: 5–7 runbook для самых частых и критичных алертов
  • Месяц 3: 20–30 (все Disaster + часть High)
  • Год 1: 50–70 (всё что важно)

Остальное — по мере инцидентов. Постмортем → runbook. Это органический рост.

Автогенерация — есть ли смысл

Тема популярная сейчас. Несколько инструментов пытаются генерировать runbook из описаний алертов через LLM.

Честно: для базовой структуры — помогает. Для конкретных команд под вашу инфраструктуру — нужна ручная правка. Воспринимайте как «заготовку черновика», не готовый продукт.

Попробовать: скопируйте описание триггера в любой LLM и попросите «напиши runbook для этого алерта». Получите 70% готового — остаётся адаптировать под ваш стек, команды, контакты.

⚠️ Дисклеймер. LLM может придумать несуществующие команды, неверные пути к файлам, устаревшие флаги, опасные операции без контекста («просто удали и пересоздай»). Каждый сгенерированный runbook обязан пройти проверку ответственным инженером и быть проверен в тестовой среде до использования в промышленной среде. Особенно опасно: команды для MSSQL, 1С, Exchange, процедуры failover.

Вот и всё по runbook. Там нет ничего сложного — сложность в том, чтобы реально писать их после каждого инцидента, а не «потом». Это дисциплина, не технология.

Связь с остальными главами