Game Day / Chaos Drills

«Game day мы провели в прошлом году, всем понравилось, отметили в OKR». Эту фразу я слышу регулярно. Это не game day, это мероприятие для отчёта. Работает только регулярный ритуал: ежемесячный внутри команды, ежеквартальный между командами, ежегодный полномасштабный на уровне всей организации. Цель не в том, чтобы найти баги или проверить chaos tooling. Цель — перевести реакцию на инцидент из теоретического знания в мышечную память, удержать калибровку команды по мере смены людей и инфраструктуры, найти дыры в runbook’ах и наблюдаемости раньше, чем их найдёт прод. Этот лист — про культурную сторону практики; метод проверки гипотез о системе разобран в соседнем листе Chaos Engineering.

Game day и chaos engineering — разные инструменты с пересекающейся областью. Chaos engineering — метод: эксперимент от гипотезы, который может идти автоматически и непрерывно, вообще без участия людей. Game day — ритуал: запланированное событие, на котором команда отыгрывает реакцию на инцидент. Игра может опираться на инструменты инъекции вроде Chaos Mesh или AWS FIS, а может пройти целиком за столом, в формате Wheel of Misfortune, без единого сломанного сервиса. Граница проходит не между «технически» и «организационно». Она проходит между проверкой системы и тренировкой команды.

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

Главный навык на уровне L5 — проектировать game day так, чтобы сценарий учил, а не превращался в шоу. Я регулярно вижу две крайности: либо сценарий тривиальный («перезагрузим pod, посмотрим как HPA отработает») и команда теряет интерес ко второй итерации, либо сценарий нагромождён («кладём БД + DNS + Kafka одновременно») и команда теряет понимание, что именно она сейчас тренирует. Рабочий сценарий тренирует одну явную способность — дисциплину эскалации, выполнение runbook, ритм коммуникаций, передачу роли — и оставляет место для правдоподобной растерянности, но не для коллапса.

Понимает разницу между game day, wheel of misfortune и chaos experiment. Участвует в game day своей команды как responder.
Читает runbook’и заранее перед game day; в момент тренировки следует им, фиксирует места, где runbook был неясен или устарел.

Фасилитирует Wheel of Misfortune для своей команды: выбирает прошлый или придуманный инцидент, описывает входной сигнал, ведёт обсуждение, фиксирует «что бы вы сделали → почему → откуда узнаете, что сработало».
Готовит сценарий для staging: инъекция (через chaos tooling или вручную), чеклист наблюдаемости для проверки сигнала, прогон по runbook, условие остановки, шаблон разбора после игры.

Проектирует quarterly game day календарь для команды: scenarios варьируются (network / dependency / data / human-error / process), сложность растёт инкрементально, каждый game day тренирует одну явную способность.
Запускает game day в production с minimal blast radius (1% traffic / 1 instance / single region) с явными условиями остановки и наблюдаемостью как воротами. Только после того, как цикл на staging стабильно работает.
Ведёт post-game review: factual timeline, findings (что сработало / что нет), action items с владельцем и дедлайном; следит за их закрытием до следующего game day.

L6+

Внедряет game day как регулярную практику в нескольких командах / org-wide. Согласует cadence, scenarios sharing, cross-team drill, executive buy-in.
Проектирует full-scale exercise (DiRT-style): multi-team, multi-day, multi-region. Включая communications protocol, command center, regulatory implications.

Материалы

Книги

Betsy Beyer et al. — Site Reliability Engineering (O’Reilly, 2016), глава 28 «Accelerating SREs to On-Call and Beyond». Источник Wheel of Misfortune как формализованной практики. Сам главу не читал — формат знаю по рассказам коллег, которые его у себя гоняли, и именно в этом виде он разошёлся по индустрии.
Casey Rosenthal, Nora Jones — Chaos Engineering: System Resiliency in Practice (O’Reilly, 2020), главы про GameDay structure и blast radius management. Не читал; лежит в списке по совету коллег, которые занимаются chaos engineering всерьёз, — за технической стороной учений с реальной инъекцией они отправляют сюда.
Kripa Krishnan — Weathering the Unexpected (ACM Queue, 2012). Не книга, но обязательно к прочтению: как Google запустил DiRT и что из этого вышло. Самый ценный единичный источник про full-scale drill.

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

