War Room Patterns

«Созвонились в Zoom, тушим» — типичная реакция на SEV0 в команде, где дисциплины war room нет. Через два часа десять человек говорят одновременно, никто не помнит, что уже пробовали, клиентам не пишет никто, IC меняется неявно, через «я устал, кто-то другой», а хронологию для постмортема потом не восстановить. War Room Patterns — это дисциплина координации, когда инцидент тушат несколько команд сразу: явный Incident Commander (IC) со сменой каждые два-четыре часа, разделение ролей (IC, Ops, Comms, Scribe, SME), ритм сводок как ритуал (раз в 15–30 минут), журнал решений как след аудита, передача смены по чек-листу. Уточнение Incident Response: тот лист описывает весь жизненный цикл инцидента, этот — механику фазы гашения, когда тушат несколько команд сразу.

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

Главный навык на уровне L5 — спроектировать смену IC. Дольше двух-четырёх часов вести инцидент без потери качества не выходит: усталость, туннельное зрение, прирастание к собственной гипотезе. Я регулярно вижу инциденты на восемь часов и больше с одним IC, который к концу принимает решения хуже, чем дежурный инженер в первый час. Передача второму IC планируется заранее и включает пятиминутную сверку: текущая гипотеза, что попробовали, что не сработало. Без смены IC сам становится узким местом.

Понимает роли war room. У Google (SRE Book, гл. 14) их четыре: IC — координация и решения, не делает руками; Ops Lead — техническая mitigation; Comms Lead — внешние и внутренние коммуникации; Planning Lead — всё, что живёт дольше текущей смены (баги, передача дежурства, снабжение людьми). У PagerDuty набор другой и шире: к IC добавлены Deputy (дублёр и второй взгляд), Scribe (ведёт хронологию в реальном времени), SME (знаток конкретной системы) и две отдельные роли связи — с клиентами и с внутренними стейкхолдерами. Смешивать наборы можно, но стоит понимать, откуда что взято: Scribe — это PagerDuty, Planning Lead — это Google.
Работает как IC на инцидентах от SEV2 в своей области: открывает канал war room, объявляет роли, держит ритм сводок. Решает по правилу семидесяти процентов: ждать полной уверенности — терять время, есть семьдесят — действуй и записывай в журнал решений.
Держит ритм сводок как явный ритуал: каждые 15 минут на SEV0, каждые 30 на SEV1. Структура одна и та же: где мы сейчас / что попробовали / что делаем прямо сейчас / что дальше / что блокирует / следующая сводка в HH:MM.

Проектирует смену ролей: заранее спланированная передача второму IC и пятиминутная сверка (текущая гипотеза, что попробовано, что не работает). То же касается Ops Lead и Comms Lead.
Ведёт журнал решений отдельным артефактом: кто, что и когда решил, какие были альтернативы, как откатываемся. Главный источник для постмортема.
Проектирует передачу смены для многодневных инцидентов: документ передачи, явное переназначение всех ролей, окно пересечения на 15–30 минут.
Держит гигиену канала: один источник истины, разделение incident-${id}-warroom (исполнители) и incident-${id}-stakeholders (вещание). Никаких решений в личке, никаких параллельных war room.

L6+

Строит инфраструктуру на уровне организации: платформа для инцидентов, регулярное обучение IC, аттестация, разбор работы IC на постмортеме.
Принимает стратегические решения: круглосуточное покрытие IC, пороги эскалации к руководству, подключение юристов и пиара, оплата участия в war room.

Материалы

Книги

Site Reliability Engineering: How Google Runs Production Systems (O’Reilly, 2016), Chapter 14. Канонический заход: четыре роли (Incident Command, Operational Work, Communication, Planning), рекурсивное разделение ответственности, шаблон документа инцидента и протокол передачи. Сама глава опирается на ICS пожарных, а не изобретает модель заново. Короткая, читать целиком.
Heather Adkins et al. — Building Secure and Reliable Systems (O’Reilly, 2020), Chapter 17 «Crisis Management». Шире: инциденты безопасности, юристы, регуляторы, координация с руководством.
Site Reliability Workbook (O’Reilly, 2018), Chapter 9. Прикладные примеры из Google, разбор распределения ролей и того, что ломалось в координации. Здесь же вводится аббревиатура IMAG (Incident Management At Google) — в SRE Book гл. 14 её ещё нет.

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

