Кухня аварий на бумаге: как готовить «бумажные» плейбуки, когда мониторинг превратился в шведский стол алертов

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

Во многих командах инциденты до сих пор выглядят так:

Кого-то пейджат в 2:17 ночи
Он в панике роется в тредах в Slack, старых тикетах, «племенных» знаниях и собственной интуиции
В итоге проблему чинят… но как именно это произошло — непонятно и повторить почти невозможно

А теперь представьте, что работа с инцидентами ощущается как хорошо организованная кухня: чистые станции, понятные рецепты, каждый знает свою роль. Этого и добиваются хорошие ранбуки (incident response runbooks): превращают хаотичное «пожаротушение» в спокойную, почти скучную последовательность шагов, которые может выполнить любой дежурный.

Этот пост — о том, как построить такую «кухню» — с карандашом, бумагой и плейбуками — до того, как случится следующий пожар.

От хаоса к рецептам: что на самом деле делают ранбуки

Ранбук по реагированию на инциденты (incident response runbook) — это задокументированная пошаговая процедура для работы с определённым классом инцидентов. По сути, это рецепт:

Ингредиенты: инструменты, команды, дашборды, права доступа
Шаги: что проверять, в каком порядке и что делать дальше в зависимости от результатов
Подача: кого уведомить, как коммуницировать, когда эскалировать, что зафиксировать

Хорошо сделанные ранбуки превращают:

Героическую импровизацию → в повторяемые процессы
«Спросите у Алисы, только она знает» → в «Открой ранбук и следуй шагам»
Догадки под стрессом → в понятные решения с минимальной когнитивной нагрузкой

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

Mise en place для аварий: подготовка до пожара

В профессиональных кухнях есть понятие mise en place — «всё на своих местах». До начала сервиса повара подготавливают ингредиенты, раскладывают инструменты и организуют рабочие станции, чтобы во время нагрузки готовить без суеты.

Сильный процесс реагирования на инциденты устроен так же. Основная работа начинается до аварии:

Выделите частые типы инцидентов: например, «скачок латентности API», «ошибки подключения к базе данных», «заполненный диск», «бэклог в очереди», «всплеск неудачных логинов».
Сгруппируйте их по темам: сеть, сторидж, производительность, аутентификация, внешние зависимости и т.д.
Пишите ранбуки офлайн: на доске, в тетради, в документах — да, даже буквально карандашом на бумаге.

Момент активного инцидента — худшее время решать, как бы вам хотелось всё организовать. Вашей «кухне аварий» нужен свой mise en place:

Дашборды сохранены в закладках и прямо залинкованы в ранбуке
Диагностические команды перечислены, готовы к копипасту
Графики дежурств и пути эскалации чётко задокументированы
Шаблоны коммуникаций для статус-апдейтов подготовлены заранее

Вы документируете не только «как чинить», вы сервируете стол так, чтобы любой мог зайти и начать «готовить».

Проектирование ранбуков: от пустого листа к первому рецепту

Многие команды застревают на этапе «нам бы неплохо написать ранбуки», потому что пустой документ пугает. Шаблоны и конкретные примеры помогают сдвинуться быстро.

Практичная структура ранбука может выглядеть так:

Заголовок и область применения
- «Высокая латентность API — только веб-уровень»
- Чётко опишите, что этот ранбук покрывает, а что — нет.
Триггер / Когда использовать
- «Запускайте этот ранбук, когда api_p95_latency > 1s в течение 5 минут в проде».
- Дайте прямую ссылку на правило алерта или панель мониторинга.
Быстрая триаж (не более 5 минут)
- Убедитесь, что алерт реальный (не тест и не устаревшие данные)
- Проверьте основной дашборд / статус страницы сервиса
- Оцените влияние: сколько пользователей, какие регионы, какие критичные пути
Проверки безопасности
- «Перед любыми деструктивными действиями проверьте: текущий error rate, недавние деплои, плановые работы».
- Опасные действия явно помечайте жирным.
Пошаговое расследование
- Упорядоченный список проверок: логи, метрики, зависимости, последние изменения
- Конкретные запросы или команды
- Ссылки на нужные дашборды и инструменты
Точки решений и разветвления (branching logic)
- «Если error rate высокий, но латентность в норме → переходите к разделу 7»
- «Если затронут только один регион → переходите к разделу Региональная митигация»
Действия по митигации
- Роллбеки, feature flags, переключение трафика
- Для каждого действия — чёткие предусловия и шаги отката
Эскалация и коммуникации
- Кого пейджить дальше и в каком порядке
- Шаблоны для внутренних и внешних обновлений статуса
Критерии выхода
- «Инцидент считается митигированным, когда метрики X, Y, Z стабильны в течение 30 минут».
Заметки после инцидента

Что важно зафиксировать (таймлайн, факторы, последующие задачи)

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

Ветвящаяся логика: меньше импровизации в сложных сценариях

Не все инциденты линейные. Некоторые больше похожи на «книгу-игру», чем на прямой рецепт. Здесь нужна ветвящаяся логика (branching logic).