Wheel of Misfortune (SRE Book, глава 28 «Accelerating SREs to On-Call and Beyond»). Описание формата ролевой тренировки: ведущий берёт реальный прошлый инцидент, участник отыгрывает дежурного. Команде без ритуала советую начинать с него: порог входа нулевой, нужны ведущий, час времени и один прошлый постмортем.
AWS GameDay — программа AWS для внешнего обучения incident response. Пробовал заводить такой формат у себя: до регулярного ритуала не дошло, я ушёл из компании раньше, но впечатление осталось хорошее. Смотреть стоит как референс формата — тайм-бокс, оценка, разбор после игры, — даже если AWS вы не используете.
Aaron Blohowiak (Netflix) — FIT: Failure Injection Testing (Netflix Tech Blog, 2014). Эволюция от game day к continuous chaos; объясняет, где game day упирается в потолок и нужны automated experiments.
Ɔhaos Ǝnginǝǝring @ Target (Target Tech Blog). Один из немногих публичных взглядов изнутри на то, как крупная компания встраивает game day в обычную работу: cadence, участники, что делают с находками.

Инструменты

Сценарий в markdown, лежащий в git — основной артефакт game day: входной сигнал, ожидаемый runbook, условия остановки, чеклист наблюдаемости, критерии оценки. Без документа сценарий рассыпается на устные договорённости и через квартал не воспроизводится.
postmortem-templates — публичные постмортемы как источник сценариев. По моим наблюдениям, лучшие сценарии — это реальные инциденты других компаний, натянутые на свой стек. Дешевле и реалистичнее, чем выдумывать.
Chaos Mesh / AWS Fault Injection Service — инструменты инъекции отказов для game day с реальным воздействием. Про выбор подробно в листе Chaos Engineering. Здесь важнее сторона безопасности: явное условие остановки и фиксированный blast radius, а не «посмотрим, как пойдёт».
PagerDuty / Opsgenie на тестовом сервисе — отдельный тестовый пейджер для game day, чтобы не путать сигналы. Настоящий поток алертов, настоящий пейджер, реакция как в бою.
Настольный формат без инструментов — лист бумаги, ведущий, команда вокруг стола. Wheel of Misfortune в чистом виде. Самый дешёвый вариант и один из самых полезных. Недооценивать его не стоит.

Best practices

Главный публичный кейс — Google DiRT (Disaster Recovery Testing). Kripa Krishnan описывает в ACM Queue 2012, как Google проводит запланированные full-scale exercises: команды тренируют коммуникации и проверяют business continuity на масштабе компании. DiRT — не непрерывный chaos engineering, а ритуал с командным центром, расписанием, ролями и поддержкой руководства. Из статьи можно безопасно вынести два практических правила: у каждой находки есть владелец, а сценарии обновляются вслед за системами. Точного универсального отношения «ценность / стоимость» для tabletop статья не задаёт, поэтому его лучше измерять внутри своей программы учений.

Дальше — три вещи, без которых ритуал не складывается.

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

У одной игры — одна цель тренировки. «Кладём всё разом, посмотрим, что выйдет» — самый быстрый способ получить хаос вместо урока: команда перестаёт понимать, что именно она отрабатывает. Один сценарий — одна способность: эскалация, выполнение runbook, ритм коммуникаций, передача роли. Усложнять можно между играми, но не внутри одной.

Условие остановки и blast radius фиксируются до начала. В момент, когда стало «что-то не так», договориться уже не получится, поэтому abort описан заранее: burn rate SLO выше порога, error rate выше порога, замечено влияние на клиентов — немедленная остановка, уборка, разбор. Без этого game day однажды становится настоящим инцидентом.

