Failure ScenarioとRecovery Exerciseを設計する

ゴール

障害シナリオを選ぶ
↓
期待する動作を定義
↓
ディザスタリカバリ計画と復旧手順を確認
↓
安全な演習を設計
↓
復旧行動を実行
↓
期待結果と実際を比較
↓
学びを改善へ反映

1. 最初に「何を壊すか」ではなく「何を確認したいか」を決める

障害演習では、最初から「EC2を停止する」「AZを落とす」「ネットワーク障害を起こす」と操作を選ぶのではなく、先にどの運用能力を確認したいのかを決めます。

例えば、依存API停止を正しく検知できるか、リージョン障害時に復旧判断できるか、自動復旧が失敗した場合に担当者へ正しく引き継げるか、復旧サイトへの切り替えを担当チームが実行できるか、などです。

その後で、その目的を確認できる障害条件を設計します。

2. 障害シナリオは実際のリスクから作る

障害シナリオの候補には、過去に発生した障害、繰り返している障害、重要な依存関係、単一障害時に影響が大きい箇所、ディザスタリカバリ計画が前提としている障害、最近大きく変更された構成などを利用します。

例えば、外部API停止によってアプリケーション処理が停止し、利用者からの問い合わせで初めて発覚した障害を繰り返しているなら、外部APIを利用できない状態は有力なシナリオです。

珍しい障害であること自体ではなく、実際の運用リスクを理解するために価値があるかで選びます。

3. 障害シナリオには開始条件と期待結果を持たせる

単に「データベース障害を起こす」と決めるだけでは不十分です。

演習前に、何が起きるか、何を検知するはずか、誰に通知されるはずか、どの判断が行われるはずか、どの復旧手順を開始するはずか、最終的にどの状態へ戻るはずかを整理します。

障害
依存サービス停止
↓
期待
監視が異常検知
↓
担当者へ通知
↓
影響範囲確認
↓
復旧手順開始
↓
代替経路へ切り替え
↓
サービス正常確認

目的は障害を発生させることではなく、期待した復旧行動が実際に成立するか確認することです。

4. ディザスタリカバリ計画と復旧手順を分ける

ディザスタリカバリ計画と具体的な復旧手順は同じ役割ではありません。

一方、復旧手順では、どの操作を、どの順番で、どの権限を使って、どこを確認しながら実行し、異常時にはどう対応するかを具体化します。

AWS Well-Architectedでも、ランブックは特定の結果を達成するための手順として、必要な権限・ツール・例外・エスカレーションまで含めて維持することが推奨されています。

5. 計画があっても手順がなければ演習で詰まる

計画書に「リージョン障害時は復旧リージョンへ切り替える」とだけ記載されていても、誰が切り替えを判断するか、どの権限を使うか、どの順番で操作するか、どこまで終われば成功か、失敗したら誰へエスカレーションするかが分からなければ実行できません。

演習では計画の存在だけではなく、担当者が計画を具体的な復旧行動へ変換できるかを確認します。

6. ゲームデーはシステムだけではなく人とプロセスも試す

ゲームデーでは障害イベントを模擬し、システム、運用プロセス、担当者、意思決定、連絡、復旧手順が実際に機能するかを確認します。

実際の本番障害時に関与する運用・開発・インシデント対応・業務関係者などを参加させます。

技術担当者1人が復旧コマンドを実行できただけでは、組織としての復旧能力を十分に確認できません。

7. ゲームデーは「突然本番を壊すこと」ではない

現実的な演習は重要ですが、参加者に知らせない、安全条件を決めない、顧客影響を許容する、停止方法を決めないことがゲームデーの目的ではありません。

演習前に、対象範囲、開始条件、参加者、監視項目、許容する影響、中止条件、切り戻し方法、連絡先を定義します。

本番に近い条件で行う場合でも、想定外の悪影響が生じたときに中止・切り戻しできる安全措置を準備します。

8. 障害注入は目的ではなくシナリオ再現の手段

必要に応じて、依存サービスを利用不能にする、対象コンポーネントを停止する、ネットワーク到達性を制限する、リソース障害を模擬するなどの方法で障害を再現します。

AWS Fault Injection Serviceを利用して制御された障害シナリオを作成することもできます。

AWS Fault Injection Serviceを使った
=
良いゲームデー

ではありません。先に確認したい復旧行動があり、それを再現するために障害注入を使用します。

9. フェイルオーバー演習では人とプロセスも確認する

フェイルオーバーの実施方法や、実際の復旧経路を使って復旧能力を検証する考え方は既習です。

ここでは「フェイルオーバーできるか」だけではなく、ゲームデーの中で、誰が障害を認識するか、誰が切り替え開始を判断するか、誰が実行するか、どの時点で関係者へ連絡するか、想定外の状態になった場合に誰が中止を判断するか、切り替え後に誰がサービス正常性を確認するかまで確認します。

