Runbook для инцидентов: что должно быть под рукой до первой аварии

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

Именно поэтому runbook для инцидентов нужен до того, как что-то действительно упадет. Не после постмортема, не “когда появится время”, а заранее. Иначе в момент сбоя команда работает не по процессу, а по памяти, случайным ссылкам и опыту самого старшего дежурного.

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

Что такое runbook и зачем он нужен

Runbook — это короткий рабочий документ с конкретными действиями для типового инцидента или класса проблем. Его задача не “описать систему красиво”, а помочь человеку быстро начать правильные шаги под давлением времени.

Runbook отвечает на вопрос: что мы проверяем и делаем в первые минуты, когда началась проблема.

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

Чем runbook отличается от обычной документации

У большинства команд должен быть и runbook на сервис, и общий сценарий реагирования на инциденты. Это разные по масштабу вещи.

Что обязательно должно быть внутри

Хороший признак: если по runbook новый дежурный может начать диагностику без помощи “старожила”, документ уже выполняет половину своей задачи.

Что должно происходить в первые 15 минут

1. Подтвердить инцидент и масштаб
2. Проверить технические и бизнес-метрики
3. Найти последние релизы и недавние изменения
4. Понять, нужен ли откат, флаг или другое быстрое смягчение
5. Определить владельца инцидента и канал координации

Именно эта часть документа самая ценная. Если человек в стрессе открывает runbook и сразу понимает, с чего начать, команда уже выигрывает время.

Какие ссылки и команды должны быть под рукой

• основной дашборд сервиса;

• журналы и трассировки по последним ошибкам;

• ссылки на последние релизы и фичефлаги;

• команды просмотра состояния pods, jobs, очередей и consumers;

• путь к плану отката или временному смягчению.

Чем меньше во время аварии нужно вспоминать, тем меньше команда ошибается.

Как писать runbook, чтобы он реально работал

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

• ставьте шаги выше объяснений;

• пишите коротко и однотипно;

• сначала давайте быстрые проверки, потом более глубокую диагностику;

• не перегружайте текст теорией, если она не помогает принять действие.

Плохой runbook выглядит умно, но не помогает действовать. Хороший — наоборот: может казаться простым, но экономит самые дорогие минуты.

Где хранить и кто должен поддерживать актуальность

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

У документа должен быть явный владелец: чаще всего сервисная команда, техлид, SRE или ответственный за on-call-процесс.

Что чаще всего ломает runbook на практике

• устаревшие ссылки и команды;

• документ слишком длинный и теоретический;

• никто не пересматривает его после инцидентов и релизных изменений;

• на один сервис есть несколько документов с разной логикой;

• runbook никогда не прогоняли в тренировке или game day.

Если команда во время аварии идет в чат, а не в документ, значит документ уже проиграл.

Минимальный шаблон, с которого можно начать

Сервис: ...
Симптомы: ...
Первые проверки: ...
Команды и ссылки: ...
Кого звать: ...
Как быстро снизить ущерб: ...
Кто владелец документа: ...

Что еще полезно добавить

• частые ложные срабатывания и как их отличать от реальной аварии;

• типичные причины прошлых инцидентов;

• что нельзя делать в спешке без согласования;

• какие бизнес-метрики проверять параллельно с техническими.

Главный вывод: runbook для инцидентов — это не “документ на всякий случай”, а инструмент первой реакции. Если он сокращает время между алертом и первым правильным действием, значит он работает.

Частые вопросы

Нужен ли отдельный runbook на каждый алерт?

Не на каждый, но на частые и критичные типы проблем — да. Там, где реакция часто повторяется, стандартный документ особенно полезен.

Можно ли использовать AI как основу для runbook?

Можно как черновик. Но финальная версия должна быть привязана к реальным командам, ссылкам, командам отката и текущей архитектуре.

Как понять, что runbook устарел?

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

Что важнее: краткость или полнота?

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

А лучшие вакансии для DevOps ищите на hirehi.ru