# GameDay ## 定義 GameDay（ゲームデイ）は、事前通知なしにリアルな障害をシミュレートし、チームの対応準備態勢を検証する演習形式である。カオスエンジニアリングの実験とは異なり、個々の障害モードの技術的検証よりも**チームとしての検知・対応・復旧能力**を測ることに主眼を置く。管理された環境での「意図的な失敗」により、インシデント対応の筋肉を事前に鍛える。 Bradesco の定義: 「事前通知なしにリアル障害をシミュレートし、対応準備態勢を検証する（Simulate real failures without prior notice and validate response readiness）」（Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]] p.11） ## 実施形式（Bradesco 事例・p.11） - **目的**: Ops・Dev・SRE の 5 チーム横断で対応力を統一的に向上させる - **仕組み**: Dynatrace を RCA の「宝の地図（treasure map）」として活用しながら障害注入。終了後に構造化ポストモーテムを実施 - **規模**: 5 チーム（Ops/Dev/SRE）、10 Monkeys 注入（54% 発見）、+300 人参加者 - **成果**: より速い検知・迅速な復旧・文書化されたランブック・測定可能な改善 ## 横断的知見 - **GameDay の未発見 46% は「見つけられなかった問題」を可視化する**: Bradesco の GameDay では 10 本の Monkey 注入に対し 54% しか発見されなかった。この数値は失敗でなく「現在のオブザーバビリティと対応能力の上限」の計測値であり、改善目標の設定に使える。(Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - **「カーディオを鍛えよ」との文化的連続性**: [[レジリエンスエンジニアリング]] の横断的知見にある Ruppe（SREcon22 EMEA）の「ゲームデイ・リージョン切替訓練」推奨は、Bradesco の実践と独立に同方向を指向している。GameDay は「インシデント後に学ぶ」でなく「インシデント前に適応能力を構築する」RE 思想の実践形式である。(Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]], [[レジリエンスエンジニアリング]]) - **practice の目的は「次のインシデントの再現」ではなく「チームメイトの逸脱パターンを察知できるようになること」**: [[Thai Wood]]（[[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]]）は、ゲームデイやテーブルトップ演習で練習する理由は次のインシデントが練習内容と一致することを期待するためではなく、普段一緒に働く中で「いつもと違う」兆候（例: 普段より無口になる）を察知できるようになるためだと明言する。Bradesco の GameDay（[[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]）が「発見率」という定量指標で対応能力の上限を測るのに対し、Wood は「暗黙のチーム間コミュニケーション能力の向上」という定性的な効果を指摘しており、GameDay の効果測定に技術的発見率だけでは捉えられない次元があることを示唆する。(Source: [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]], [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - **「文書を公開しただけでは終わっていない」という Wood の主張は、GameDay がなぜ文書化(ランブック・インシデント対応計画)だけでは代替できないかの理論的根拠を補強する**: Wood は「You're not done because you published a document. There needs to be time and space to practice working together」と述べ、Dr. Richard Cook（[[Richard I. Cook]]）の「アイススケートは本を読んでは学べない」という引用を用いる。これは GameDay という実践形式そのものの存在理由（なぜ文書化だけでは不十分か）を、Bradesco の事例が示す定量的効果とは別の角度から裏付ける。(Source: [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]]) - **GameDay の「発見率」という定量成果指標に対し、Anatomy of an Incident は「何を注入対象に選ぶか」を決める上流の設計原則を提供する**: Bradesco の GameDay(10 Monkeys 注入、54% 発見)は演習の結果を測定するが、10 種のシナリオをどう選定したかまでは踏み込まない。Google の DiRT / Wheel of Misfortune を紹介する Anatomy of an Incident 2章は、直近のポストモーテムの3標準質問(何が悪かったか・何が良かったか・どこで運が良かったか)からテスト対象を選び、具体的で修正しやすい項目から着手して段階的に複雑化するという設計手順を示す。この手順を GameDay の注入シナリオ選定に適用すれば、「発見率」の低さがシナリオ設計の未成熟(単純な項目から始めきれていない)によるものか、対応能力自体の限界によるものかを切り分けやすくなる可能性がある。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]], [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - **GameDay の実施頻度は「疲弊させない・勢いを失わない」というコスト意識のもとで設計すべきだと Anatomy of an Incident は具体的に定量化する**: Bradesco 事例は+300人参加という大規模な実施報告にとどまるが、Anatomy of an Incident 2章は「運用予算の10%を割くより4週間ごとに1時間のテストの方が正当化しやすい」という具体的なペース配分の目安を示す。GameDay のような大規模・高コストな演習の実施頻度を検討する際、この目安が適用可能かは未検証である(未解決の問い参照)。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]]) - **本番実施の GameDay の前段には、卓上ロールプレイングという低コストな入門形態が存在する**: Bradesco の GameDay(10 Monkeys 注入・+300人参加)は実インフラへの障害注入を伴う高コスト・高忠実度の演習である。これに対し [[@2021__OReillyJapan__SREの探求 - Chapter 20 アクティブなティーチングとラーニング]]が記述する Google の Wheel of Misfortune・Incident Manager は、ノートPCとホワイトボード(または最大12名の卓上カードゲーム)だけで完結し、実インフラには一切触れない。両者は「事前に適応能力を構築する」という同じ思想的系譜に属しながら、前者は技術的な検知・復旧能力の実測(発見率)を、後者はコミュニケーション・調整・責任分離という人的プロセスの練習を主眼とする点で棲み分けている。GameDay という語自体は ch.20 には登場せず、Wheel of Misfortune / Incident Manager は GameDay の直接の前身とは明言されていないが、低コストな卓上演習から本番環境での高コストな障害注入演習へという難易度・忠実度のグラデーションを成す実践群として位置づけられる。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 20 アクティブなティーチングとラーニング]], [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) ## 未解決の問い - 卓上型(Wheel of Misfortune・Incident Manager)と本番注入型(Bradesco の GameDay)を難易度順に組み合わせた段階的トレーニングプログラムは、どちらか単独より高い効果を持つか。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 20 アクティブなティーチングとラーニング]], [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - Anatomy of an Incident が示す「4週間ごとに1時間」という小規模テストのペース配分の目安は、+300人・複数チーム規模の GameDay のような大規模演習にもそのまま適用できるか、それとも演習規模に応じて別のコスト計算が必要か。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]], [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - GameDay の「発見率」を KPI として追跡する場合、シナリオの難易度・注入数・チーム規模をどう統制するか？ - 事前通知なし（サプライズ型）と事前通知あり（計画型）の GameDay はどちらが何を測るのに適しているか？ - +300 人規模の参加者を巻き込む組織的調整コストと学習効果のトレードオフはどう評価するか？ - GameDay 後の構造化ポストモーテムを次の自動化シナリオ追加に繋げるサイクルはどのように設計するか？ ## 関連 - [[カオスエンジニアリング]] — GameDay の技術的基盤 - [[レジリエンスエンジニアリング]] — 「事前に適応能力を構築する」という思想的背景 - [[ポストモーテム]] — GameDay 終了後の学習サイクル - [[インシデント管理]] — GameDay が養う対応能力の適用先 - [[Thai Wood]] — practice(ゲームデイ・テーブルトップ演習)の必要性を文書化批判とセットで主張 - [[Richard I. Cook]] — 「アイススケートは本を読んでは学べない」の引用元 - [[アクティブラーニング]] — GameDay を包含する能動的学習の上位概念 - [[Laura Nolan]] — Wheel of Misfortune・Incident Manager という卓上型の前段教材の実践者 ## 出典 - [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]] (p.11) - [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]] - [[@2021__OReillyJapan__SREの探求 - Chapter 20 アクティブなティーチングとラーニング]]