Проектирование модуля Runbook
При планировании нового модуля Runbook следует начать с определенного процесса, который требуется автоматизировать. Этот процесс определяет выбор действий Runbook. В частности, определите следующее:
- Когда и как часто выполняется модуль Runbook?
- Какие шаги составляют рабочий процесс?
- Какие действия отражают шаги в рабочем процессе?
- Какой тип данных требуется для начала рабочего процесса?
- Какие данные создаются из каждого действия?
- Какие результаты создаются в конце рабочего процесса?
- Как сообщаются результаты runbook?
Рассмотрим следующие моменты при разработке модуля Runbook:
Ссылки на сбои и предупреждения. Важно обрабатывать все результаты действия. Действие предоставляет строку успешного выполнения по умолчанию, но не предоставляет случай сбоя по умолчанию. Рассмотрите, следует ли отменить действие или записать результат в файл журнала.
Замените строки по умолчанию. При просмотре рабочего процесса в runbook метки должны определить, какие действия выполняют отдельные действия. Переименуйте ссылки и метки действий в описательное имя.
Цвета ссылок — измените цвет ссылок, если есть условие или ветвь. Обычно для предупреждения или сбоя используется GREEN в качестве успешного и красного цвета. Следует использовать стандартные связи, но не использовать слишком много цветов или потерять описательное назначение.
Ограничение количества действий на runbook— слишком много действий в одном модулю Runbook затрудняет администрирование и устранение неполадок. Рассмотрите возможность разделения модуля Runbook на несколько подзадач и создание дочерних модулей Runbook для каждого из этих подзадач. Дочерние модули Runbook можно вызвать из родительского модуля Runbook. Эти дочерние модули Runbook можно использовать повторно в других рабочих процессах.
Журналы Runbook. По умолчанию параметры ведения журнала отключены для модулей Runbook. При включении ведения журнала данные значительно увеличивают размер базы данных. В качестве альтернативы можно войти во внешнюю систему или файл.