# インシデントシミュレーション 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]])。 ## 未解決の問い - ステージドワールドを「チーム単位(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 実験の設計者と組織 ## 出典 - [[@2024__SREcon24EMEA__Incident Groundhog Day]]