Почему операционные runbook - это спасение, а не бюрократия

Когда случается инцидент, мозг отключается первым.
Остаются только привычка и инструкции.

Хороший runbook - это документ, который:

1. Снимает стресс

Когда всё горит, видеть перед собой понятный чеклист - половина успеха.
Меньше паники - меньше ошибок.

2. Повышает MTTR

Чёткие шаги ➞ предсказуемые действия ➞ быстрый возврат сервиса.

3. Уменьшает bus-factor

Заболел единственный, кто "знает, что делать"?
Не проблема — знания уже лежат в runbook.

4. Убирает хаос

Инциденты редко уникальны.
Обычно это вариации одних и тех же проблем:
«диск переполнился», «база упала», «kube-scheduler решил отдохнуть».
Runbook превращает бардак в алгоритм.



Как выглядит рабочий runbook?

Минимальная структура:

- Контекст: что за система и как понять, что она неисправна
- Триггеры: alert'ы, метрики, логи
- Диагностика: команды, которые нужно выполнить
- Решения: пошагово, без "понятно же"
- Rollback / временные костыли
- Куда эскалировать
- Что записать в postmortem



Главная ошибка инженеров

Делать runbook после инцидента.
Правильный вариант: вести их как код - постепенно дополнять при любом изменении системы.

Runbook, который не обновляли 6 месяцев — не runbook.
Это исторический артефакт.

Подпишись 👉@devopslib