# インシデント対応の教科書 本教科書は 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]])。 ![[_attachments/srecon15__lueder__incident-analysis/page-012.png]] **図1-1**:Google の 8 フェーズタイムライン。Root Cause が本番に到達してから Detect、Escalate、Mitigate、Resolve、Retrospect、Action Items へ至る。Incident Duration は Detect から Resolve までである。 (Source: [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]], p.12) 修正機会はこのタイムライン上で 3 方向に分類される。 | 方向 | 介入点 | |---|---| | **STOP** | 根本原因が本番に到達する前に止める | | **FASTER** | 検知から緩和までを高速化する | | **PREVENT and FIX CULTURE** | 復旧後に予防策と学習文化を醸成する | ![[_attachments/srecon15__lueder__incident-analysis/page-026.png]] **図1-2**:同じタイムライン上の 3 方向の介入点。STOP は根本原因が本番に到達する前、FASTER は検知から緩和まで、Prevent and Fix Culture は振り返りとアクションアイテムである。 (Source: [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]], p.26) #### クラウド障害ライフサイクルの実測値 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% にとどまる。 ![[_attachments/Li-et-al.-2022---Going-through-the-Life-Cycle-of-Faults-in-Clouds---Guidelines-on-Fault-Handling-1/fig2-figure.png]] **図1-3**:障害のライフサイクル。検知(TTD)、箇所特定(TTI)、緩和(TTM)が直列し、その合計が TTR である。TTR の過半を TTM が占めるという本文の数値は、この区間分割に対応する。 (Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]], 図 2) ![[_attachments/anatomy-of-an-incident/ch04-fig4-1-outage-lifecycle.png]] **図1-4**:障害のライフサイクルを信頼性の時間変化として描いた図。障害発生からアラート確認までが検知時間、確認から緩和完了までが修復時間、次の障害までが障害間隔である。 (Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]], 図 4-1) ### 第 2 章　重大度の評価 インシデントの重大度は、直感的には「単一の数値(Sev1, Sev2)」で表現される。 しかしこの単純化にはいくつもの問題がある。 [[Sue Lueder]](Google)は、重大度を法的リスク、ユーザー影響、財務、サービス種別の 4 次元に分解し、パースペクティブ別(財務、広報、品質)に重み付けスコアを算出する方式を提案した(Source: [[インシデント重大度評価]])。 ![[_attachments/srecon15__lueder__incident-analysis/page-022.png]] **図2-1**:重大度フラグの多次元設計。法的コンプライアンス、ユーザー影響、財務、サービス種別に技術的フラグを加え、単一の Sev 番号へ畳む前の材料を列挙する。 (Source: [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]], p.22) [[Courtney Nash]](Verica)は VOID データベース(1,856 件、610 組織)の分析から、持続時間と重大度は相関しないことを示した(Source: [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]])。 「23 時間 11 分で顧客影響ゼロ」と「21 分で Critical 顧客影響」が共存する。 ![[_attachments/srecon22americas-nash-incident-metrics/page-016.png]] **図2-2**:Honeycomb の持続時間と顧客影響。23 時間 11 分で影響ゼロの棒と、21 分で Critical の棒が共存し、持続時間を重大度の代理にできないことを示す。 (Source: [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]], p.16) 重大度は測定値ではなく、社交的な調整物(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?]]) ![[_attachments/2016__SREcon16__nrrd-911-ic-me-The-Incident-Commander-Role/page-022.png]] **図2-3**:New Relic の 5 段階重大度。Sev1 は「すべてが爆発した」状態であり、後述の Sev1 拡張役割が解放される閾値でもある。 (Source: [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]], p.22) ![[_attachments/srecon24americas-ruppe-incident-severity/frame-006.jpg]] **図2-4**:緊急度と不確実性の 2 軸で Bug から P0 までを置くマトリクス。影響と優先度を単一の計算に合成しようとする試みの例である。 (Source: [[@2024__SREcon24 Americas__What Is Incident Severity, but a Lie Agreed Upon?]], frame-006) ![[_attachments/srecon24americas-ruppe-incident-severity/frame-016.jpg]] **図2-5**:重大度の 5 命題。測定可能、実行可能、期待値を設定する、画一適用できない、カナリアである。摩擦そのものを組織課題の診断シグナルとする本文の第 3 の処方箋に対応する。 (Source: [[@2024__SREcon24 Americas__What Is Incident Severity, but a Lie Agreed Upon?]], frame-016) --- ## 第 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** | 長期化した場合の計画策定 | ![[_attachments/2016__SREcon16__nrrd-911-ic-me-The-Incident-Commander-Role/page-010.png]] **図3-1**:ICS の基本 3 役。IC の下に TL と CL が並列し、指揮と報告の方向が矢印で示される。SRE Book の 4 役から Planning Lead を除いた最小形である。 (Source: [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]], p.10) ![[_attachments/anatomy-of-an-incident/ch04-fig4-4-ics-hierarchy.png]] **図3-2**:ICS 階層の例。IC の下に Operations、Planning、Logistics、Communications の 4 リードが並ぶ。SRE Book がソフトウェアへ移した 4 役割と対応する。 (Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]], 図 4-4) 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 を示す、公開されている最古の実績報告である。 ![[_attachments/2016__SREcon16__nrrd-911-ic-me-The-Incident-Commander-Role/page-023.png]] **図3-3**:Sev1 で解放される拡張役割。EC が最上位に加わり、IC の直下に TL、LL、CL が並ぶ。LL はシフト管理や食事手配などのロジスティクスを担う。 (Source: [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]], p.23) ### 第 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 つである。 コミュニケーション(技術と非技術の両方の語り口)、社会技術的リーダーシップ(技術の外の問題を識別する力)、認知負荷管理(複数の作業ストリームを切り替えながら全体状況を維持する力)。 ![[_attachments/sre26amer_slides_huerta-granda/page-019.png]] **図4-1**:IC のコアコンピテンシーを社内で識別するシグナル。コミュニケーション、社会技術的リーダーシップ、認知負荷の 3 軸は、役職やオンコール適性とは独立である。 (Source: [[@2026__SREcon26 Americas__So You Want a New Incident Commander]], p.19) #### 最小導入としての「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 相当): 技術的な問題解決。 重大度や命令系統を意図的に排除し、チーム単体で今日からでも始められる規模に縮小している。 成熟度の低い組織でも着手可能な入り口として位置づけられる。 ![[_attachments/srecon23amer-wood-ics-ambulance/frame-006.jpg]] **図4-2**:3 つの帽子。Organizer は調整、Connector は内外の橋渡し、Expert は手を動かして系に介入する。正式な ICS 役割を、対応に必須の核へ縮小した最小導入である。 (Source: [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]], frame-006) #### 複数インシデントの統制 [[Brent Chapman]](Slack)は、同時多発インシデントが増えるにつれ単一の IC では解決しない「インシデント間のリソース競合」に直面し、公共安全 ICS から **Area Command** を輸入した(Source: [[@2021__SREcon21__Evolution of Incident Management at Slack]])。 Area Command は、他のインシデントを俯瞰して優先順位付けと仲裁を行うメタ統制層である。 ![[_attachments/srecon21-chapman-incident-mgmt-slack/page-010.png]] **図4-3**:Slack のインシデント管理を Response、Review、Analysis の 3 部で捉えた図。同時多発への Area Command は、この Response 層が単一 IC では足りなくなったときに導入された。 (Source: [[@2021__SREcon21__Evolution of Incident Management at Slack]], p.10) ### 第 5 章　フォロワーシップ IC の設計論は「IC をどう選び育てるか」に組織的関心を集中させる。 しかし対応者の大半は IC ではなく「フォロワー」である。 [[Laura Maguire]](Jeli, SREcon23 Americas)は、この関心の非対称性を問題視し、**フォロワーシップ(Followship)**を提唱した(Source: [[Followship]])。 フォロワーシップとは、共通の目標のために協働する経験豊富な対応者たちの「適応的コレオグラフィ(adaptive choreography)」である。 ![[_attachments/2023-srecon-maguire-organizational-response-incidents/page-019.png]] **図5-1**:注意の非対称。組織的関心は IC 個人へ集中する一方、実際の影響は対応者チーム側に生じ、怒った VP からの要求も IC へ向かう。 (Source: [[@2023__SREcon23Americas__An Organizational Response to Incidents]], p.19) #### 調整のパラドックス 複雑適応系ではあらゆる人のメンタルモデルは部分的にしかなり得ない(Woods, 2017)。 非定型の事象に対処するには多様な視点の統合が必要だが、他者と協働すること自体が追加の認知負荷(Cost of Coordination, CoC)を生む。 対応者はこの負荷に DELEGATE(委任)、DELAY(後回し)、DIMINISH(優先度低下)、DROP(切り捨て)という 4 戦略で対処する。 ![[_attachments/2023-srecon-maguire-organizational-response-incidents/page-025.png]] **図5-2**:増大する協調負荷への 4 戦略。DELEGATE、DELAY、DIMINISH、DROP は、フォロワーが認知負荷を管理する具体的な行動である。 (Source: [[@2023__SREcon23Americas__An Organizational Response to Incidents]], p.25) #### フォロワーの 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: テスト** | 仮説を検証し、確認後に修正する | ![[_attachments/srecon26americas-kingsman-epistemology/page-003.png]] **図7-1**:SRE Book の Incident Loop。Triage、Examine、Diagnose、Test/Treat が縦に連なり、状況変化時は再トリアージへ戻る。Kingsman の 5 フェーズはこのループを基盤にする。 (Source: [[@2026__SREcon26Americas__Epistemology of Incident Management]], p.3) #### 認識ツール 1: 証拠 2×2 マトリクス 証拠を出所の直接性(Direct / Indirect)と変化状況(Changing / Stable)の 2 軸で分類し、収集の優先度をつける。 - **Direct-Changing**: 最高信頼度。今起きていることを直接示す。 - **Direct-Stable**: 長期的根本原因を示す可能性が高い。 - **Indirect-Changing**: 変化の徴候として有用だが解釈を要する。 - **Indirect-Stable**: 最低信頼度。補足情報としてのみ使う。 ![[_attachments/srecon26americas-kingsman-epistemology/page-018.png]] **図7-2**:検査フェーズでの証拠分類の実例。Evidence、Correlated/Causal、Nominal、Odd but Uncorrelated に分け、見当違いの手がかりを切り分けながら仮説の材料を揃える。 (Source: [[@2026__SREcon26Americas__Epistemology of Incident Management]], p.18) #### 認識ツール 2: 探索パターン 3 種 - **線形探索(Linear Search)**: ユーザー側の末端から順に「正常か異常か」を判定しながら根本へ進む。 - **2 分探索(Binary Search)**: 確認するコンポーネントを毎回半分に絞る。 - **変化誘導(Induced-Change)**: 意図的に変化(再現テスト、無効化、負荷変更)を加えて反応を観察する。証拠が乏しいときに能動的に証拠を生成する戦略である。 ![[_attachments/srecon26americas-kingsman-epistemology/page-020.png]] **図7-3**:線形探索。Edge から Auth、LB、Compute、Cache、Storage、Egress へと末端から根本へ順に当たり、各コンポーネントを正常か異常かで切り分ける。 (Source: [[@2026__SREcon26Americas__Epistemology of Incident Management]], p.20) ![[_attachments/srecon26americas-kingsman-epistemology/page-021.png]] **図7-4**:2 分探索。同じ要求経路を半分に割り、LB と Compute の間など分割点を動かして障害区間を絞り込む。 (Source: [[@2026__SREcon26Americas__Epistemology of Incident Management]], p.21) #### 認識ツール 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]])。 ![[_attachments/2023-srecon-maguire-organizational-response-incidents/page-067.png]] **図8-1**:共通基盤を構成する知識の 4 象限。team、others、technical system、organization が相互に更新され、引き継ぎで明示的に受け渡される対象になる。 (Source: [[@2023__SREcon23Americas__An Organizational Response to Incidents]], p.67) #### 引き継ぎコミュニケーション **引き継ぎ(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 の所要時間を考慮すると、ロールバックやアドホック修正が優先されるためである。 ![[_attachments/arxiv-2504.08865/fig1-figure.png]] **図9-1**:GenAI クラウドサービスのインシデント管理。検知、トリアージ、診断、緩和が循環し、検知から緩和までが TTM として測られる。コード修正よりロールバックが先行する本文の観察は、この最終段の選択である。 (Source: [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]], 図 1) また自己回復が 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%)である。 ![[_attachments/How_to_Manage_Change-Induced_Incidents_Lessons_from_the_Study_of_Incident_Life_Cycle/fig2-figure.png]] **図10-1**:変更起因インシデントのライフサイクル。デプロイ開始から障害発生(導入)、検知(TTD)、緩和(TTM)が時間軸上に並ぶ。変更中が最もリスクの高い時間帯であることの構造図である。 (Source: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]], 図 2) クラウド障害ライフサイクルの 354 件分析でも、58.8% が変更中に発生し、そのうち 84.7% が内部原因(設定ミス、コード変更)であった。 変更プロセス中が最もリスクの高い時間帯であるという構造は、独立したデータセットで一致する。 変更起因インシデントの 50.6% ではユーザーがモニタより先に異常を検知した。 自動検知の網からすり落ちるインシデントの過半が変更操作中に発生しているという事実は、デプロイパイプラインへの検知強化が最優先であることを示す。 ![[_attachments/How_to_Manage_Change-Induced_Incidents_Lessons_from_the_Study_of_Incident_Life_Cycle/fig4-figure.png]] **図10-2**:検知手段別の TTD の累積分布。モニタ報告は早期に立ち上がり、ユーザー報告は遅れが残る。ユーザーが先に気づく事例が多いという本文の数値は、モニタ網の穴をこの差として示す。 (Source: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]], 図 4) ![[_attachments/An_Empirical_Study_on_Change-induced_Incidents_of_Online_Service_Systems/fig3-figure.png]] **図10-3**:変更管理のワークフロー。変更票と CM システムを経てデプロイし、顧客とモニタがインシデントを検知してオンコールが緩和する。変更プロセス中に検知を厚くする位置がここである。 (Source: [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]], 図 3) --- ## 第 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]])。 コンダクター質問が疲労、食事、時刻、心理的安全を問うのはその実践形態である。 ![[_attachments/srecon23americas-davis-human-observability/page-011.png]] **図11-1**:Response Trio。conductor、communication、problem solver が三角形をなし、ステークホルダーは communication 経由でつながる。人間側の役割を観測対象にする出発点である。 (Source: [[@2023__SREcon23Americas__Human Observability of Incident Response]], p.11) ![[_attachments/srecon23americas-davis-human-observability/page-030.png]] **図11-2**:コンダクターが自問する 8 項目。Response Trio 上の位置、共通通信、疲労と食事、競合優先事項、時刻など、技術状態ではなく人間の状態を問う。 (Source: [[@2023__SREcon23Americas__Human Observability of Incident Response]], p.30) 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**: スケールする自動化設計。 「アーキテクチャの水準には上がれない。システム思考の水準に落ちる」。 この主張は、アーキテクチャの複雑性が増すほど人間の全体俯瞰能力の相対的価値が上がるという意味である。 ![[_attachments/2026__SREcon26Americas__Human-Factors-in-the-Age-of-AI-Ops/page-039.png]] **図11-3**:P1 におけるシステム思考。アラートを個別に追う反応モードに対し、影響範囲の把握、信号の相関、人間による AI 仮説の検証、単一 IC による流れの所有を対置する。 (Source: [[@2026__SREcon26Americas__Human Factors in the Age of AI Ops]], p.39) ### 第 12 章　ストレスと回復 #### オンコールストレスの生理学 [[Beth Adele Long]](SREcon26 Americas)は、オンコール業務に伴う 2 種類のストレスを区別した(Source: [[オンコールストレス管理]])。 慢性ストレス(ページャーを持ち続ける負荷)と急性ストレス(インシデント対応中の超警戒状態)である。 自律神経系(ANS)は本来、自己修正機能を持つ。 しかし合理的思考(Ordinary Mind)による抑制がかかると自己修正が働かなくなる。 解法は身体知性に根ざした 4 つの実践ツール(ボディスキャン、呼吸法、自発的な動き、退屈)である。 ![[_attachments/srecon26americas-long-destressing/page-026.png]] **図12-1**:自律神経系は自己修正するが、Ordinary Mind が抑制すると働かなくなる。オンコールの慢性ストレスと対応中の急性ストレスが、この遮断を固定する。 (Source: [[@2026__SREcon26Americas__The Critical Resource Is You - Practical Destressing for On-Call Engineers]], p.26) ![[_attachments/srecon26americas-long-destressing/page-040.png]] **図12-2**:4 つの実践ツール。ボディスキャン、呼吸、動き、退屈により、系が自己管理できるようにする。 (Source: [[@2026__SREcon26Americas__The Critical Resource Is You - Practical Destressing for On-Call Engineers]], p.40) #### インシデント後の人的回復 Jaime Woo(SREcon18 Americas)は Shopify の 40 名を対象に調査し、42.5% がインシデント後に強いストレスを報告した(Source: [[インシデント後の人的回復]])。 80% が組織的サポートをほぼ受けていないとも報告している。 ![[_attachments/srecon18americas-woo-developer-recovery/page-010.png]] **図12-3**:インシデント後 1 ヶ月の変化。睡眠、集中、気分は「悪化」に偏り、食欲は変化なしが多い。システムの復旧後も人間側の負荷が残る根拠である。 (Source: [[@2018__SREcon18Americas__Your System Has Recovered from an Incident, but Have Your Developers]], p.10) ![[_attachments/srecon18americas-woo-developer-recovery/page-018.png]] **図12-4**:「誰かが様子を聞いてくれるか」。40 名中 80% がほぼ受けていない側に落ち、組織的ピアサポートの欠如を示す。 (Source: [[@2018__SREcon18Americas__Your System Has Recovered from an Incident, but Have Your Developers]], p.18) 医師の二次被害者研究(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 する時間」に置き換えられた。 ![[_attachments/srecon22americas-nash-incident-metrics/page-013.png]] **図13-1**:VOID 全組織の持続時間分布。1〜4 時間にピークがあり、72 時間超まで右裾が伸びる。平均(MTTR)がノイズになる統計的問題の根拠である。 (Source: [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]], p.13) ![[_attachments/srecon22americas-nash-incident-metrics/page-015.png]] **図13-2**:MTTR 改善のモンテカルロシミュレーション。3 社とも相対変化の分布が広く、実際の改善を統計的に見分けるのが困難であることを示す。 (Source: [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]], p.15) #### 代替指標のフレームワーク インシデント件数も MTTR も機能しない場合、何を測るべきか。 Luck と de Vesine(Datadog, SREcon25 Americas)は、インシデント管理プロセスの「目標ごと」に指標を当てる方式を提案した。 | 目標 | 測定例 | |---|---| | オンコール持続可能性 | 深夜ページ数、シフト長、フェアネス知覚サーベイ | | インシデントが真剣に扱われる | ステートマシン完走率、自発的ポストモーテム率 | | インシデント対応の質 | 役割使用率、感情分析(自信、準備感) | | 事後学習と改善 | アクションアイテム速度、繰り返しインシデント率 | 顧客信頼性はこのリストに含まれない。 それは SLO で直接測定すべき別の問題である。 ![[_attachments/srecon25americas-de-vesine-incident-management-metrics/page-044.png]] **図13-3**:Datadog が実際に測っている項目の一覧。オンコール負荷、役割使用、自発的ポストモーテム、繰り返しインシデントなど、本文の目標別指標に対応する。 (Source: [[@2025__SREcon25Americas__Incident Management Metrics that Matter]], p.44) ![[_attachments/srecon25americas-de-vesine-incident-management-metrics/page-046.png]] **図13-4**:目標から指標を当てる 4 ステップ。合意、目標の特定、指標の特定、定義と拡張の循環であり、顧客信頼性は SLO 側の別問題として切り離す。 (Source: [[@2025__SREcon25Americas__Incident Management Metrics that Matter]], p.46) --- ## 第 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)で構成される。 ![[_attachments/sre-next-2024/page-026.png]] **図14-1**:インシデント対応成熟度の 4×3 マトリクス。横軸が Absent から Strategic、縦軸が Pre-Incident、Response、Post-Incident。各セルに 9 プロセスの状態が入る。 (Source: [[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]], p.26) ![[_attachments/sre-next-2024/page-027.png]] **図14-2**:成熟度の概要表。9 プロセスそれぞれを 4 段階の状態記述で定義し、IC 導入が Proactive 以降で効く前提を読み取れる。 (Source: [[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]], p.27) IC の導入は Proactive 以降で効果を発揮する。 「さまざまな前提が整って初めて効果を発揮する、企業によっては単なるオーバーヘッドになりうるベストプラクティス」である(Takamura)。 ### 第 15 章　ChatOps ChatOps は、チャットプラットフォームを運用操作の主要インターフェイスとする実践パターンである(Source: [[ChatOps]])。 [[Al Tobey]](Netflix, SREcon16)の Scorebot は典型実装であり、以下の機能パターンを確立した。 - **bookmarking**: タイムスタンプとメモの記録。タイムライン構築の起点。 - **presence**: 実際にキーボードの前にいるかを追跡する。 - **after-hours**: 夜間の問い合わせに自動応答し、緊急時はページを促す。 - **archive**: 絵文字リアクションで発言にタグ付けし、インシデントレポートの自動生成を目指す。 「ボットに機能を詰め込みすぎない」ことが設計原則である。 ロジックは独立したデーモンとして動かし、ボットはそれらへの薄いインターフェイスにとどめる。 Slack が落ちても本質ロジックは別で動く。 ![[_attachments/2016__SREcon16__nrrd-911-ic-me-The-Incident-Commander-Role/page-038.png]] **図15-1**:ChatOps による IC 宣言。`nrrd 911 ic me` で役割割り当てとチェックリストがチャットに残り、開始時刻の記録とタイムライン構築の起点になる。 (Source: [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]], p.38) ![[_attachments/2016__SREcon16__nrrd-911-ic-me-The-Incident-Commander-Role/page-042.png]] **図15-2**:インシデント終了の ChatOps。`nrrd 911 over` が所要時間を記録し、IC と CL へ事後タスクを配信する。ボットは薄いインターフェイスにとどまる実装例である。 (Source: [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]], p.42) ### 第 16 章　アンインシデント 潜在インシデントの 30〜60% が正式なトラッキングを通過しない。 [[Andreas Deuschl]](Dynatrace, SREcon25 EMEA)はこれを**アンインシデント(Un-Incident)**と名づけた(Source: [[アンインシデント]])。 #### 4 類型 | 類型 | 定義 | |---|---| | **No-CI** | 顧客影響があるが既存分類に当てはまらない | | **NOF** | 外部要因に起因し自組織の責任外と判断される | | **Near Miss** | 幸運または予防的行動でエスカレーションを免れた | | **Fear Miss** | 不安による不必要なエスカレーション | ![[_attachments/2025__SREcon25EMEA__The-Un-Incident/page-005.png]] **図16-1**:アンインシデントの規模。宣言されない、見落とされる、議論のまま終わる、という 3 状態と、正式トラッキングを通過しない 30〜60% を示す。 (Source: [[@2025__SREcon25EMEA__The Un-Incident]], p.5) 「インシデントか否か」という問いを「何を学べるか」に転換することが中心テーゼである。 対処の骨格は Gray Zone Playbook として示される。 マインドセット(宣言を阻まない、宣言に感謝する、事実ベースのトリアージ)、ストラクチャー(オブザーバビリティへの信頼構築、SLO による微細劣化の早期検出)、プロセス(簡単にトリガーできる事後分析への接続)の 3 層で構成される。 ![[_attachments/2025__SREcon25EMEA__The-Un-Incident/page-013.png]] **図16-2**:Gray Zone Playbook。左に 4 類型、右に Mindset、Culture、Structure、Process、Fact-based Decisions の循環を置く。グレーゾーンを学習対象へ転換する骨格である。 (Source: [[@2025__SREcon25EMEA__The Un-Incident]], p.13) ![[_attachments/2025__SREcon25EMEA__The-Un-Incident/page-015.png]] **図16-3**:マインドセットの 3 本柱。宣言を阻まない、宣言に感謝する、事実ベースのトリアージ。No-CI、Near Miss、Fear Miss に適用される。 (Source: [[@2025__SREcon25EMEA__The Un-Incident]], p.15) ![[_attachments/2025__SREcon25EMEA__The-Un-Incident/page-020.png]] **図16-4**:アンインシデントのレビュー経路。No-CI と Near Miss を軽量レビューや事後分析へ接続し、Fear Miss と NOF は既存インシデント経路を通す。 (Source: [[@2025__SREcon25EMEA__The Un-Incident]], p.20) --- ## 第 VIII 部　訓練 ### 第 17 章　インシデントシミュレーション 「同じインシデントを二度経験することは不可能」という根本的制約を緩和する手段が、インシデントシミュレーションである(Source: [[インシデントシミュレーション]])。 #### ステージドワールド [[David D. Woods]] と Hollnagel(2006)が定義した手法で、4 つの特性を持つ。 シミュレーションシナリオ、十分な忠実度、専門性を引き出す設計、唯一解がないことである。 ![[_attachments/srecon24emea-silatani-groundhog-day/frame-005.jpg]] **図17-1**:同じインシデントを二度見ない理由。日付、時刻、市場、人、第三者依存、ソフトウェア、メンタルモデルが毎回異なる。シミュレーションが必要な根本制約である。 (Source: [[@2024__SREcon24EMEA__Incident Groundhog Day]], frame-005) ![[_attachments/srecon24emea-silatani-groundhog-day/frame-007.jpg]] **図17-2**:ステージドワールドの 4 特性。模擬シナリオ、十分な忠実度、専門性を引き出す設計、唯一解がないこと。Woods と Hollnagel(2006)の定義に対応する。 (Source: [[@2024__SREcon24EMEA__Incident Groundhog Day]], frame-007) [[Hamed Silatani]](Uptime Labs, SREcon24 EMEA)は 20 名を対象にステージドワールド実験を行い、2 つの行動パターンを同定した(Source: [[@2024__SREcon24EMEA__Incident Groundhog Day]])。 - **Solo Artist**: 全負担を一人で抱え、ストレスが高い。 - **Band Member**: 早期にチームメンバーを巻き込み、ワークロードと思考力を分散する。 ![[_attachments/srecon24emea-silatani-groundhog-day/frame-020.jpg]] **図17-3**:Solo Artist と Band Member の通信頻度。Band Member は早期から通信が密で、ワークロードを分散する。技術スキルより組織的行動が成否を分ける観察の根拠である。 (Source: [[@2024__SREcon24EMEA__Incident Groundhog Day]], frame-020) 解決時間は参加者の経験や能力レベルと相関しなかった。 むしろ重大度の議論に費やした時間や、チームの巻き込み方が有意な行動差として浮上した。 技術的スキルより組織的な行動が成否を分けるという洞察は、訓練設計に含めるべき要素を示唆する。 #### Allspaw の 4 活動カテゴリ | カテゴリ | 内容 | |---|---| | **Diagnostic** | 信号を吸収し推論を行う | | **Therapeutic** | 問題を修正しようとする介入 | | **Recruiting** | 専門性と権限を持つ人を巻き込む | | **Status/Reporting** | 記録の作成とステークホルダーへの報告 | ![[_attachments/srecon24emea-silatani-groundhog-day/frame-015.jpg]] **図17-4**:Allspaw の 4 活動カテゴリ。Diagnostic、Therapeutic、Recruiting、Status/Reporting。失敗したロールバックが新たな診断シグナルになる、という本文の主張の分類枠である。 (Source: [[@2024__SREcon24EMEA__Incident Groundhog Day]], frame-015) 治療的行動(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 | ![[_attachments/Incident_Buddy_AI_Edition/page-010.png]] **図18-1**:SAE 自動運転レベルを IR0〜IR5 へ写像した表。IR2 は判断支援と提案、IR3 は実行と監視の責任も AI が持つ。 (Source: [[@2025__SRE NEXT 2025__Rethinking Incident Response - Context-Aware AI in Practice]], p.10) 2025 年時点で IR0〜IR2 は実現済みとされ、MCP(Model Context Protocol)とコーディングエージェントの進展により IR2〜IR3 の実現可能性が出てきたとされる。 IR3 到達には「AI に任せられる安全な操作の定義」が必要である。 ![[_attachments/Incident_Buddy_AI_Edition/page-012.png]] **図18-2**:IR2+ のフロー。監視やサポートを起点に MCP で原因推測と変更履歴を取り、修正案を PR 化し、人間がレビューしてデプロイする。安全な操作の境界を人間側に残す設計である。 (Source: [[@2025__SRE NEXT 2025__Rethinking Incident Response - Context-Aware AI in Practice]], p.12) #### TSG 自動化 TSG(Troubleshooting Guide)を LLM エージェントで実行する問題は、Microsoft の 3 本の論文で設計空間として立ち上がった(Source: [[インシデント管理]])。 - **FLASH**: インシデント時にオンラインで TSG を実行する。 - **StepFly**: オフラインで DAG を抽出し、並列スケジューラで実行する。 - **LLexus**: 計画フェーズを前置し、実行時は決定論的に走らせる。 3 本に共通する最大の発見は、**TSG 品質が自動化の律速**であることである。 FLASH の曖昧アクション(Ambiguous Action)が TSG の約 40% を占め、LLexus では低品質 TSG で計画コストが約 3 倍に膨らむ。 ![[_attachments/FLASH_Paper/fig1-architecture.png]] **図18-3**:FLASH のアーキテクチャ。TSG を入力に、状態推論、思考、ツール呼び出し、リフレクションを回す。オンラインで TSG を実行する設計であり、TSG 品質が律速になる理由がこのループの入力側にある。 (Source: [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]], 図 1) 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レベル]], [[インシデント管理]] 横断的知見 |