Playbooks

«Playbook и runbook — это одно и то же?» — вопрос, который я слышу почти от каждой команды, у которой первый раз появляется инцидент с двумя командами в war room. Терминология в индустрии действительно плавающая: Google SRE Workbook называет «playbook» то, что в индустрии DevOps обычно зовут runbook. Я придерживаюсь различения, которое закрепилось в incident-response сообществе после PagerDuty / incident.io в 2020-х: runbook — это конкретные шаги для одного симптома («увидел 5xx > 1% → выполни шаги 1-N»); playbook — это сценарий реагирования для класса инцидентов: роли, точки решения, ритм коммуникации, порядок эскалации. Лист — про playbook’и; про runbook’и — соседний лист Runbooks, который явно вынес обсуждение границы как TBD; этот лист её закрывает.

Один способ почувствовать разницу: на инциденте «data corruption в primary DB» runbook ответит на вопросы «как проверить целостность? как переключиться на реплику?». Playbook ответит на вопросы «кого позвать? что говорим клиентам сейчас и через час? в какой момент решаем не восстанавливать данные, а пересоздать таблицу? кто принимает решение?». Это разные документы и разные навыки. Runbook читает on-call инженер; playbook читает Incident Commander.

Что должен уметь

Главный навык на уровне L5 — проектировать playbook так, чтобы он работал при стрессе IC, а не выглядел красиво на ревью. Я регулярно вижу двенадцатистраничные playbook’и с матрицей решений на тридцать строк — в инциденте их не открывают, потому что IC не успевает столько прочитать. Рабочий playbook умещается на одну страницу: роли в две-три строки, первые действия в пять-семь шагов, три-четыре явные точки решения, эскалация (когда и кому), ритм коммуникации (когда обновлять статус). Всё остальное — в приложениях, которые открываются по ссылке.

Понимает разницу между playbook и runbook; знает, какие playbook’и команда использует; следует роли, назначенной в playbook (responder, scribe, comms).

Пишет playbook для известного класса инцидентов своего сервиса: роли, первые действия, точки решения, критерии эскалации, ритм коммуникации. Обновляет после каждого инцидента, в котором playbook использовался.
Различает playbook’и по severity: SEV1 и SEV3 — это разные роли, разная интенсивность и разные коммуникации. Не использует один документ на все уровни.

Проектирует семейство playbook’ов для команды или сервиса: обычный инцидент, инцидент безопасности, повреждение данных, исчерпание ёмкости, авария у поставщика. Держит общую структуру между ними.
Встраивает playbook в поток работы с инцидентом: команда ChatOps (/incident declare) подтягивает нужный документ в канал war room, роли распределяются автоматически, чеклист рендерится сам.
Раз в квартал пересматривает playbook’и: какие открывались и как часто, какие шаги сработали, какие нет. Playbook без использования за полгода либо удаляется, либо инспектируется.

L6+

Внедряет практику playbook на уровне всей организации: единая структура, шаблоны, обмен между командами, управление актуальностью.
Связывает playbook с regulatory обязательствами там, где они есть (PCI-DSS incident response, GDPR breach notification, SOC 2): playbook становится артефактом для аудита, а не только рабочим документом.

Материалы

Книги

Betsy Beyer et al. — The Site Reliability Workbook (O’Reilly, 2018), глава 8 «On-Call». Google использует «playbook» как обобщённое слово, но описанная структура (severity, impact, debugging suggestions, mitigation) почти совпадает с тем, что сегодня называют playbook в incident.io и PagerDuty. Полезно как отправная точка.
Atlassian — Incident Management Handbook (живой документ). Самый детальный публичный гайд по структуре playbook’а в индустрии 2020-х. Разделы про severity, коммуникации и постмортем читаются как справочник.

Статьи и доклады