障害発生
↓
監視が検知
↓
担当者へ通知
↓
影響範囲を確認
↓
責任者が復旧開始を判断
↓
担当者が定義済みの復旧手順を実行
↓
関係者へ状態共有
↓
サービス正常性を確認

フェイルオーバー操作だけ成功しても、通知されなかった、判断者が不明だった、必要な承認先へ連絡できなかった、正常性確認の担当が決まっていなかったなら、復旧体制全体が機能したとは判断しません。

10. 復旧検証は「期待した動作」と比較する

演習後は、サービスが復旧したという最終結果だけで評価せず、事前に定義した期待結果と実際を比較します。

最終的にサービスが回復していても、監視が機能しなかった、エスカレーションされなかった、手順外の操作が必要だったのであれば、それらは重要な改善点です。

11. 「復旧できたが手順どおりではなかった」を成功で終わらせない

復旧手順
1
2
3

実際
1
↓
手順にない操作A
↓
別担当者へ問い合わせ
↓
操作B
↓
3

最終的に復旧できても、復旧手順だけでは再現できないことが判明しています。

なぜ追加操作が必要だったか、どの前提が抜けていたか、必要権限は明記されていたか、別担当者でも実行できるかを確認します。

12. 演習ではチームの判断経路も確認する

技術的な復旧操作だけではなく、誰が障害を宣言するか、誰が復旧開始を承認するか、どの時点で業務部門へ連絡するか、誰が状態を共有するか、判断できない場合はどこへエスカレーションするかも確認します。

人
+
プロセス
+
技術

が一緒に機能するかを確認します。

13. 学びを改善項目へ変換する

ゲームデーの終了後には、検知が遅れた、通知先が古かった、権限が不足した、手順が曖昧だった、実際には不要な承認があった、自動復旧が想定どおり動かなかった、担当者が手順にない操作を行った、などの事実を整理します。

発見
↓
改善項目
↓
担当者
↓
対応期限
↓
計画 / 手順 / システムを修正
↓
次の演習で再確認

問題を見つけたこと自体で終了せず、改善を完了まで追跡します。

14. 個人を責めるための演習にしない

担当者が手順を間違えた場合も、担当者個人の問題だけで終了すると運用改善につながりません。

手順は明確だったか、必要な情報へアクセスできたか、権限は用意されていたか、判断条件は理解できたか、時間的な負荷が高すぎなかったかを確認します。

目的は失敗者を探すことではなく、実際の障害が起きる前に運用上の弱点を発見することです。

15. 演習は一度成功して終わりではない

新しい依存サービス、ネットワーク変更、権限変更、新しいデプロイ方式、新しい自動化、担当者変更などによって、以前成立した復旧手順が将来も成立するとは限りません。

ゲームデーは一回限りのイベントではなく、継続的な準備活動として定期的に実施します。

16. 障害シナリオ設計の判断フロー

現在の障害履歴 / 重要依存関係
↓
確認したい復旧能力を決める
↓
障害シナリオを定義
↓
期待する検知・判断・復旧結果を定義
↓
ディザスタリカバリ計画を確認
↓
復旧手順を確認
↓
参加者 / 役割を決定
↓
影響範囲・中止条件・切り戻しを定義
↓
ゲームデーを実施
↓
必要な復旧行動を演習
↓
期待結果と実際を比較
↓
復旧検証
↓
振り返り
↓
計画 / 手順 / システムへ改善反映
↓
次回の演習で再確認

17. 混同ポイント

18. SAP-C02判断

復旧計画は存在するが実際に演習していない
↓
障害シナリオを設計
↓
ゲームデー / 復旧演習

復旧時の担当者が具体的な操作を分からない
↓
復旧手順を明確化
↓
演習で検証

リージョン障害時に復旧サイトへ切り替える計画
↓
安全条件・役割・判断経路を定義
↓
ゲームデーで復旧プロセスを演習

演習では復旧したが通知・権限・手順に問題
↓
振り返り
↓
計画 / 手順 / 運用を改善
↓
再演習

まとめ

障害シナリオと復旧演習の中心は、障害を発生させることではありません。実際の障害時に必要な復旧行動を理解し、安全な演習で確認することです。

障害シナリオ
↓
ディザスタリカバリ計画
↓
復旧手順
↓
ゲームデー
↓
フェイルオーバーテストなどの復旧行動
↓
復旧検証
↓
振り返り

演習で見つかった問題は、本番障害が起きる前に発見できた改善材料として計画・手順・運用へ反映します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional SAP-C02 Exam Guide — Task 3.1
• AWS Well-Architected Framework — ゲームデーを定期的に実施する
• AWS Well-Architected Framework — ディザスタリカバリの実装をテストする
• AWS Well-Architected Framework — ランブックを使用して手順を実行する