PagerDuty Incident Response Documentation. Открытый playbook под Apache 2.0, который форкают и правят под себя. Внутри протоколы war room, чеклист IC, шаблоны ролей, сводок и передачи смены. По моим наблюдениям, чаще всего именно её берут как стартовый шаблон.
Atlassian Incident Management Handbook. Подробный playbook с упором на координацию. Альтернативный взгляд к PagerDuty.
Brent Chapman — Incident Command for IT: What We Can Learn from the Fire Department (LISA 2005). Тот самый доклад, который принёс NIMS / ICS (система командования, которой пожарные США пользуются с 1970-х) в мир IT-эксплуатации. История role separation идёт оттуда — и стоит отметить, что это 2005 год, за одиннадцать лет до того, как SRE-сообщество начало обсуждать роли в инцидентах как что-то новое. Обновлённая версия доклада — SREcon18 Americas.
FEMA Incident Command System (ICS-100, ICS-200 free courses). Исходная рамка, на которой стоят и PagerDuty, и IMAG у Google. Бесплатные онлайн-курсы от двух часов.
Honeycomb — How We Manage Incident Response (Fred Hebert). Разбор внутренней кухни небольшой команды: кто объявляет инцидент, как устроены роли, когда команда сознательно не разворачивает полную процедуру.

Шаблоны

PagerDuty Incident Commander training — материал под Apache 2.0 для подготовки IC: что делает, чего не делает, как ведёт совещание.
Google SRE Book: Incident State Document — шаблон живого документа инцидента прямо в главе 14; отдельного репозитория с шаблонами у Google нет.
Atlassian incident communication templates — templates для sitrep, customer updates, internal stakeholder updates.

Инструменты

Платформы для инцидентов (со встроенной поддержкой war room): incident.io (современный, с характером, живёт в Slack), FireHydrant, Rootly, PagerDuty с комнатами. Умеют они одно и то же: назначать роли, автоматически выгружать хронологию, давать шаблоны сводок, связываться со Slack, Zoom и статусной страницей. Сегмент активно консолидируется — Blameless как отдельный продукт исчез, его купил FireHydrant в 2024, — так что при выборе стоит смотреть не только на функциональность, но и на то, кому платформа принадлежит.
Совместная работа в реальном времени: Slack или Microsoft Teams (канал инцидента как основной источник), Zoom или Google Meet (голосовой мост для тяжёлых инцидентов), Slack Huddles (быстрый голос без подготовки).
Scribe / timeline tools: incident.io timeline (auto-export Slack messages в structured timeline), FireHydrant scribe, Jeli — теперь часть PagerDuty после покупки в 2023. Без инструментов роль scribe держится на одном энтузиазме.
Журнал решений как обычный артефакт: документ на инцидент в Google Docs, Notion или Confluence с явной секцией «журнал решений». Инструмент не важен, важно, что журнал существует отдельно, а не растворён в переписке Slack.

Если инцидентов, ради которых собирают war room, у вас единицы в год, отдельная платформа избыточна: канал в Slack плюс отдельный документ с decision log закрывают ровно ту же потребность. Платформа начинает окупаться там, где ролей много, инциденты идут потоком и timeline нужно собирать не руками.

Best practices

Главный публичный источник war room patterns — FEMA Incident Command System (ICS) и Google IMAG. ICS используется пожарной службой США с 1970-х годов в инцидентах, которые длятся днями (лесные пожары, ураганы). Brent Chapman показал это IT-аудитории ещё на LISA 2005: role separation, sitrep cadence, handoff protocol — не SRE-изобретение, а адаптация дисциплины, которой к тому моменту было уже тридцать пять лет, а сейчас больше пятидесяти. Меня в этой истории отрезвляет разрыв: доклад 2005 года, а команды до сих пор изобретают роли в war room заново на каждом втором проекте. Если кто-то скептичен к «формальностям war room» — отправляйте к этим источникам: ICS не работала бы полвека, если бы формальности были лишними.

Явный IC нужен даже там, где тушат двое. «Работаем вместе» без распределения означает, что решения растворяются в группе, а MTTR растёт. IC не делает руками — он координирует и принимает решения; и даже если IC и Ops Lead физически один человек, это должно быть произнесено вслух как выбор, а не получиться само собой.

