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

Одна из самых недооценённых вещей в DevOps - подготовленные сценарии отказов. Большинство инцидентов выглядят одинаково: 💚 02:37 ночи 💚 CPU 100%, latency растёт 💚 кто-то пишет «у нас всё легло?» 💚 начинается хаотичный SSH-тур по серверам Проблема не в том, что система упала. Проблема - никто не знает, что делать дальше. Что реально спасает Runbook, но не «для галочки». Хороший runbook - это: ✅ конкретный триггер (какой алерт) ✅ чёткая цель (что восстановить) ✅ пошаговые действия (без “разберись по ситуации”) ✅ команды, ссылки, контакты ✅ критерий «инцидент закрыт» Плохой runbook: 💕 «Проверь логи» 💕 «Перезапусти сервис» 💕 «Если не помогло - эскалируй» Практика Если runbook: 💕 не обновлялся после последнего инцидента - его не существует 💕 не может выполнить дежурный без автора - он бесполезен 💕 не проверялся в рабочее время - ночью он не сработает Минимальный лайфхак После каждого падения: 1. открой runbook 2. зафиксируй, где было непонятно 3. допиши одну строку Через 5 инцидентов у тебя будет документ, который реально работает. Подпишись 👉@devopslib