PagerDuty Incident Response Documentation. Публично выложенный playbook PagerDuty: роли (IC, Deputy, Scribe, Subject Matter Experts), severity playbook, training playbook. По моим наблюдениям — самый часто адаптируемый референс в индустрии. Команды берут его как заготовку и подгоняют под себя.
Google SRE Book, Chapter 14 «Managing Incidents». Принципы incident command, заимствованные из ICS — системы управления пожарными расчётами: явные роли, слаженность, спокойствие под давлением. Это философская основа playbook’ов, читается до конкретных шаблонов.
Материалы incident.io — их руководство по управлению инцидентами с разбором типовых сценариев. По моим наблюдениям, полезнее всего именно как набор стартовых точек, а не готовых документов: скопировать чужой playbook целиком не выйдет, он всегда про чужую систему.

Инструменты

Markdown в репозитории команды — базовый формат, как и для runbook’ов. Ревью через pull request, история в git, поиск работает. Я регулярно вижу, что зрелые команды держат playbook’и в одном репо с runbook’ами, под разными директориями.
incident.io / FireHydrant / Rootly — платформы управления инцидентами, где playbook — полноценная сущность: объявили инцидент → платформа сама подобрала сценарий → роли разошлись в Slack → чеклист отрисовался в канале war room. По моим наблюдениям, оправданы от полусотни инженеров и при инцидентах не реже раза в неделю. В команде из десяти человек это перебор, markdown справится.
Netflix Dispatch — open-source альтернатива платным платформам. Playbook как код, интеграция со Slack, PagerDuty и Jira. Берут те, кто не хочет зависеть от чужого сервиса.
Команда ChatOps /incident declare <type> — самый частый способ привязать playbook к инциденту в моменте. Бот создаёт war room, публикует первый чеклист, тегает IC. См. ChatOps для деталей.

Best practices

Главный публичный кейс — PagerDuty Incident Response Documentation. PagerDuty выложила свои внутренние playbook’и в открытый доступ в 2017 году. На момент написания листа это самый цитируемый источник в индустрии: роли IC / Deputy / Scribe / SME, отдельный playbook про подготовку новых IC, playbook по severity с явной матрицей решений, playbook по коммуникациям. Уникальность этого источника не в том, что они «правильные» — а в том, что они публично доступны и адаптируемы. Команды берут их за основу и подрезают под себя: часть ролей объединяют, шкалу severity упрощают. Через две-три итерации получается рабочий документ, и структуру для него не пришлось изобретать. Если читаете лист и впервые внедряете playbook — начните с PagerDuty, дальше — incident.io библиотека.

Playbook пишется на класс инцидентов, а не на один конкретный. Единый документ «на любой инцидент» не работает: нужно семейство по типу — база, сеть, безопасность, поставщик, исчерпание ёмкости — и внутри него разделение по severity. Один playbook равен одному повторяющемуся сценарию, а не одному случаю из прошлого квартала.

Дальше — размер. Двенадцать страниц с матрицами в моменте инцидента не читает никто, тем более IC, у которого параллельно горят три чата. На быстрый доступ отводится ровно одна страница: роли, первые шаги, точки принятия решения, эскалация, коммуникации. Всё остальное уезжает в приложения за ссылками.

И третье — связь с severity должна быть явной. SEV1 тянет за собой уведомление руководства, публичную статус-страницу, war room на десяток человек. SEV3 — это IC и один эксперт, которые тихо чинят без всякой эскалации. Применить документ SEV1 к SEV3 значит выжечь команду на ровном месте, а обратная ошибка стоит пропущенной эскалации.

Playbook без тренировки работает только один раз. Я регулярно вижу команды, у которых playbook’и записаны качественно, но в моменте инцидента IC не открывает их — потому что никогда не открывал раньше, не помнит структуры, ищет в Confluence по поиску. Playbook живёт мышечной памятью: его открывают на каждом game day, прогоняют по ролям, находят дыры. Без game day playbook остаётся знанием, не навыком. Тренировочная сторона практики разобрана в Game Day / Chaos Drills.

