Почему операционные runbook - это спасение, а не бюрократия Когда случается инцидент, мозг отключается первым. Остаются только привычка и инструкции. Хороший runbook - это документ, который: 1. Снимает стресс Когда всё горит, видеть перед собой понятный чеклист - половина успеха. Меньше паники - меньше ошибок. 2. Повышает MTTR Чёткие шаги ➞ предсказуемые действия ➞ быстрый возврат сервиса. 3. Уменьшает bus-factor Заболел единственный, кто "знает, что делать"? Не проблема — знания уже лежат в runbook. 4. Убирает хаос Инциденты редко уникальны. Обычно это вариации одних и тех же проблем: «диск переполнился», «база упала», «kube-scheduler решил отдохнуть». Runbook превращает бардак в алгоритм. Как выглядит рабочий runbook? Минимальная структура: - Контекст: что за система и как понять, что она неисправна - Триггеры: alert'ы, метрики, логи - Диагностика: команды, которые нужно выполнить - Решения: пошагово, без "понятно же" - Rollback / временные костыли - Куда эскалировать - Что записать в postmortem Главная ошибка инженеров Делать runbook после инцидента. Правильный вариант: вести их как код - постепенно дополнять при любом изменении системы. Runbook, который не обновляли 6 месяцев — не runbook. Это исторический артефакт. Подпишись 👉@devopslib