# インシデント対応の教科書 本教科書は wiki に蓄積された 30 以上のソースと 20 以上のコンセプトページを横断し、SRE のインシデント対応を検知から緩和、組織設計から AI 支援まで体系化したものである。 ポストモーテム(事後振り返り)については姉妹編である [[ポストモーテムの教科書]] を参照されたい。 --- ## 第 I 部　基礎 ### 第 1 章　インシデント対応のライフサイクル インシデント管理(Incident Management)は、クラウドサービスにおけるサービス違反や性能劣化を**検知、トリアージ、診断、緩和**の 4 段で処理するライフサイクル全体を指す(Source: [[インシデント管理]])。 この 4 段は AIOps の能力分類(検知、箇所特定、RCA、緩和)がタスク能力を縦に切るのに対し、運用プロセスとしてライフサイクルを横断する視座を提供する。 Google SRE はさらに細粒度の 8 フェーズタイムラインを定義する。 Root Cause が本番に到達してから Detect、Escalate、Mitigate、Resolve、Retrospect、Action Items へ至る流れである(Source: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]])。 修正機会はこのタイムライン上で 3 方向に分類される。 | 方向 | 介入点 | |---|---| | **STOP** | 根本原因が本番に到達する前に止める | | **FASTER** | 検知から緩和までを高速化する | | **PREVENT and FIX CULTURE** | 復旧後に予防策と学習文化を醸成する | #### クラウド障害ライフサイクルの実測値 Li ら(2022)は AWS、Azure、Google Cloud の公開ポストモーテム 354 件を分析し、ライフサイクルを **TTX(Time to X)指標**で定量化した(Source: [[クラウド障害ライフサイクル]])。 | 指標 | 定義 | 平均値 | |---|---|---| | **TTD** | 障害発生から最初の検知まで | 16.9 分 | | **TTI** | 検知から根本原因特定まで | 77.8 分 | | **TTM** | 根本原因特定から緩和完了まで | 304.2 分 | | **TTR** | 障害発生から完全解決まで | 572.8 分 | TTR の 53% を緩和フェーズ(TTM)が占める。 障害発生から緩和まで平均 9 時間以上かかるという事実は、緩和フェーズの短縮が最大の改善ポイントであることを示す。 DevOps の理想目標(TTD 1 分、TTI 5 分、TTM 10 分)に対し、達成率は TTD 15.7%、TTI 14.0%、TTM 1.9% にとどまる。 ### 第 2 章　重大度の評価 インシデントの重大度は、直感的には「単一の数値(Sev1, Sev2)」で表現される。 しかしこの単純化にはいくつもの問題がある。 [[Sue Lueder]](Google)は、重大度を法的リスク、ユーザー影響、財務、サービス種別の 4 次元に分解し、パースペクティブ別(財務、広報、品質)に重み付けスコアを算出する方式を提案した(Source: [[インシデント重大度評価]])。 [[Courtney Nash]](Verica)は VOID データベース(1,856 件、610 組織)の分析から、持続時間と重大度は相関しないことを示した(Source: [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]])。 「23 時間 11 分で顧客影響ゼロ」と「21 分で Critical 顧客影響」が共存する。 重大度は測定値ではなく、社交的な調整物(socially negotiated variable)であるというのが Nash と [[John Allspaw]] の結論である。 この問題に対し 3 つの異なる処方箋が提示されている。 1. **意図的な過大分類**(Eason, Facebook 2016): リスクがあれば Sev1 に倒し、後から格下げする。 2. **結果ベースの評価**(McCarthy, Afterpay 2023): 重大度判断の重心を「エンジニアの意図」から「ユーザーへの実害」に移す。 3. **カナリアとしての重大度**(Ruppe, Jeli 2024): 重大度を巡る摩擦そのものを組織課題の診断シグナルとして活用する。 (Source: [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]], [[@2023__SREcon23EMEA__The Incident Is The Way - Using Your Incidents to Win Reliability Investment]], [[@2024__SREcon24 Americas__What Is Incident Severity, but a Lie Agreed Upon?]]) --- ## 第 II 部　指揮 ### 第 3 章　インシデントコマンドシステム #### ICS の起源 ICS(Incident Command System)は 1960〜70 年代のカリフォルニア山火事対応を起源とする指揮体系である。 2004 年に NIMS(National Incident Management System)として連邦義務化され、多機関連携の標準となった(Source: [[Incident Commander]])。 Google SRE Book(2016)はこの ICS をソフトウェアインシデント対応に適用し、4 役割を定義した(Source: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]])。 | 役割 | 責務 | |---|---| | **IC(Incident Commander)** | 全体指令、調整、内部コミュニケーション | | **Ops Lead** | 実際の修復 | | **Communications Lead** | 外部ステークホルダーへの情報発信 | | **Planning Lead** | 長期化した場合の計画策定 | IC は技術問題を自ら解く役割ではない。 SRE Book は非管理型インシデントの最大の悪化要因を「善意に基づく独断行動(フリーランシング)」と特定し、この抑制こそが IC の中核機能だとする。 Facebook の [[Gareth Eason]] はこの調停機能を「人間のミューテックス(human mutex)」と呼んだ。 複数人が同時に問題解決を試みる際、まず 1 つの案を試し他は待たせるという並行制御の比喩である(Source: [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]])。 #### Sev1 拡張役割 [[Alice Goldfuss]](New Relic, 2016)は、最深刻の Sev1 でのみ解放される追加役割を定義した(Source: [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]])。 - **EC(Emergency Commander)**: IC と法務、マーケティング等の間のリエゾン。 - **LL(Logistics Lead)**: シフト管理、食事手配、帰宅指示などのロジスティクス。 ICS 導入前後で、同種の大規模インシデントの対応時間が 3 日から 3 時間に短縮された。 この数値は IC プログラムの ROI を示す、公開されている最古の実績報告である。 ### 第 4 章　IC の育成と組織設計 IC の育成方針は 10 年間で進化した。 Goldfuss(2016)は「全員を訓練し、快適な者が任意で立候補する」アプローチを採った。 [[Vanessa Huerta Granda]](2026)は「Deliberate IC Team(意図的専任チーム)」を最良実践として推奨する(Source: [[@2026__SREcon26 Americas__So You Want a New Incident Commander]])。 両者は「IC は技術役割でない」という核心で完全に一致する。 IC の人材選定にあたり、役職は指標にならない。 | アンチパターン | 理由 | |---|---| | 最強エンジニアを IC にする | 最強のエンジニアを技術問題から引き離すことになる | | オンコール担当者をそのまま IC にする | オンコール適性と IC 適性は別物である | | 最上位者を IC にする | 役職が IC の適性を保証しない | IC のコアコンピテンシーは 3 つである。 コミュニケーション(技術と非技術の両方の語り口)、社会技術的リーダーシップ(技術の外の問題を識別する力)、認知負荷管理(複数の作業ストリームを切り替えながら全体状況を維持する力)。 #### 最小導入としての「3 つの帽子」モデル [[Thai Wood]](SREcon23 Americas)は、ICS の正式な役割体系ではなく「対応に必須の core needs」として 3 つの帽子を提示した(Source: [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]])。 - **Organizer**(IC 相当): 全体の調整。 - **Connector**(CL 相当): 情報の橋渡し。 - **Expert**(TL 相当): 技術的な問題解決。 重大度や命令系統を意図的に排除し、チーム単体で今日からでも始められる規模に縮小している。 成熟度の低い組織でも着手可能な入り口として位置づけられる。 #### 複数インシデントの統制 [[Brent Chapman]](Slack)は、同時多発インシデントが増えるにつれ単一の IC では解決しない「インシデント間のリソース競合」に直面し、公共安全 ICS から **Area Command** を輸入した(Source: [[@2021__SREcon21__Evolution of Incident Management at Slack]])。 Area Command は、他のインシデントを俯瞰して優先順位付けと仲裁を行うメタ統制層である。 ### 第 5 章　フォロワーシップ IC の設計論は「IC をどう選び育てるか」に組織的関心を集中させる。 しかし対応者の大半は IC ではなく「フォロワー」である。 [[Laura Maguire]](Jeli, SREcon23 Americas)は、この関心の非対称性を問題視し、**フォロワーシップ(Followship)**を提唱した(Source: [[Followship]])。 フォロワーシップとは、共通の目標のために協働する経験豊富な対応者たちの「適応的コレオグラフィ(adaptive choreography)」である。 #### 調整のパラドックス 複雑適応系ではあらゆる人のメンタルモデルは部分的にしかなり得ない(Woods, 2017)。 非定型の事象に対処するには多様な視点の統合が必要だが、他者と協働すること自体が追加の認知負荷(Cost of Coordination, CoC)を生む。 対応者はこの負荷に DELEGATE(委任)、DELAY(後回し)、DIMINISH(優先度低下)、DROP(切り捨て)という 4 戦略で対処する。 #### フォロワーの 8 つの行動 1. **Anticipating**: 他者の作業を先読みする。 2. **Initiating**: 作業を自発的に始める。 3. **Signalling intent**: 意図を表明して協調を助ける。 4. **Proactively providing information**: 能動的に情報と前提を共有する。 5. **Relaxing goals and constraints**: 互恵性を示すために自分の制約を緩める。 6. **Synchronizing**: 活動を同期させる。 7. **Preparing themselves to be useful**: 役立つための準備をする。 8. **Looking in and listening in**: 状況を観察し傾聴する。 IC 中心主義とフォロワーシップは対立ではなく補完である。 IC の設計論がリーダー役割の内部を最適化するのに対し、フォロワーシップはそれ以外の全員の働きを底上げするフォースマルチプライヤーとなる。 --- ## 第 III 部　調査と診断 ### 第 6 章　調査戦略 [[Jonathan Sillito]] と [[Esdras Kutomi]] は 30 インシデントの定性分析から、調査を 2 種の戦略に分類した(Source: [[インシデント調査戦略]])。 **体系的戦略(Systematic Strategy)** は、症状から根本原因まで段階的に調査する。 2 つのアプローチがある。 「なぜ」を繰り返してシステムの挙動の連鎖をたどる方法と、テクノロジースタックを層ごとに下って問題の存在する層を特定する方法である。 **日和見的戦略(Opportunistic Strategy)** は、根本原因に概念的に直接ジャンプしようとする。 過去の経験に基づく典型的な原因の確認と、時間的に相関する異常の探索がある。 実際のインシデント調査では純粋に 1 戦略のみを用いるケースは少なく、日和見的戦略が出発点をより特定的にし、そこから体系的調査を継続するパターンが多い。 相関の発見だけでは不十分で、**因果の理解**が伴わなければ調査は失敗する。 設定変更との「良い時間的相関」を発見しながらメモリリークとの因果関係を理解できず、数時間の無駄が生じた事例が報告されている(incident 2.2)。 ### 第 7 章　インシデント認識論 [[Jack Kingsman]](Atlassian, SREcon26 Americas)は、インシデント対応を認識論的に分析するフレームワークを提案した(Source: [[インシデント認識論]])。 Google SRE Book の Incident Loop を基盤に、4 つの認識ツールを追加した構成をとる。 #### Incident Loop の 5 フェーズ | フェーズ | 目標 | |---|---| | **Phase 0: 検知** | インシデントの存在を確認し宣言する | | **Phase 1: 生存** | 被害の拡大を止める(「ボートを浮かせる」) | | **Phase 2: 検査** | システムの現状を観測して証拠を集める | | **Phase 3: 診断** | 証拠から根本原因の仮説を立てる | | **Phase 4: テスト** | 仮説を検証し、確認後に修正する | #### 認識ツール 1: 証拠 2×2 マトリクス 証拠を出所の直接性(Direct / Indirect)と変化状況(Changing / Stable)の 2 軸で分類し、収集の優先度をつける。 - **Direct-Changing**: 最高信頼度。今起きていることを直接示す。 - **Direct-Stable**: 長期的根本原因を示す可能性が高い。 - **Indirect-Changing**: 変化の徴候として有用だが解釈を要する。 - **Indirect-Stable**: 最低信頼度。補足情報としてのみ使う。 #### 認識ツール 2: 探索パターン 3 種 - **線形探索(Linear Search)**: ユーザー側の末端から順に「正常か異常か」を判定しながら根本へ進む。 - **2 分探索(Binary Search)**: 確認するコンポーネントを毎回半分に絞る。 - **変化誘導(Induced-Change)**: 意図的に変化(再現テスト、無効化、負荷変更)を加えて反応を観察する。証拠が乏しいときに能動的に証拠を生成する戦略である。 #### 認識ツール 3: 良い仮説の 3 条件 1. **Testable**: 何らかのテストで真偽を確認できる形式である。 2. **Relevant**: 現在の証拠と結びついている。 3. **Specific**: どのコンポーネント、条件、状態を指しているかが明確である。 「十分もっともらしい」と感じた段階で探索を止めてはならない。 早期停止(stopping early)は最大の誤りとされる。 ### 第 8 章　コミュニケーションと共通基盤 インシデント対応はチームスポーツである。 技術的な調査と並行して、参加者間の相互理解を維持する作業が常に進行している。 #### Common Grounding **Common Grounding**(共通基盤構築)は、相互理解とメンタルモデルをコミュニケーション、テスト、更新、調整、修復によって維持するプロセスである(Klein et al., 2005)(Source: [[Common Grounding]])。 「Common Grounding」は修復活動の副次的活動ではなく、修復と並行して常に進行するメイン活動の一つである。 割り込み、疲労、注意分散は Common Ground を直ちに脅かす。 さらに危険なのは、一方が協働から離脱しても他方が共同作業の存続を信じ続ける場合である。 崩壊に気づくのは離脱した側ではなく残された側であり、しかも遅れて気づく(Source: [[@2023__SREcon23Americas__Handover Communications in Software Operations - Findings from the Field]])。 [[Laura Maguire]] は Common Ground の知識を team(チームのスキル、知識)、others(誰が誰を頼るか)、technical system(システムの動作)、organization(目標、制約)の 4 象限に整理した(Source: [[@2023__SREcon23Americas__An Organizational Response to Incidents]])。 #### 引き継ぎコミュニケーション **引き継ぎ(Handover)** は Common Ground が明示的に受け渡される数少ない局面である(Source: [[Handover Communications]])。 [[Chad Todd]](CrowdStrike)の調査から、確信度を下げる要因として部門間の不整合、引き継ぎ後の不在、高負荷下での準備不足が特定された。 確信度を上げる要因は、口頭と記述の併用、詳細な記述、確認応答(Acknowledgement)の徹底である。 --- ## 第 IV 部　緩和 ### 第 9 章　障害緩和の構造 障害緩和(remediation / mitigation)は、診断結果を入力に適切な復旧アクションを実行してシステムを健全な状態へ戻す、インシデントライフサイクルの最終段である(Source: [[障害緩和]])。 #### 緩和手段の分類 Li ら(2022)は 354 件から 9 種類の緩和手段を同定した(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]])。 - リプレースメント(32%)が最多、自己回復(7.6%)が最少。 - ロールバックが TTM 中央値 91 分で最速、フィックスが 220 分で最遅。 - 根本原因と緩和手段には強い相関がある。設定ミスにはロールバックが集中し、ハードウェア障害にはフィックスが多い。 #### 「速く止める」と「正しく直す」 本番インシデントの緩和は「正しく直す」より「速く止める」に傾く。 GenAI クラウドサービスの分析では、コード修正は根本原因のコードバグ 21.5% に対し 7.6% にとどまる(Source: [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]])。 CI/CD の所要時間を考慮すると、ロールバックやアドホック修正が優先されるためである。 また自己回復が 19.7% を占める点も注目に値する。 「何もしないのが最適」なケースが約 2 割存在するが、既存のエージェント評価はこの判別能力を測っていない。 #### 緩和の段階化 深刻度に応じた多段エスカレーションへの収束が、SRE とハードウェア故障管理の双方で独立に観察される。 可逆で軽量な早期措置を先に置き、不可逆で重い措置は深刻度が確証されるまで遅らせるという順序設計が共通する(Source: [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]], [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]])。 ### 第 10 章　変更起因インシデント **変更起因インシデント**(Change-Induced Incidents, CII)は、変更を行わなければ起きなかった障害として通常インシデントと区別される(Source: [[変更起因インシデント]])。 2 つの独立した実証研究が、ほぼ同一の統計を報告している。 コード変更が約 55% で最多、構成変更が約 25% で第 2 位、最多緩和策はロールバック(約 50%)である。 クラウド障害ライフサイクルの 354 件分析でも、58.8% が変更中に発生し、そのうち 84.7% が内部原因(設定ミス、コード変更)であった。 変更プロセス中が最もリスクの高い時間帯であるという構造は、独立したデータセットで一致する。 変更起因インシデントの 50.6% ではユーザーがモニタより先に異常を検知した。 自動検知の網からすり落ちるインシデントの過半が変更操作中に発生しているという事実は、デプロイパイプラインへの検知強化が最優先であることを示す。 --- ## 第 V 部　人間 ### 第 11 章　インシデント対応における人的要因 #### 「ヒューマンエラー」は分析の行き止まりである この主張は 3 人の実践者が独立に到達した収束点である(Source: [[人的要因]])。 - Lund(SREcon19 APAC): 「Human Error は analytical dead end」 - Eckhardt(SREcon19 Asia/Pacific): 「ヒューマンエラーは調査を終わらせる場所でなく、始める場所」 - Gallego(SREcon18 Americas): 「人はその時点の情報において最善と信じる行動をとる」(ローカル合理性) 人間をエラーの原因として特定した瞬間に分析は止まり、「なぜその文脈でその判断が合理的に見えたか」という問いが省かれる。 #### 対応中の人間のオブザーバビリティ [[Matt Davis]](SREcon23 Americas)は「人間のオブザーバビリティ」を技術的メトリクスとは独立した観測対象として位置づけた(Source: [[@2023__SREcon23Americas__Human Observability of Incident Response]])。 コンダクター質問が疲労、食事、時刻、心理的安全を問うのはその実践形態である。 Davis は「インシデント対応の即興能力(Adaptive Capacity)は練習の外に存在しない」と主張し、**Practice of Practice Gamelan** という練習フレームワークを提案した。 認識論的な提案にとどまった Lund、Eckhardt とは異なり、Davis は組織的な訓練設計への橋渡しを行った点で新しい。 #### AI 時代の人的要因 [[Eddie Redick]](SREcon26 Americas)は "Commanding the Chaos" として、AI エージェントが自律的に動く環境下での SRE の人間側スキルセットを 3 軸で定義した(Source: [[@2026__SREcon26Americas__Human Factors in the Age of AI Ops]])。 1. **Psychological Composure**: プレッシャー下での冷静。 2. **Systems Thinking**: 全体最適視点。 3. **Automation at Scale**: スケールする自動化設計。 「アーキテクチャの水準には上がれない。システム思考の水準に落ちる」。 この主張は、アーキテクチャの複雑性が増すほど人間の全体俯瞰能力の相対的価値が上がるという意味である。 ### 第 12 章　ストレスと回復 #### オンコールストレスの生理学 [[Beth Adele Long]](SREcon26 Americas)は、オンコール業務に伴う 2 種類のストレスを区別した(Source: [[オンコールストレス管理]])。 慢性ストレス(ページャーを持ち続ける負荷)と急性ストレス(インシデント対応中の超警戒状態)である。 自律神経系(ANS)は本来、自己修正機能を持つ。 しかし合理的思考(Ordinary Mind)による抑制がかかると自己修正が働かなくなる。 解法は身体知性に根ざした 4 つの実践ツール(ボディスキャン、呼吸法、自発的な動き、退屈)である。 #### インシデント後の人的回復 Jaime Woo(SREcon18 Americas)は Shopify の 40 名を対象に調査し、42.5% がインシデント後に強いストレスを報告した(Source: [[インシデント後の人的回復]])。 80% が組織的サポートをほぼ受けていないとも報告している。 医師の二次被害者研究(Waterman et al. 2007)では、医療ミス後に将来のミスへの不安増大(61%)、自信の喪失(44%)、睡眠困難(42%)が報告されているが、82% がピアサポートとカウンセリングを有効と感じた。 Mosewich ら(2013)のセルフコンパッション介入研究(n=60)は、反芻思考と自己批判を有意に低下させた。 この能力は先天的ではなく、意図的に訓練できる。 --- ## 第 VI 部　測定 ### 第 13 章　MTTR 批判とインシデントメトリクス #### なぜ MTTR は機能しないか MTTR は 3 つの観点から批判されている(Source: [[インシデントメトリクス]])。 1. **統計的問題**(Davidovič, Google SRE): インシデント件数が少なく標準偏差が大きい場合、MTTR の変化のほぼすべてが統計的ノイズである。VOID の実データ(1,856 件、610 組織)では持続時間分布は一貫して右歪みを示し、この理論的予測を裏付ける。 2. **逆インセンティブ**(Luck, de Vesine, Datadog): MTTR を下げる最も簡単な方法は「同じインシデントを繰り返して素早く修正する」こと。深い根本原因の修正は MTTR を上昇させる。 3. **DORA での廃止**: DORA の最新版では MTTR が「bad rollout を remediate する時間」に置き換えられた。 #### 代替指標のフレームワーク インシデント件数も MTTR も機能しない場合、何を測るべきか。 Luck と de Vesine(Datadog, SREcon25 Americas)は、インシデント管理プロセスの「目標ごと」に指標を当てる方式を提案した。 | 目標 | 測定例 | |---|---| | オンコール持続可能性 | 深夜ページ数、シフト長、フェアネス知覚サーベイ | | インシデントが真剣に扱われる | ステートマシン完走率、自発的ポストモーテム率 | | インシデント対応の質 | 役割使用率、感情分析(自信、準備感) | | 事後学習と改善 | アクションアイテム速度、繰り返しインシデント率 | 顧客信頼性はこのリストに含まれない。 それは SLO で直接測定すべき別の問題である。 --- ## 第 VII 部　組織 ### 第 14 章　インシデント対応成熟度モデル [[Narimichi Takamura]](Topotal)は、Google SRE の「信頼性のマインドセット」をベースに、3 フェーズ×9 プロセスを 4 段階で評価するマトリクスを提案した(Source: [[インシデント対応成熟度モデル]])。 | レベル | 状態 | |---|---| | **Absent** | 属人的対応が常態化 | | **Reactive** | 重大障害の方針は定まるが環境改善は行われない | | **Proactive** | 組織全体で対応し、事前リスク低減を実施 | | **Strategic** | フィードバックループで対応負荷を継続的に最小化 | 3 フェーズは Pre-Incident(Detection、Workflow、Training)、Response(Empowerment、Systematization、Collaboration)、Post-Incident(Learning、Analytics、Follow-up)で構成される。 IC の導入は Proactive 以降で効果を発揮する。 「さまざまな前提が整って初めて効果を発揮する、企業によっては単なるオーバーヘッドになりうるベストプラクティス」である(Takamura)。 ### 第 15 章　ChatOps ChatOps は、チャットプラットフォームを運用操作の主要インターフェイスとする実践パターンである(Source: [[ChatOps]])。 [[Al Tobey]](Netflix, SREcon16)の Scorebot は典型実装であり、以下の機能パターンを確立した。 - **bookmarking**: タイムスタンプとメモの記録。タイムライン構築の起点。 - **presence**: 実際にキーボードの前にいるかを追跡する。 - **after-hours**: 夜間の問い合わせに自動応答し、緊急時はページを促す。 - **archive**: 絵文字リアクションで発言にタグ付けし、インシデントレポートの自動生成を目指す。 「ボットに機能を詰め込みすぎない」ことが設計原則である。 ロジックは独立したデーモンとして動かし、ボットはそれらへの薄いインターフェイスにとどめる。 Slack が落ちても本質ロジックは別で動く。 ### 第 16 章　アンインシデント 潜在インシデントの 30〜60% が正式なトラッキングを通過しない。 [[Andreas Deuschl]](Dynatrace, SREcon25 EMEA)はこれを**アンインシデント(Un-Incident)**と名づけた(Source: [[アンインシデント]])。 #### 4 類型 | 類型 | 定義 | |---|---| | **No-CI** | 顧客影響があるが既存分類に当てはまらない | | **NOF** | 外部要因に起因し自組織の責任外と判断される | | **Near Miss** | 幸運または予防的行動でエスカレーションを免れた | | **Fear Miss** | 不安による不必要なエスカレーション | 「インシデントか否か」という問いを「何を学べるか」に転換することが中心テーゼである。 対処の骨格は Gray Zone Playbook として示される。 マインドセット(宣言を阻まない、宣言に感謝する、事実ベースのトリアージ)、ストラクチャー(オブザーバビリティへの信頼構築、SLO による微細劣化の早期検出)、プロセス(簡単にトリガーできる事後分析への接続)の 3 層で構成される。 --- ## 第 VIII 部　訓練 ### 第 17 章　インシデントシミュレーション 「同じインシデントを二度経験することは不可能」という根本的制約を緩和する手段が、インシデントシミュレーションである(Source: [[インシデントシミュレーション]])。 #### ステージドワールド [[David D. Woods]] と Hollnagel(2006)が定義した手法で、4 つの特性を持つ。 シミュレーションシナリオ、十分な忠実度、専門性を引き出す設計、唯一解がないことである。 [[Hamed Silatani]](Uptime Labs, SREcon24 EMEA)は 20 名を対象にステージドワールド実験を行い、2 つの行動パターンを同定した(Source: [[@2024__SREcon24EMEA__Incident Groundhog Day]])。 - **Solo Artist**: 全負担を一人で抱え、ストレスが高い。 - **Band Member**: 早期にチームメンバーを巻き込み、ワークロードと思考力を分散する。 解決時間は参加者の経験や能力レベルと相関しなかった。 むしろ重大度の議論に費やした時間や、チームの巻き込み方が有意な行動差として浮上した。 技術的スキルより組織的な行動が成否を分けるという洞察は、訓練設計に含めるべき要素を示唆する。 #### Allspaw の 4 活動カテゴリ | カテゴリ | 内容 | |---|---| | **Diagnostic** | 信号を吸収し推論を行う | | **Therapeutic** | 問題を修正しようとする介入 | | **Recruiting** | 専門性と権限を持つ人を巻き込む | | **Status/Reporting** | 記録の作成とステークホルダーへの報告 | 治療的行動(Therapeutic)は即座に診断情報に変わるという特性を持つ。 失敗したロールバックは「その変更が原因ではなかった」という新たな診断シグナルを生み出す。 --- ## 第 IX 部　AI とインシデント対応の未来 ### 第 18 章　AI によるインシデント対応の自動化 #### インシデントレスポンス AI レベル [[Ryota Yoshikawa]](Topotal)は SAE の自動運転 L0〜L5 を IR(インシデントレスポンス)に対応させたフレームワークを提唱した(Source: [[インシデントレスポンスAIレベル]])。 | IR レベル | AI の役割 | |---|---| | **IR0** | なし | | **IR1** | 通知と記録補助 | | **IR2** | 判断支援と提案 | | **IR3** | 実行と監視責任も AI | | **IR4** | 完全実行(特定領域) | | **IR5** | あらゆる状況で AI | 2025 年時点で IR0〜IR2 は実現済みとされ、MCP(Model Context Protocol)とコーディングエージェントの進展により IR2〜IR3 の実現可能性が出てきたとされる。 IR3 到達には「AI に任せられる安全な操作の定義」が必要である。 #### TSG 自動化 TSG(Troubleshooting Guide)を LLM エージェントで実行する問題は、Microsoft の 3 本の論文で設計空間として立ち上がった(Source: [[インシデント管理]])。 - **FLASH**: インシデント時にオンラインで TSG を実行する。 - **StepFly**: オフラインで DAG を抽出し、並列スケジューラで実行する。 - **LLexus**: 計画フェーズを前置し、実行時は決定論的に走らせる。 3 本に共通する最大の発見は、**TSG 品質が自動化の律速**であることである。 FLASH の曖昧アクション(Ambiguous Action)が TSG の約 40% を占め、LLexus では低品質 TSG で計画コストが約 3 倍に膨らむ。 Google SRE AI はこの律速を、プレイブックの保守自体をエージェンティックループに組み込むことで解こうとしている(Source: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]])。 エージェントが利用実態を監視し、改善を提案し、インシデントから新規プレイブックを生成する。 #### ICS の AI への投影 Google SRE AI は ICS の 4 役割に 4 種のエージェントを補助層として被せる設計を採る。 コミュニケーション面の監視と集約、SRE 間ハンドオフ文書生成、ポストモーテム下書き作成、内外コミュニケーション管理である。 いずれも人間 IC を置き換えない補助層であり、「フリーランシング」の抑制を agentic 補助層でも貫いている。 ### 第 19 章　未解決の問い 本教科書の各部から浮かび上がる未解決の研究課題を整理する。 **指揮と組織** - Wood の「3 つの帽子」(最小導入)と Granda の「Deliberate IC Team」(専任チーム)は、どの成熟度で接続すべきか。 - フォロワーシップの 8 行動は、経験の浅い対応者にどう訓練できるか。 - MTTI(Mean Time To Innocence)を定量化した研究は存在するか。 **調査と診断** - AIOps エージェントは体系的戦略と日和見的戦略のどちらを実装しているか。ReAct ループは両者の切り替えを設計しているか。 - インシデント認識論の「良いテストの 6 基準」は、緊急度が高い場面でどれを優先するか。 **緩和** - 緩和エージェントは「何もしないのが最適」というケースを判別できるか。 - 反復リフレクションの精度向上は逓減する。適応的なプロービングとリフレクションの最適配分は設計できるか。 **人間** - Human Factors アプローチのコスト(個別インタビュー、デブリーフィング)と効果のトレードオフ。 - セルフコンパッション介入は SRE チームの文化に組み込めるか。 **測定** - 繰り返しインシデントの検出は現在手動に依存しており、LLM は不得意とされる。どのような定式化で自動化できるか。 - SLO とインシデント指標の「橋渡し」をどう設計するか。 **AI** - IR3 に必要な「安全な操作の定義」はどう検証するか。 - RCA 精度(14%)が低いまま IR3 は実現できるか。 - LLM 生成の緩和スクリプトの「症状消し」への最適化をどう防ぐか。 --- ## 付録 ### A. 用語集 | 用語 | 定義 | |---|---| | ICS | Incident Command System。山火事対応に起源を持つ指揮体系 | | IC | Incident Commander。全体指令と調整の最高責任者 | | TTX | Time to X。障害ライフサイクルの各フェーズの所要時間指標群 | | TTD | Time to Detect。障害発生から検知まで | | TTI | Time to Identify。検知から根本原因特定まで | | TTM | Time to Mitigate。根本原因特定から緩和完了まで | | TTR | Time to Resolve。障害発生から完全解決まで | | CII | Change-Induced Incidents。変更起因インシデント | | TSG | Troubleshooting Guide。トラブルシューティングガイド | | Common Grounding | 相互理解とメンタルモデルを維持するプロセス | | Followship | フォロワー全体の適応的コレオグラフィ | | Area Command | 同時多発インシデントの優先順位付けと仲裁を行うメタ統制層 | | IR Levels | SAE 自動運転レベルに対応させたインシデントレスポンス AI 自律度分類 | | MCP | Model Context Protocol。AI エージェントのツール接続標準 | | アンインシデント | 正式なトラッキングに至らなかった潜在インシデント | ### B. 推奨読書リスト **入門** - Google SRE Book Chapter 13: Emergency Response - Google SRE Book Chapter 14: Managing Incidents - Google SRE Workbook: Incident Response **指揮** - Alice Goldfuss: "nrrd 911 ic me" (SREcon16 Americas) - Vanessa Huerta Granda: "So You Want a New Incident Commander" (SREcon26 Americas) - Thai Wood: "If I Can Do It on an Ambulance" (SREcon23 Americas) - Brent Chapman: "Evolution of Incident Management at Slack" (SREcon21) **調査と診断** - Jack Kingsman: "Epistemology of Incident Management" (SREcon26 Americas) - Jonathan Sillito, Esdras Kutomi: "Failures and Fixes" (arXiv, 2020) **人的要因** - Matt Davis: "Human Observability of Incident Response" (SREcon23 Americas) - Laura Maguire: "An Organizational Response to Incidents" (SREcon23 Americas) - Eddie Redick: "Human Factors in the Age of AI Ops" (SREcon26 Americas) **測定** - Courtney Nash: "Tales from the VOID" (SREcon22 Americas) - Jamie Luck, Laura de Vesine: "Incident Management Metrics that Matter" (SREcon25 Americas) - Li+: "Going through the Life Cycle of Faults in Clouds" (ISSRE 2022) **訓練** - Hamed Silatani: "Incident Groundhog Day" (SREcon24 EMEA) - Sarah Butt: "When Systems Flatline" (SREcon21) **AI** - Google Cloud Blog: "AI in SRE: Where Google is Deploying Agentic AI" (2026) - Ryota Yoshikawa: "Rethinking Incident Response" (SRE NEXT 2025) ### C. ソースマッピング | 章 | 主要 wiki ソース | |---|---| | 1 | [[インシデント管理]], [[クラウド障害ライフサイクル]], SRE Book Ch14 | | 2 | [[インシデント重大度評価]] | | 3-4 | [[Incident Commander]], SRE Book Ch14, SRE Workbook | | 5 | [[Followship]], [[Common Grounding]] | | 6 | [[インシデント調査戦略]] | | 7 | [[インシデント認識論]] | | 8 | [[Common Grounding]], [[Handover Communications]] | | 9 | [[障害緩和]], [[クラウド障害ライフサイクル]] | | 10 | [[変更起因インシデント]] | | 11 | [[人的要因]] | | 12 | [[オンコールストレス管理]], [[インシデント後の人的回復]] | | 13 | [[インシデントメトリクス]], [[TTXメトリクス]] | | 14 | [[インシデント対応成熟度モデル]] | | 15 | [[ChatOps]] | | 16 | [[アンインシデント]] | | 17 | [[インシデントシミュレーション]] | | 18-19 | [[インシデントレスポンスAIレベル]], [[インシデント管理]] 横断的知見 |