# インシデントシミュレーション Navigation: [[index]] | [[インシデント管理]] | [[レジリエンスエンジニアリング]] ## 定義 インシデントシミュレーション(Incident Simulation)とは、実際のインシデント対応スキルを安全な環境で練習・研究するための模擬演習の総称である。単純なルール走査型の「テーブルトップ演習(tabletop exercises)」や「Choose Your Adventure」型から、忠実度の高い「ステージドワールド(staged world)」まで段階が存在する。 **ステージドワールド(staged world)** は [[David D. Woods]] と [[Hollnagel]](2006)が定義した手法で、以下の4特性を持つ: 1. **シミュレーションシナリオ(Simulated Scenario)**: 実際のインシデントを模倣するが管理された環境 2. **十分な忠実度(Enough fidelity)**: 参加者にリアルと感じさせるのに十分な詳細さ 3. **専門性を引き出す設計(Designed to elicit expertise)**: 参加者の知識・判断・経験を試す設計 4. **唯一解なし(There is no one solution)**: 複数の解決経路が存在するオープンエンド性 インシデントシミュレーションは「同じインシデントを二度経験することは不可能」という根本的制約を緩和する手段として位置づけられる(Source: [[@2024__SREcon24EMEA__Incident Groundhog Day]])。 ## ステージドワールドの設計要件 [[Hamed Silatani]]（[[Uptime Labs]]）の実験から明らかになった設計要件: ### 技術的忠実度 - エンジニアは本物のコマンドラインや SSH を使用しようとする——モックシステムでは信頼性を失う - 監視ツール/オブザーバビリティツールのメトリクスがシステムの実際の状態と一致している必要がある - インフラが実際に壊れている状態を作ること(AWS + Kubernetes 上の eコマースサービスを実際に壊した) ### 社会的環境の再現 - インシデント対応はチームスポーツ——1名の孤立した演習では不十分 - 異なるキャラクター: 経験浅い・発言を躊躇するエンジニア、自信過剰なエンジニア、情報を要求するステークホルダー - リアルなコミュニケーションチャネル(Slack インシデントブリッジ) ### シナリオの特性 - 唯一解なし: 参加者は複数の異なる解決経路を取れる - 潜在条件(latent conditions)の組み合わせ: 「Schrodinger's plates」と表現——単独では問題にならない条件が重なったとき問題が顕在化 - チームワークを必要とする設計: 情報が分散して配置され、権限と知識が異なる役割に分かれている ## Allspaw の4活動カテゴリ [[Hamed Silatani]] が [[John Allspaw]](SREcon21 "Hard Problems We Handle in Incidents but Aren't Recognized")から借用した、インシデント対応活動の4分類: | カテゴリ | 説明 | |---|---| | **Diagnostic** | 信号を吸収し推論を行うこと(ログ確認、重大度判断、他者の発言からの推論) | | **Therapeutic** | 問題を修正しようとする介入(ロールバック・サービス再起動・APIキー更新) | | **Recruiting** | 専門性と権限を持つ人物を巻き込むこと | | **Status/Reporting Activities** | インシデント記録の作成・ステークホルダーへの更新報告 | 重要な特性: **治療的行動は即座に診断情報に変わる** — 失敗したロールバックは「その変更が原因ではなかった」という新たな診断シグナルを生み出す(Source: [[@2024__SREcon24EMEA__Incident Groundhog Day]])。 ## 横断的知見 - **インシデントシミュレーションは技術訓練にとどまらず、認知・行動パターンの研究ツールとして機能する**: [[Hamed Silatani]] の20名実験(2024)では、解決時間は参加者の経験・能力レベルと相関せず、むしろ「重大度(severity)議論に費やした時間」「Solo Artist vs Band Member の役割取り方」「ステークホルダー更新の効率性」が有意な行動パターンの差として浮上した。技術的スキルより組織的・社会的行動が成否を分けるという洞察は、インシデント訓練の設計に含めるべき要素を示唆する(Source: [[@2024__SREcon24EMEA__Incident Groundhog Day]])。 - **シミュレーション「実施」の設計論(Silatani)に対し、Anatomy of an Incident は「何を題材にシナリオを書くか」という上流の設計論を補う**: Silatani のステージドワールド研究は、忠実度・社会的環境の再現・唯一解なしといった演習**実施時**の設計要件に焦点を当てる一方、シナリオそのものをどう選び定めるかには立ち入らない。Google の Wheel of Misfortune(週次の災害ロールプレイング、SRE Book 28章由来)を紹介する Anatomy of an Incident 2章は、直近のポストモーテムに対する3標準質問「何が悪かったか(What went wrong)」「何が良かったか(What went right)」「どこで運が良かったか(Where did we get lucky)」を起点にテスト題材を選び、まず具体的で修正しやすい「何が悪かったか」の小さく単純なテストから始め、確信が高まるにつれて技術的でない人的プロセスの課題や、より発見しにくい「どこで運が良かったか」の項目へ段階的に広げるという具体的な設計手順を示す。両者を合わせると「何を題材にするか(Anatomy of an Incident)」→「どう実施すれば忠実度・唯一解なしを担保できるか(Silatani)」という、シナリオ設計からファシリテーションまでの一貫したパイプラインとして読める。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]], [[@2024__SREcon24EMEA__Incident Groundhog Day]]) - **Anatomy of an Incident が「二次情報」として簡潔に紹介する Wheel of Misfortune を、実践者自身による一次情報が裏付け、かつ「唯一解なし」の構造化バリエーションを追加する**: Anatomy of an Incident 2章は Google の Wheel of Misfortune を「週次の災害ロールプレイング」として一文で紹介するにとどまるが、この教材を実際に運用していた [[Laura Nolan]] による一次情報([[@2021__OReillyJapan__SREの探求 - Chapter 20 アクティブなティーチングとラーニング]])は、ゲームマスター1名とオンコール担当者役1名という最小構成、事前のシナリオ準備の負荷、専用施設(ダブリンの「コバヤシマル」)の存在まで具体的に記述する。さらに同章が紹介する Incident Manager カードゲームは、Wheel of Misfortune の自由形式ロールプレイングに対し、ロールカード(IC・プランニングリード・オペレーションリード・コミュニケーションリード・レスポンダー)とアクションカードで進行に構造を与えたバリエーションであり、Silatani のステージドワールドが要求する「専門性を引き出す設計」を、即興のゲームマスター采配ではなくカードという明示的な機構で担保する設計思想の違いを示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 20 アクティブなティーチングとラーニング]], [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]]) - **参加者上限という運用制約は、忠実度追求(Silatani)とは独立に、教材そのものの構造から生じる**: Silatani のステージドワールド研究は忠実度・唯一解なしといった演習の質を論じるが、実施規模の上限には立ち入らない。ch.20 は Incident Manager が「グループの規模が12名程度を超えると機能しない」という具体的な運用上限を明示しており、この制約はロールカードの種類数(5ロール)とアクティブなシフト内での順番待ちという教材の構造そのものに起因すると読める。GameDay の Bradesco 事例(+300人参加)のような大規模演習とは対照的に、Incident Manager 型のカードゲームは少人数・高構造という別の設計点を占める。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 20 アクティブなティーチングとラーニング]], [[GameDay]]) ## 未解決の問い - Anatomy of an Incident の「小さく単純なテストから始め段階的に複雑化する」というシナリオ選定の進行原則は、Silatani のステージドワールドが要求する「唯一解なし」「潜在条件の組み合わせ(Schrodinger's plates)」という高忠実度シナリオの設計とどう両立するか。進行の初期段階では意図的に単純さを優先し、唯一解なしの複雑さは後段に導入すべきか。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]], [[@2024__SREcon24EMEA__Incident Groundhog Day]]) - Incident Manager のカード機構(ロール・アクション・PLAY NOW)は、Silatani が要求する「唯一解なし」「潜在条件の組み合わせ」という高忠実度シナリオ設計とどこまで両立するか。カードによる構造化は忠実度を損なわずに準備コストを下げる手段になりうるか。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 20 アクティブなティーチングとラーニング]]) - ステージドワールドを「チーム単位(Team Groundhog Day)」で実施した場合、Solo Artist / Band Member の個人差がチーム全体の行動にどう影響するか。 - 時間制限なしのシミュレーションでは、有限時間版と異なる行動パターンが出るか。 - シミュレーション経験がリアルインシデントのパフォーマンス向上に繋がることを示す縦断的エビデンスはあるか。 - staged world の「十分な忠実度」の下限はどこか——どの詳細を削れば認知的リアリティが失われるか。 - AI 駆動のインシデント自動対応が普及する中で、人間の Incident Commander が練習すべきスキルは変化するか。 ## 関連 - [[インシデント管理]] — 本概念の実践的文脈 - [[Incident Commander]] — シミュレーション上の主役 - [[レジリエンスエンジニアリング]] — 理論的基盤("Resilience is a verb", David D. Woods) - [[人的要因]] — 人間の認知・行動パターンの研究側面 - [[Hamed Silatani]]、[[Uptime Labs]] — staged world 実験の設計者と組織 - [[Laura Nolan]] — Wheel of Misfortune・Incident Manager の実践者 - [[アクティブラーニング]] — 教育論としての上位概念 ## 出典 - [[@2024__SREcon24EMEA__Incident Groundhog Day]] - [[@2021__OReillyJapan__SREの探求 - Chapter 20 アクティブなティーチングとラーニング]]