新規シナリオの追加

シナリオは「仮説を立てて壊し、観測して学ぶ」ための計画書。観測できない仮説は検証できないので、このスキルの本体は保存前のチェック関門にある(リハーサルで「フェイルオーバーが起きたのに何も観測されない」を実際に踏んだ)。

シナリオタイプ (frontmatter type)

この GameDay は中級者が AWS を学ぶハンズオン。シナリオは 2 タイプあり、チェック関門が異なる。

type	内容	主な学び	例
observe (観測型)	自己回復する仕組みに障害を注入し、挙動を観測・検証する	観測と判断 (静観の正当性、影響範囲の説明)	タスク停止、フェイルオーバー
rebuild (復旧構築型)	FIS 等でリソースを使えなくし、参加者が代替構成を手で構築して復旧させる	構築スキルそのもの + 応急処置を IaC に反映する運用	EC2 終了 → ECS 化、リージョン障害 → DR 切替

rebuild は復旧に数十分かかるため観測窓の問題は起きにくい(canary がずっと赤いのがゲームの進行表示になる)。代わりに下の「復旧経路チェック」を通すこと。

手順

1. 棚卸し — scenarios/ を読み、既存の id・学びの狙いを確認する。番号は既存最大 + 1 (NN はゼロ埋め 2 桁)。学びが重複するシナリオは追加しない(難易度違いの再実施は既存ファイルの改訂で扱う)。
2. 立案は gameday-scenario エージェントに委任する — 出力フォーマットはエージェントが知っている。依頼時に渡すもの: 対象アーキテクチャの現状 (lib/ の要点)、避けたい重複(既存シナリオの狙い一覧)、難易度・所要時間の希望。
3. 観測可能性チェック(下記)を通す — 通らない場合、観測手段の追加を「前提インフラ」に書くか、期待する振る舞い・成功条件を観測できる形に直す。
4. scenarios/NN-<slug>.md に保存する(frontmatter status: draft)。
5. ダッシュボードの参考資料 (システム構成) を連動更新する — dashboard/gameday.seed.json(定義の正。コミット対象)の systems[] に、このシナリオの「元のシステム構成図 + 軽い補足」を反映する(本物の GameDay で配られるアーキテクチャ図に相当。保存とセットで必ずやる)。実体 dashboard/public/data/gameday.json(git 管理外)にも同じ変更を入れると即時反映される(入れなくても次の周回リセットで seed から反映される):
   • 既存システムが対象 → その system の scenarioIds に新しい id を追加。「前提インフラ」で観測手段やノードが増えるなら tiers / notes にも反映
   • 新しい出発点スタックを使う → system を新規追加(未構築なら summary に明記)
   • ノードには AWS 公式アイコンのキー (icon) を付ける。キー一覧と追加方法は gameday-dashboard スキルの references/data-schema.md(未登録サービスは dashboard/src/awsIcons.ts に import + キー登録)
   • 構成は記憶で書かず lib/ の実装(または本シナリオの「前提インフラ」)から起こす。スキーマと書き方の指針は gameday-dashboard スキルの references/data-schema.md
6. 次工程を案内する: 実装は fis-experiment スキル(実装完了で status: implemented)、実施後は status: executed(講評は gameday-retrospective スキルが KPT として gameday.json の feedback[] に書く)。

観測可能性チェック(保存前の関門)

リハーサル実測値: ECS タスク自己回復 ≈ 30 秒 / Aurora フェイルオーバー ≈ 43 秒。仮説の時間見積もりはこれを基準にする。

• 障害の継続時間は観測窓より長いか? canary は 1 分間隔。1 分未満で収束する障害は canary には「起きなかったこと」になる。対処はどれか一つを明記する:
  • 継続時間を伸ばすパラメータを使う(aws:ecs:task-network-latency の duration、aws:fis:wait の挟み込み等)
  • より細かい分解能の観測(1 分粒度メトリクス、ECS/RDS イベント)を観測ポイントに含める
  • 「ユーザー影響が出ない」こと自体を成功条件に据え直す(それも立派な検証)
• プローブの種類は障害の種類と合っているか? 読み取りプローブ (SELECT 1) では書き込み断は見えない。書き込み系の障害(フェイルオーバー、ストレージ)を「見せたい」なら、書き込みエンドポイント(例: app の /write)とそれを叩く canary を「前提インフラ」に明記する。逆にリクエスト毎の短命接続は再接続に強く、接続プールを持つ実アプリより回復が速く見えることに注意。
• 検知経路を成功条件に含めたか? 「どの信号(canary / アラーム / イベント)で何分以内に気づくか」まで書く。気づけること自体が GameDay の試験項目。
• 回復時間の仮説は実測ベースか? 「数分で回復」のような保守的な見積もりは検知・採点の基準を狂わせる(実測 30 秒に対して「2〜4 分」と見積もった実績あり)。
• 振り返りの一次資料は揃うか? 観測ポイントに「FIS 実験レポート (PDF)」を書いておく — 実装時の experimentReportConfiguration 設定漏れを防ぐ(リハーサルで漏れた実績あり)。

復旧経路チェック(rebuild 型のみの追加関門)

参加者に「作らせる」以上、作れることを運営が先に保証する。

• 代替構成は制限時間内に構築可能か? 中級者 1 チームで 30〜60 分が目安。CDK を書かせるのは長すぎる — コンソール / CLI での構築を正とし、IaC 化は振り返りの宿題にする。
• 素材は用意したか? 構築に必要な材料 (ECR のコンテナイメージ、AMI、スナップショット、DR 先の VPC 等) は事前に存在しないと時間内に終わらない。「前提インフラ」に列挙する。
• 権限は足りるか? 参加者ロールで構築操作 (ECS サービス作成、Route 53 変更等) ができること。逆に対象スタック外を壊せる権限を渡しすぎない。
• 終了条件は自動判定できるか? 「canary が緑に戻る」を復旧完了の判定にする (ダッシュボードがそのまま進行表示になる)。復旧先が別 URL になる場合は canary の向き先変更が必要 — これも前提・手順に書く。
• ヒントの階段を用意したか? 学習ハンズオンなので、詰まったら 10 分刻み程度で開示する段階ヒント (方針 → 使うサービス → 具体手順) をシナリオに含める。
• drift の読み方が変わる: 参加者の新規構築リソースはスタック外なので cdk drift に出ない。drift に出るのは既存リソースへの変更 (SG 編集、desiredCount 等) のみ。振り返りでは drift + 手動作成リソースの棚卸し (タグなしリソース、コンソール操作履歴) + IaC 反映ワークの 3 点セットにする。
• 後片付けを設計したか? 手動構築リソースは cdk destroy で消えない。振り返り後に消す手順 (棚卸しリストの流用) をシナリオに含める。

採番・命名の規約

• ファイル: scenarios/NN-<slug>.md(例: 03-task-network-latency.md)
• frontmatter の id (scenario-NN) は、ダッシュボード (injects[].scenarioId / KPT 講評の scenarioId) との突き合わせキー。一度使った id は変更・再利用しない。

ライフサイクル

status: draft (立案) → implemented (fis-experiment で CDK 実装済み) → executed (実施済み)。実施の記録・講評はシナリオファイルではなく gameday.json (events[] / feedback[]) と data-archive に残る(シナリオ = 計画、講評 = 記録)。