Wheel of Misfortune: зачем это SRE и как из него извлекать пользу

Что это?
Wheel of Misfortune (иногда встречается и название вроде «Walk the Plank») - это ролевая игра про инцидент: ведущий (Game Master) задаёт сценарий - вымышленный или основанный на прошлом сбое (что приоритетнее), а «дежурный» по очереди рассказывает, что именно сделал бы: какие алерты смотрит, какие запросы к метрикам и логам, кого пингует, как эскалирует. Остальная команда наблюдает и подключается к разбору. В материалах Google SRE это описано как регулярная практика, близкая к настольной RPG: вы в «лабиринте одинаковых консолей мониторинга», цель - отработать мышление и протокол до реального пейджа (ускорение выхода на дежурство).

Чем полезно именно SRE.
Инцидент - это не только root cause, но и управление вниманием, временем, коммуникацией и эскалацией при неполной картине. WoM даёт низкий риск для прода: можно намеренно тренировать редкие сценарии и процедуры (в том числе кто командир инцидента, как объявлять major и вести коммуникации). Это симуляция, а не реальное отключение: обучение через «низкие ставки» (Google Cloud: DiRT и Wheel of Misfortune). Рядом по смыслу - координированные учения вроде DiRT, но там другой масштаб подготовки и другой профиль риска.

Как из песочницы сделать пользу - практика.
1. Сценарии из жизни. Опирайтесь на постмортемы, странные прод-кейсы и гипотезы про будущий релиз. Если нужен зерновой набор тем, посмотрите публичное обсуждение сценариев в инфраструктурных командах - например, идеи в духе failover кластера, потери ноды, жёсткой деградации и отката деплоя (issue GitLab): не готовый сценарий, а ориентир, что описывать в своих .md или JSON.
2. Дебриф с артефактом. После сессии зафиксируйте: где споткнулись о runbook или дашборд, один конкретный шаг - обновить алерт, ссылку в playbook или порог. Без этого легко уехать в «поиграли и забыли».
3. Качество ведущего. GM выдаёт последовательно то, что запросил игрок (вид графиков, вывод команд, фрагменты логов), без преждевременного «значит вот что»: как в жизни, сигнал приходит сырой (тот же материал Google Cloud).
4. Ротация и чужие углы. Меняйте дежурного на «сцене», GM и зрителей; после хода игрока собирайте альтернативные пути отладки - так смешиваются стили мышления и знания не копятся у одного человека.
5. Связка с коммуникациями. В реальном учении команды вроде GOV.UK PaaS показывают, как к техническому расследованию добавить роль коммуникаций: сцена с пейджером и smoke tests, шаблон вопросов вроде «что сделаете первым?», «что ожидаете увидеть?», отдельно - ответственные за тексты для пользователей. Это хороший образец, если хотите тренировать не только grep по логам (запись в блоге UK government technology).

Дополнительный угол.
В Open Practice Library формулируют ещё одну пользу: при грамотной подводке игра помогает проверить гипотезы о том, как ведут себя мониторинг и алертинг - не вместо реальных проверок инфраструктуры, но как разговор «ожидание vs реальность» в команде.

Инструменты и примеры контента.
Классический open-source проект - dastergon/wheel-of-misfortune: сценарии в general_incidents.json, есть sample-файл, поддержка Ink для ветвящихся интерактивных историй; демо и инструкции можно отдать команде без установки. Есть форки: у twstewart42 - например, тёмная тема и выбор «дежурного»; автор описывает ежемесячный слот, порядка двух инцидентов за час и мок blameless postmortem после сессии (пост в блоге). У alphagov/paas-unlucky-dip - вариант с бэкендом для списков сценариев, если сценарии часто меняются. Идеи формулировок «что ломаем» в учениях (в духе утёкших ключей, компрометации аккаунта) можно подсмотреть в смежных drill-гайдах - например, раздел 18F про incident response drills: это не бренд WoM, но полезный каталог заготовок для своих текстов.

Wheel of Misfortune - дешёвый по риску тренажёр инцидентного мышления, процедур и ролей. Выгода измеряется не «мы провели игру», а обновлёнными runbook’ами, более предсказуемой эскалацией и тем, что на реальном пейдже меньше трения и сюрпризов.

#SRE #WheelOfMisfortune #incident_response #oncall