Wheel of Misfortune — недооценённый формат. Я регулярно вижу команды, которые сразу берутся «по-взрослому»: staging, инструменты инъекции, полдня, полная наблюдаемость. Дорого. Требует инфраструктуры — и чаще всего именно поэтому не запускается вовсе. Настольный вариант из SRE Book (гл. 28) устроен проще: ведущий описывает входящий алерт, команда вслух разбирает, что сделала бы и откуда узнала бы, что сработало. Час времени, ноль инфраструктуры. Для команды, у которой ритуала ещё нет, я считаю осмысленным ровно один первый шаг — месяц настольных игр до первой попытки инъекции на staging. Дешевизна даёт регулярность, регулярность делает ритуал, ритуал даёт мышечную память.

Разбор после игры важнее самой игры. Самая частая поломка ритуала на моей памяти выглядит так: game day прошёл, всем понравилось, находки улетели в канал Slack, и туда никто больше не заглянул. Через квартал команда не помнит ни находок, ни того, чем был неясен runbook. Рабочий разбор состоит из фактического таймлайна, списка «что сработало / что нет», правок в runbook, пробелов в наблюдаемости и задач с владельцем и сроком. Первый пункт следующей игры — проверка задач с прошлой. Без этой петли ритуал превращается в развлечение.

Game day для всей команды, а не только для новичков. Wheel of Misfortune часто считают инструментом онбординга (см. SRE Onboarding). Это верно, но это лишь часть ценности. Основная — постоянная калибровка тех, кто работает давно. Люди отходят от процесса, runbook’и устаревают вместе с инфраструктурой, пробелы в наблюдаемости копятся незаметно. Команда теряет навык, не замечая потери, и узнаёт о ней в три ночи на реальном инциденте. Регулярная игра здесь работает как пожарная тревога в офисе: участвуют все, не только новенькие.

Культурные предпосылки: режим blameless, постмортемы, дисциплина runbook. Те же три, что и для chaos engineering (см. соседний лист). Если находка с game day превращается в «кто это пропустил в runbook», петля обратной связи сломана, и через две-три игры люди перестают участвовать всерьёз. Порядок внедрения такой: постмортем в режиме blameless, затем рабочая практика runbook, и только потом game day. Без первых двух практика не работает вовсе: игра превращается в машину по поиску виноватых и теряет смысл за квартал.

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

Chaos Engineering — метод проверки гипотез о системе; может использоваться в game day, но scope шире (continuous, automated). Game day — ритуал, chaos — метод; пересекаются, но не дублируются.
Incident Response — game day тренирует именно этот процесс: роли, escalation, sitrep, mitigation vs investigation. Без working incident response practice game day не имеет, что тренировать.
SRE Onboarding — Wheel of Misfortune для onboardee — частный случай game day. Здесь — про continuous calibration команды, там — про скрипт первых недель.
Postmortem Culture — game day findings обрабатываются через постмортем-формат; качество разборов = качество сценариев для будущих drill’ов.
Runbooks — game day — основной механизм валидации runbook’ов: если шаги не сработали — runbook outdated. Без drill’а вы узнаёте об этом в реальном инциденте.
Severity Classification — scenarios варьируются по severity; game day тренирует correct severity declaration без давления реального инцидента.
On-Call Rotation — game day с participation новых on-call инженеров — основная подготовка перед первой неделей; снижает MTTR и тревожность.
Communities of Practice — cross-team game day и sharing сценариев между командами — типичная активность CoP по reliability.
Postmortem Database — главный источник сценариев game day; реальные прошлые инциденты лучше любых вымышленных.
Playbooks — playbook без training работает один раз; game day — место, где playbook’и тренируются и обнаруживаются их пропуски.
DR Policy & Stakeholders — annual DR exercise (full-scale tabletop + functional drill) — это game day в DR-scope. Здесь — тренировочная сторона; там — policy и stakeholder map, которые учения и проверяют.

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

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

Второе, в чём я не уверен: как проводить game day там, где дежурство идёт круглосуточно и любая запланированная игра неизбежно накладывается на реальную нагрузку. Возможно, ответ — настольный формат в асинхронном виде. Рабочей публичной практики я не встречал, так что если у вас есть опыт — расскажите через PR.