Одна из самых недооценённых вещей в DevOps - подготовленные сценарии отказов.

Большинство инцидентов выглядят одинаково:

💚 02:37 ночи
💚 CPU 100%, latency растёт
💚 кто-то пишет «у нас всё легло?»
💚 начинается хаотичный SSH-тур по серверам

Проблема не в том, что система упала.
Проблема - никто не знает, что делать дальше.

Что реально спасает

Runbook, но не «для галочки».

Хороший runbook - это:

✅ конкретный триггер (какой алерт)
✅ чёткая цель (что восстановить)
✅ пошаговые действия (без “разберись по ситуации”)
✅ команды, ссылки, контакты
✅ критерий «инцидент закрыт»

Плохой runbook:

💕 «Проверь логи»
💕 «Перезапусти сервис»
💕 «Если не помогло - эскалируй»

Практика

Если runbook:

💕 не обновлялся после последнего инцидента - его не существует
💕 не может выполнить дежурный без автора - он бесполезен
💕 не проверялся в рабочее время - ночью он не сработает

Минимальный лайфхак

После каждого падения:

1. открой runbook
2. зафиксируй, где было непонятно
3. допиши одну строку

Через 5 инцидентов у тебя будет документ, который реально работает.

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