Представьте её как дерево решений на кухне:

Если соус слишком густой → добавить бульон
Если слишком солёный → разбавить или уравновесить кислотой

В ранбуках это выглядит так:

Точки решений, описанные простым языком
- «CPU базы данных > 90% дольше 10 минут?»
- «Ошибки повышены во всех регионах или только в одном?»
Понятные ветки
- «Если да → следуйте по пути A (масштабирование, шардинг, фейловер)»
- «Если нет → путь B (расследуем приложение, последние изменения кода)»

Хорошая ветвящая логика:

Уменьшает потребность в глубоком знании системы в разгаре инцидента
Не даёт людям пропускать критичные проверки
Держит команду синхронизированной, когда несколько человек идут по одному плейбуку

Ранбук не обязан быть сложным. Даже от руки нарисованная блок-схема, сфотографированная и добавленная в документацию, — уже полезный старт.

Измеряем эффект: MTTA, MTTR и устойчивость

Ранбуки — это не просто «красивая документация». Они должны заметно улучшать ключевые метрики надёжности:

Mean Time to Acknowledge (MTTA) — среднее время до подтверждения инцидента
- С чёткими триггерами и ответственными алерты подтверждаются быстрее.
- Новые дежурные не мнутся, потому что вопрос «и что теперь делать?» уже закрыт.
Mean Time to Resolve (MTTR) — среднее время до решения
- Меньше тупиков и дублирования работы.
- Диагностика стандартизирована: первые 10 минут расследования всегда одинаковы.
- Типовые митигирующие действия описаны, безопасны и исполняются быстро.
Общая устойчивость системы (resilience)
- Пишя ранбуки, вы находите хрупкие места и пробелы в знаниях.
- Повторяющиеся паттерны инцидентов становятся очевиднее, и вы делаете структурные улучшения.

Если ваши ранбуки не помогают MTTA/MTTR, воспринимайте это как обратную связь: они либо слишком размытые, либо их трудно найти, либо они не вшиты в реальные рабочие процессы.

Свежесть рецептов: сопровождение, ревью и трекинг

Протухший ранбук во время аварии — как рецепт, который требует ингредиенты, которых нет, и технику, которая не работает. Он замедляет и убивает доверие.

Чтобы ранбуки оставались полезными:

Проводите регулярные ревью
- Раз в квартал или после крупных архитектурных изменений
- Указывайте дату следующего пересмотра в шапке документа
Обновляйте после каждого релевантного инцидента
- Какие шаги были непонятны или отсутствовали?
- Где люди импровизировали вне ранбука?
- Какие команды/дашборды изменились?
Трекьте исполнение
- Даже простая отметка «Шаги 1–7 сделаны, 8 пропущен» уже помогает
- Используйте incident tooling, который позволяет встраивать/прикреплять ранбуки и отмечать прогресс
Агрессивно чистите
- Объединяйте или удаляйте неиспользуемые или устаревшие ранбуки
- Цель — аккуратная, курационная коллекция, а не кладбище старых доков

Ваша «кухня» должна ощущаться актуальной и организованной, а не как ящик со старыми меню доставки.

Встраиваем ранбуки в общий процесс работы с инцидентами

Ранбуки дают максимум пользы, когда это не просто статичные документы в вики, а часть рабочего контура:

От алерта к действию
- Каждый алерт ссылается напрямую на конкретный ранбук или дерево решений
- Дежурный может пройти путь пейджер → ранбук → дашборды без лишнего поиска
Внутри инструментов для инцидентов
- Встраивайте ранбуки в систему управления инцидентами
- Дайте возможность отмечать выполненные шаги и добавлять заметки прямо там
Во время обучения и учений
- Используйте ранбуки на game days и tabletop-упражнениях
- Позвольте новым членам команды прогонять их от начала до конца

Когда мониторинг — это «шведский стол» сигналов и шума, ранбуки — это способ «подать на тарелку» именно то, что нужно в каждой конкретной ситуации.

Вывод: начните с одного карандаша и одного плейбука

Не нужен идеальный, полностью автоматизированный процесс, чтобы начать. Вам нужно лишь:

Один частый тип инцидента
Один простой, честный ранбук
Одно место, где его точно найдут все

Напишите первую версию хоть карандашом. Зафиксируйте то, что ваши эксперты и так делают по памяти. Превратите это в понятный, ветвящийся «рецепт», который любой сможет исполнить в 2 часа ночи.

Дальше улучшайте его после каждого инцидента. Добавляйте новые ранбуки там, где они дадут максимум эффекта. Привяжите их к алертам. Отслеживайте использование. Держите вашу «кухню аварий» организованной, подписанной и всегда готовой.

Когда в следующий раз мониторинг накроет вас «шведским столом» алертов, вы будете рады, что плейбуки уже лежат рядом — подготовленные, отточенные и доступные, чтобы «готовить» среди хаоса по спокойным, повторяемым шагам.