【テンプレあり】英語ゲームデイ計画書の書き方｜SRE・インフラチームで使える日英フォーマット付き

英語でGame Day（障害訓練）の計画書を書くよう求められたとき、何を準備すればいいか迷った経験はないだろうか。

Game DayはNetflixのChaos Engineeringから広まった障害訓練の手法だ。意図的に障害を発生させ、チームの対応力と復旧手順を検証する。5つのセクション構成さえ押さえれば、英語でも問題なく計画書を書ける。

この記事では、英語Game Day計画書に必要な5つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次の障害訓練で活用できる。

Game Day計画書に必要な5つの構成要素

Game Day（ゲームデイ）計画書は障害訓練の目的・シナリオ・手順・評価基準を事前に定義するドキュメントだ。以下の5つが標準的な構成要素になる。

基本情報・目的（Overview & Goals）
訓練シナリオ（Scenarios）
実施手順（Execution Plan）
評価基準（Success Criteria）
結果・振り返り（Results & Retrospective）

Chaos EngineeringとGame Dayの違い

Chaos Engineeringは「本番環境で継続的に障害を注入し、システムの弱点を発見する」エンジニアリング手法全体を指す。Game Dayはその中の「計画された訓練イベント」だ。事前に参加者・シナリオ・評価基準を定め、チームで対応力をテストする演習として位置づけられる。

なぜ英語で書くのか

グローバルSREチームでは、Game Day計画書がインシデント対応や復旧手順（Runbook・DRP）と同じリポジトリで英語管理される。英語で書くことで、海外メンバーも同じ基準で訓練に参加でき、事後のポストモーテムとも一貫性が保てる。

障害復旧計画書（DRP）の書き方は英語障害復旧計画書の書き方でも確認してほしい。

テンプレートをダウンロード（Word）

以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。

📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)

日本語版テンプレート（コピペOK）

基本情報・目的

項目	内容
訓練名	（例：決済サービスフェイルオーバー訓練 2026-Q3）
実施日時	（例：2026年8月20日 10:00〜13:00）
対象システム	（例：決済APIサービス・DBクラスター）
実施チーム	（例：バックエンドSREチーム）
ファシリテーター	（名前）
目的	（例：マルチリージョンフェイルオーバー時のRTO（目標復旧時間）30分以内を検証する）

訓練シナリオ

#	シナリオ名	注入する障害	想定影響
1	（例：プライマリDB障害）	（例：プライマリDBへのネットワーク遮断）	（例：決済APIが503を返す。レプリカへのフェイルオーバーが自動で発動する）
2	（例：キャッシュ全消去）	（例：Redisクラスターの全キー削除）	（例：APIレスポンスタイムが急増する。DBへの直接アクセスが増加する）
3	（例：リージョン障害シミュレーション）	（例：ap-northeast-1リージョンへのトラフィックを遮断）	（例：ap-southeast-1へのフェイルオーバーが発動する）

実施手順

#	ステップ	担当	所要時間	確認方法
1	（例：前提確認：ダッシュボード正常・アラート無効化）	SREリード	10分	Datadogで全グリーン確認
2	（例：シナリオ1実施：DBネットワーク遮断）	インフラ担当	5分	iptablesコマンド実行
3	（例：フェイルオーバー観測・復旧対応）	全員	30分	Datadogアラート・ログ確認
4	（例：復旧確認：APIレスポンス正常化）	SREリード	10分	ヘルスチェックエンドポイント確認
5	（例：シナリオ2〜3を繰り返し実施）	全員	60分	各シナリオ後に評価基準を確認
6	（例：振り返りミーティング）	ファシリテーター	30分	事後テンプレートを記入

評価基準

指標	目標値	測定方法
RTO（目標復旧時間）	30分以内	障害注入からAPIヘルスチェック正常化までの時間
RPO（目標復旧時点）	5分以内のデータ損失	DBレプリカのレプリケーション遅延
アラート検知時間	2分以内	障害注入からPagerDutyアラート発報までの時間
手順書（Runbook）の完全実施	100%	Runbookの全ステップを手順書通りに実施できたか

結果・振り返り

項目	内容
実施日	（例：2026-08-20）
実施したシナリオ	（例：シナリオ1・2を実施。シナリオ3は時間不足でスキップ）
評価基準の達成状況	（例：RTO 28分で達成。アラート検知は3分（目標2分を未達））
発見した問題	（例：Runbookの手順3に記載のコマンドが古く、実行に5分のロスが発生した）
改善アクション	（例：Runbook手順3を更新する（担当：田中、期限：2026-08-27））
次回の訓練予定	（例：2026年11月（Q4 Game Day））

英語版テンプレート（コピペOK）

Overview & Goals