Точки решения — главное, что отличает playbook от runbook. Runbook отвечает на вопрос «что делать» и состоит из команд. Playbook отвечает на вопрос «в какой момент что решать». Вот формулировки из playbook’ов, которые я видел работающими: «тридцать минут без результата — эскалация к руководству»; «потеря данных больше пяти минут — взвешиваем переключение на реплику с потерей против восстановления основной базы»; «затронуто больше 10% клиентов дольше пятнадцати минут — публикуем на статус-странице». Это не шаги, а решения, которые без документа принимаются на ходу и потом разбираются в постмортеме.

Playbook правится постмортемом, а не лежит в резерве. Главный источник правок — разборы. Шаг, который IC не вспомнил, становится новой точкой решения. Сообщение, которое ушло с опозданием, меняет ритм коммуникации. Эскалация, случившаяся поздно, уточняет критерий. Без регулярных правок playbook устаревает быстрее runbook’а, потому что вместе с компанией меняется и структура инцидентов. Я регулярно вижу документы, которые ссылаются на должности, которых в компании больше нет, или на архивированные каналы в Slack. Это не playbook, это исторический документ.

Роль IC зависит от severity. На SEV3 IC может быть on-call инженер, который ведёт инцидент сам. На SEV1 это должен быть отдельный человек, не влезающий в техническое расследование. Правило пришло из ICS и нарушается чаще прочих: IC и Ops Lead оказываются одним лицом, и тогда проседает координация, опаздывают сообщения, запаздывает эскалация. Playbook SEV1 явно фиксирует разделение ролей; SEV3 playbook — допускает совмещение.

Связанные листья

Runbooks — runbook отвечает «как делать», playbook — «что решать и кого звать». Runbook’и встраиваются в playbook’и как ссылки на конкретные шаги; playbook без runbook — обещание, runbook без playbook — фрагмент.
Incident Response — playbook’и — главный артефакт этой практики; частота их реального открытия — прямой показатель зрелости реагирования.
Severity Classification — playbook выбирается по severity; чёткая матрица severity — предпосылка работающего семейства playbook’ов.
Customer Communications — ритм коммуникаций — часть playbook’а; матрица «severity → канал → частота» живёт там же.
War Room Patterns — playbook описывает, когда открывать war room, кого звать и как закрывать; сами паттерны разобраны там.
Game Day / Chaos Drills — playbook’и тренируются на game day; документ, который никто ни разу не открывал, навыком не становится.
ChatOps — playbook привязывается к инциденту командой вида /incident declare; современные платформы управления инцидентами и есть ChatOps, живущий прямо в Slack.
Status Page Management — обновление публичной статус-страницы — шаг в коммуникационной секции playbook’а; частота обновлений задаётся там же.

Открытые вопросы

Терминология в индустрии так и не сошлась. Сообщество вокруг реагирования на инциденты различает runbook и playbook явно, а Google SRE Workbook пользуется словами как синонимами. Если в вашей команде закрепился свой вариант — это нормально: важно, чтобы определение было записано, а не совпадало с чужим. Терминологический холивар точно не стоит того, чтобы из-за него playbook остался ненаписанным.

Второй вопрос — playbook как обязательный артефакт для регуляторов. PCI-DSS, GDPR и SOC 2 требуют документированного плана реагирования, и я не уверен, как правильно совмещать короткий рабочий документ с формальным и подробным. Скорее всего, это два документа с перекрёстными ссылками. Рабочей публичной практики на эту границу я не встречал, так что если у вас есть опыт — расскажите через PR.

Отдельно наблюдаю за генерацией playbook’ов ассистентом на основе сервиса, архитектуры и прошлых инцидентов. На начало 2026 года это активная область экспериментов (incident.io AI, FireHydrant AI), но рабочих кейсов в публичной литературе пока мало.