Sitrep — обещание, а не отчётность. Каждые 15 минут на SEV0 или каждые 30 на SEV1 в канал инцидента уходит одно и то же по структуре сообщение: где мы сейчас, что попробовали, что делаем прямо сейчас, что дальше, что блокирует, когда следующий sitrep. Не «я там что-то писал в Slack в полночь».

Decision log живёт отдельным артефактом. Кто, что и когда решил, какие были альтернативы, как откатываемся — это не размазывается по переписке. Потом на разборе обязательно всплывёт вопрос «почему мы вообще пошли этим путём», и без лога ответ на него будет реконструкцией по памяти.

Смена IC каждые два-четыре часа — норма для затяжных инцидентов. Я регулярно вижу инциденты по шесть часов и дольше с одним IC, который под конец принимает решения хуже, чем дежурный инженер в первый час. Это не слабость. Усталость, туннельное зрение и привязанность к собственной гипотезе — физиология, и волевым усилием она не отменяется. Передача второму IC планируется заранее и включает пятиминутную сверку: текущая гипотеза, что попробовано, что не работает, какое решение висит нерешённым. Без смены качество управления инцидентом падает быстро — и незаметно для самого IC.

Передача смены в многодневном инциденте — документ, а не реплика. Без неё новая смена каждые восемь часов начинает с нуля, и инцидент растягивается вдвое. В документе: где мы сейчас, дерево гипотез, что попробовано, что работает, что нет, какие следующие шаги. Все роли переназначаются явно. Окно пересечения — 15–30 минут живой сверки, а не строчка «передаю». В регулируемых отраслях это базовая дисциплина, но полезна она везде.

Гигиена канала: один источник истины. Личка убивает координацию. Решения обсуждаются в канале или попадают в журнал, параллельные war room запрещены — иначе получаются две реальности, которые расходятся тем сильнее, чем дольше идёт инцидент. Канал исполнителей и канал стейкхолдеров разводятся: incident-${id}-warroom и incident-${id}-stakeholders. Так исполнители не отвлекаются на вопросы руководства, а руководство не тонет в жаргоне.

Game day и обучение IC — регулярно. Худший вариант первого опыта в этой роли — настоящий SEV0 в три ночи. Команда паникует, IC не уверен в себе, сводки не выходят, журнал решений пуст. Штабные игры и game day с придуманным SEV0 — единственный способ наработать мышечную память заранее. Аттестация IC и отдельный список тех, кто может им быть — а может не каждый дежурный, — следующий уровень зрелости.

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

Incident Response — тот лист про жизненный цикл одного инцидента, этот — про внутреннюю механику фазы гашения, когда координируются несколько команд.
Severity Classification — SEV0 и выше автоматически поднимают war room; уровень же задаёт ритм сводок и аудиторию.
Customer Communications — Comms Lead в war room — отдельная роль; заготовленные шаблоны сообщений живут в runbook.
On-Call Rotation — ротация IC может быть отдельной от дежурства по сервису, вплоть до круглосуточного покрытия.
Blameless Postmortem — журнал решений из war room — основной источник для хронологии в постмортеме.
Runbooks — чеклист IC, шаблон сводки и шаблон передачи смены — часть runbook для крупных инцидентов.
ChatOps — канал war room и есть холст ChatOps: боты держат ритм сводок, помогают scribe и фиксируют решения.

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

Круглосуточное покрытие IC — отдельная от дежурства по сервису ротация: когда оправдана и как её масштабировать.
Оплата участия в war room — переработки и компенсация дежурства IC; тема связана с моделями оплаты из листа про ротацию.

Не разобрана и эскалация наверх: в какой момент IC поднимает CTO или CEO в war room. Формально порог описывают через влияние на клиентов или регуляторные последствия, но живой формулировки, которая работала бы в моменте, я пока не нашёл. Рядом лежит вопрос про legal и PR — когда их подключать и как развести их работу с технической митигацией, чтобы одно не мешало другому.

Я не уверен и в том, в какой момент команда дорастает до отдельной ротации IC вместо «IC — это дежурный старший инженер». По моим наблюдениям, типичный момент — между 50 и 200 инженерами, но зависит это в первую очередь от потока инцидентов, а не от размера штата.