Runbook

Введение

Runbook — это не новая вещь, напротив, она существует уже много лет. Runbook можно рассматривать как практическое руководство по выполнению задачи, которое можно использовать для реагирования на инциденты в случае предупреждения.

Это практическое руководство может включать в себя тексты, контрольные списки, диаграммы, рабочие процессы — практически все, что облегчит работу дежурного во время инцидента.

Runbook можно использовать для ускорения реагирования на распространенные инциденты.

Это пример Runbook о том, что делать, когда цели Prometheus не работают.

Почему это важно

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

Это сократит время простоя и даст дежурному несколько дополнительных часов для сна :)

Согласно Google SRE Workbook, Runbook должен «снижать нагрузку, среднее время восстановления (MTTR) и риск человеческой ошибки».

Что должно быть в Runbook?

• Runbook должен сосредоточиться на одной задаче и содержать шаги, необходимые для решения проблемы.
• Шаги в модуле Runbook должны быть понятными, чтобы любой мог быстро решить проблему даже для дежурного, который находится в полусонном состоянии.
• Каждая проблема должна включать название оповещения и описание .
• В нем должно быть указано, насколько серьезной является проблема.
• Он должен описывать любые зависимости от других сервисов.
• Он должен содержать информацию о влиянии на бизнес .
• Он должен содержать информацию о том, как общаться с заинтересованными сторонами, заказчиком и организацией.
• Он должен содержать контактную и дежурную информацию .
• Раздел FAQ (часто задаваемые вопросы)

Создание Runbook

Звучит здорово, но как такое создать? С чего вообще начать?

Вы можете начать создание модуля Runbook, написав инструкции для задачи на основе предыдущего инцидента. Подумайте, какие самые распространенные инциденты. Эту информацию можно получить из вскрытий .

Всякий раз, когда создается оповещение, должна быть создана соответствующая запись Runbook.

Для начала я бы порекомендовал ознакомиться с коллекцией GitLab Runbooks . Этот репозиторий предоставляет множество модулей Runbook для начала, и это хорошее начало для вдохновения в том, как создать модуль Runbook, который будет работать для вашей команды или организации.

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

Кто должен писать Runbook?

Ответственность и ответственность должны лежать на командах. Они несут ответственность за актуальность и точность модулей Runbook. Команда SRE может предоставить шаблон для команд, но они несут за него ответственность, и каждое его изменение является совместным усилием команды.

Где следует хранить Runbook?

Runbook можно хранить в репозитории GitHub (хорошо для автоматизации) или на странице слияния, вики-странице и т. д. Здесь важно то, что их легко найти и искать во время инцидента.

Как часто следует обновлять Runbook?

Распространенная проблема с модулями Runbook заключается в том, что они устаревают. Runbook должен постоянно обновляться и содержать самую актуальную информацию. Если добавляется новая зависимость, то информация об этой зависимости должна быть добавлена ​​в документацию.

Ресурсы

Вот несколько статей, которые я бы порекомендовал для дальнейшего чтения о Runbook.

https://gitlab.com/gitlab-com/runbooks

https://sre.google/workbook/on-call/

Если вы нашли это полезным, пожалуйста, нажмите кнопку хлопка и подпишитесь на меня, чтобы получать больше статей в своей ленте.