# 組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜 SRE NEXT 2024（2024-08-03）にて [[Narimichi Takamura]]（[[Topotal]]）が発表。[[Topotal]] の SRE as a Service と [[Waroom]] プロダクトマネジメントの両方を通じて積み上げた実践知から、インシデントレスポンス成熟度モデルを提案した。発表資料: [SRE NEXT 2024 スケジュール](https://sre-next.dev/2024/schedule/#jp110) ## 概要 インシデント対応改善の難点3つ（パターン膨大・ベストプラクティス定着困難・期待値の企業差）を整理し、Google SRE の信頼性マインドセットをベースとした成熟度モデルで解決策を提案する。Pre-Incident・Response・Post-Incident の3フェーズ×9プロセスを Absent/Reactive/Proactive/Strategic の4段階で評価し、段階的改善のロードマップを示す。 ## インシデントレスポンス改善が難しい3つの難点 **難点1: 企業の状況と解決策のパターンが膨大であり、アドホックな対応になってしまう** - 企業ごとにツール・フロー・ポリシーが大きく異なるため、A社でうまくいったプラクティスがB社でうまくいくとは限らない - → 緩やかに分類した上で中長期的な改善の方向性を示す枠組みが必要 **難点2: ベストプラクティスの導入がうまくいかないケースがある** - コマンダーロールの導入やSEVの定義等、「べき論」に基づくベストプラクティスは様々な前提が整って初めて効果を発揮し、企業によっては単なるオーバーヘッドになる - → 周囲を巻き込みやすくするために段階的な改善ステップをつくる必要がある **難点3: 「組織的な対応」の期待値が企業によって異なる** - より成熟した組織では、単に複数人が連動して対応することではなく、人やシステムがより効率的に連動できる体制を求める - → 成熟した企業が目指す理想状態も含めて言語化する必要がある ## 成熟度モデルの設計方針 成熟度モデルとは、組織がプロセスを定め洗練するための手段であり、「何から着手すべきか」「共通の言語とビジョンの共有」「実行の優先順位づけの枠組み」を提供する。 [[インシデント対応成熟度モデル]] 設計のベースに使ったのは [[Google|Google SRE]] の「信頼性のマインドセット」（Absent / Reactive / Proactive / Strategic / Visionary）。Visionary は実例が少ないとして割愛し、4段階を採用した。 **インシデントレスポンスはモニタリングやデプロイ等の周辺領域の影響を受けやすい**ため、SREコンテキストを成熟度に取り込む必要があるという判断に基づく。 ## 4段階の成熟度レベル定義 | レベル | 定義 | |---|---| | **Absent** | インシデントレスポンス環境がほぼ未整備であり、属人的な対応が常態化している状態 | | **Reactive** | 重大な障害の対応方針は定まっているものの、インシデントレスポンスの環境改善はほとんど行われていない状態 | | **Proactive** | 組織全体で対応を行う体制が整っており、Pre-IncidentやPost-Incidentのフェーズの取り組みによって事前にリスクを低減している状態 | | **Strategic** | それぞれのプロセスが体系化・仕組み化されており、フィードバックループを回しながらインシデント対応の負担を最小化し続けている状態 | プロダクトライフサイクル（INTRODUCTION→GROWTH→MATURITY→DECLINE）に応じて求められる信頼性レベルが変化する。リリース前は Absent が許容され、ビジネスクリティカルなプロダクトは Strategic が求められる。 ## インシデントレスポンス成熟度モデル（全体図） **p.26 成熟度モデル 4×3 マトリクス** ![[_attachments/sre-next-2024/page-026.png]] X軸が Absent/Reactive/Proactive/Strategic の4成熟度レベル、Y軸が Pre-Incident/Response/Post-Incident の3フェーズ。各セルに9プロセスそれぞれのレベル別状態を示す。 **p.27 成熟度モデル 詳細テーブル** ![[_attachments/sre-next-2024/page-027.png]] 各フェーズ・プロセスごとに4段階の状態定義と、Absent(未整備)→Strategic(仕組み化)の典型像を言語化した早見表。 ## 9プロセスの構成 **Pre-Incident フェーズ**（事前対応） - **Detection（検知）**: アラート・監視の仕組み - **Workflow（対応フロー）**: インシデント対応の手順・フロー定義 - **Training（トレーニング）**: インシデント対応トレーニング **Response フェーズ**（対応中） - **Empowerment（権限委譲）**: インシデント対応における意思決定権限 - **Systematization（仕組み化）**: 対応プロセスのシステム化・自動化 - **Collaboration（コラボレーション）**: チーム間連携 **Post-Incident フェーズ**（事後） - **Learning（学習）**: 振り返り・学習 - **Analytics（分析）**: インシデントデータの分析 - **Follow-up（事後タスク）**: アクションアイテム管理・再発防止 ## 改善のステップ 1. 成熟度モデルをもとに、9つのプロセスに対してレベルを判定する 2. Absent〜Strategicのどのあたりに自分たちが位置しているかを確認する（9つ中大半を占めるレベルはどれかを確認） 3. 関係者とともに、インシデントレスポンスのあるべき状態をディスカッションする 4. 改善の方向性が定まったら、各プロセスごとに具体的な改善のアクションを定める **p.30 色付けによる全体感の把握** ![[_attachments/sre-next-2024/page-030.png]] 該当レベルのセルに色を付けると現在地が一目で分かる。9プロセスのうち多くが Proactive なら Proactive 寄り、といった全体評価が可能になる。 ## フェーズマイグレーションのポイント **Absent → Reactive** - 改善概要: クリティカルな障害のフォローが迅速にできるようになり、信頼性が向上する - キーポイント: 重大なインシデントのみにスコープを絞った上で、Pre-IncidentとPost-Incidentの活動を部分的にはじめることに注力する - 注意点: 検知の仕組みだけを整備しても、対応フローが未定義では失敗に終わることが多い **Reactive → Proactive** - 改善概要: トイル解消や再発防止が進むため、組織全体のインシデント対応負荷が軽減されはじめる - キーポイント: 各プロセスの体系化と仕組み化を主眼において、ソフトウェアエンジニアリングをベースに改善活動を行う - 注意点: 組織全体を巻き込む施策が増えるため、べき論に基づいて一気に進めず、各プラクティスごとに段階的に進める **Proactive → Strategic** - 改善概要: 少ないリソースで最大限の価値を得るために、これまで構築した仕組みをさらにブラッシュアップし、インシデントの負担を最小化する - キーポイント: データドリブンな改善がベースになるため、他のキーメトリクスと連携しながらインパクトの大きい施策に注力する - 注意点: 高度な専門知識を必要とする施策が多いため、改善活動自体が属人化しないよう注意する ## プロダクトフェーズと信頼性の変化 **p.22 プロダクトのフェーズと求められる信頼性の変化** ![[_attachments/sre-next-2024/page-022.png]] プロダクトライフサイクル曲線（INTRODUCTION→GROWTH→MATURITY→DECLINE）に重ねて、INTRODUCTION フェーズでは "Focus on Development"、MATURITY フェーズでは "Balancing Reliability and Development" が求められることを示す。Absent はリリース前のプロダクトに対応し、Reactive はリリース前後、Proactive はほとんどのプロダクトが目指すべき水準、Strategic はビジネスクリティカルなプロダクトに対応する。 ## モデル活用の注意点 - **たたき台として自組織向けに改変して利用する**（項目を減らす/増やす、一段階ずつレベルをずらすなど） - **具体的なアクションプランが想定できる場合は追記する** - **すべての組織が Strategic を目指す必要はない**（プロダクトのステージや組織カルチャーによって適切なレベルは異なる） - インシデントレスポンス以外の領域（モニタリング・デプロイ等）の改善も重要 ## 概念・実体への接続 - [[インシデント対応成熟度モデル]] — 本スライドが提案する中核概念 - [[インシデント管理]] — 成熟度モデルが評価対象とするインシデントライフサイクル - [[Incident Commander]] — Response フェーズの Empowerment（権限委譲）プロセスの代表例として言及される上級ベストプラクティス - [[Narimichi Takamura]] — 登壇者 - [[Topotal]] — 所属組織。SRE as a Service と Waroom の2事業が本モデル構築の実践的背景 ## 限界・不確実点 - p.27（詳細テーブル）のセル内文字が画像では小さく、全レベル×全プロセスの詳細テキストを完全に読み取れていない箇所がある。抽出テキスト(p.27)から補完可能な範囲に留まる - transcript なし（音声なし）のため、口頭補足説明・質疑の内容は不明 ## 出典確認 ✅ タイトル・登壇者・所属・イベント・日付: SpeakerDeck ページ og:title / og:author / deck-date で確認済み ✅ 3つの難点・成熟度レベル定義・9プロセス・フェーズマイグレーション: スライド画像(p.10-37)および抽出テキストで確認 ✅ 信頼性マインドセット引用元: スライド内脚注3「組織の信頼性のマインドセット:Google SRE の知見」 ⚠️ p.27 詳細テーブル内の各セルのテキスト: 画像解像度の都合上、一部のセルは抽出テキストとの照合による補完 ℹ️ プロダクトフェーズ図(p.22)の各ステージ名: 画像で確認（INTRODUCTION/GROWTH/MATURITY/DECLINE）