Item	Details
Exercise Name	(e.g., Payment Service Failover Game Day 2026-Q3)
Date & Time	(e.g., August 20, 2026, 10:00–13:00)
Target Systems	(e.g., Payment API Service, DB Cluster)
Team	(e.g., Backend SRE Team)
Facilitator	(Name)
Goal	(e.g., Verify that multi-region failover meets the RTO target of 30 minutes.)

Scenarios

#	Scenario	Failure Injection	Expected Impact
1	(e.g., Primary DB Failure)	(e.g., Block network access to the primary DB.)	(e.g., Payment API returns 503. Automatic failover to replica is triggered.)
2	(e.g., Cache Flush)	(e.g., Delete all keys in the Redis cluster.)	(e.g., API response times spike. Direct DB access increases.)
3	(e.g., Region Failure Simulation)	(e.g., Block all traffic to ap-northeast-1.)	(e.g., Failover to ap-southeast-1 is triggered.)

Execution Plan

#	Step	Owner	Duration	How to Verify
1	(e.g., Pre-check: Confirm dashboard is green, disable production alerts.)	SRE Lead	10 min	All green on Datadog
2	(e.g., Scenario 1: Block DB network access.)	Infra Engineer	5 min	Run iptables command
3	(e.g., Observe failover and respond.)	All	30 min	Datadog alerts and logs
4	(e.g., Confirm recovery: API responses normalized.)	SRE Lead	10 min	Health check endpoint
5	(e.g., Run Scenarios 2–3.)	All	60 min	Check success criteria after each scenario
6	(e.g., Retrospective meeting.)	Facilitator	30 min	Fill in results template

Success Criteria

Metric	Target	How to Measure
RTO (Recovery Time Objective)	Within 30 minutes	Time from failure injection to API health check passing
RPO (Recovery Point Objective)	Less than 5 minutes of data loss	DB replica replication lag
Alert Detection Time	Within 2 minutes	Time from failure injection to PagerDuty alert
Runbook Adherence	100%	Were all Runbook steps followed as documented?

Results & Retrospective

Item	Details
Date Conducted	(e.g., 2026-08-20)
Scenarios Completed	(e.g., Scenarios 1 and 2 completed. Scenario 3 skipped due to time constraints.)
Success Criteria Results	(e.g., RTO: 28 min — achieved. Alert detection: 3 min — missed target of 2 min.)
Issues Found	(e.g., The command in Runbook Step 3 was outdated, causing a 5-minute delay.)
Action Items	(e.g., Update Runbook Step 3 (Owner: Tanaka, Due: 2026-08-27).)
Next Game Day	(e.g., November 2026 (Q4 Game Day))

各セクションの書き方と例文

テンプレートを埋めるときに悩みやすいポイントを解説する。

シナリオの書き方（障害注入→想定影響のセット）

シナリオは「何を壊すか」と「何が起きるか」をセットで書く。「起きるか」を事前に書くことで、実際の観測結果との差異が発見事項になる。

日本語	英語
〇〇への接続を遮断する	Block access to [component].
〇〇プロセスを強制終了する	Kill the [process] process.
〇〇ノードをシャットダウンする	Shut down the [node].
〇〇のディスクをフルにする	Fill up the disk on [server].
〇〇へのレイテンシを追加する	Inject latency into [component].

評価基準の書き方（RTOとRPOの定義）

RTO・RPOは数字で定義する。「なるべく早く」ではなく「30分以内」と書くことで、訓練後の合否が明確になる。

日本語	英語
目標復旧時間（RTO）：30分以内	RTO (Recovery Time Objective): Within 30 minutes
目標復旧時点（RPO）：5分以内のデータ損失	RPO (Recovery Point Objective): Less than 5 minutes of data loss
可用性目標：99.9%（月次）	Availability Target: 99.9% monthly
アラート検知：2分以内	Alert Detection: Within 2 minutes
手動対応不要（自動復旧）	No manual intervention required (auto-recovery)

SLAとの整合性確認は英語SLAの書き方でも参考にしてほしい。

Game Dayでよく使う英語表現

実務でよく使う英語表現を場面別にまとめた。

Game Day・障害訓練の基本用語

日本語	英語
障害訓練	Game Day / Chaos Exercise / DR Drill
障害注入	Failure Injection
混乱エンジニアリング	Chaos Engineering
目標復旧時間	RTO (Recovery Time Objective)
目標復旧時点	RPO (Recovery Point Objective)
フェイルオーバー	Failover
フォールバック	Fallback
ブラストラジアス	Blast Radius
「ゲームデイ」終了宣言	Call the all-clear

訓練中・事後のフレーズ

日本語	英語
今から障害を注入します	We’re injecting the failure now.
〇〇が影響を受けています	[Component] is impacted.
フェイルオーバーが発動しました	Failover has been triggered.
復旧を確認しました	Recovery confirmed.
RTO目標を達成しました	We met the RTO target.
今日のGame Dayを終了します	Calling the all-clear — Game Day is complete.
Runbookに問題が見つかりました	We found an issue in the Runbook.