# インシデント管理 ## 定義 インシデント管理（Incident Management）は、クラウドサービスにおけるサービス違反や性能劣化を**検知→トリアージ→診断→緩和**の 4 段で処理するライフサイクル全体を指す。[[AIOps]] の 4-level taxonomy（検知/箇所特定/RCA/緩和）がタスク能力として各段を縦に切るのに対し、インシデント管理はライフサイクルを横断する運用プロセスとしての視座を提供する。[[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] は [[Microsoft]] の GenAI クラウドサービス（Azure OpenAI 等）の本番インシデント 4 年分を分析し、GenAI 固有のインシデント特性——監視の未成熟（38.3% が人手検知）、症状と根本原因の多対多マッピング、緩和戦略の多様化（アドホック修正 22.4% 対 非 GenAI 54.7%）——を定量化した。 ## 横断的知見 - **AIOps エージェント評価が想定するインシデント像と本番インシデントの乖離**: [[AIOpsLab]] や [[SREGym]] は障害注入（[[ChaosMesh]] / eBPF）によるインシデントを評価対象にするが、本番インシデントの根本原因分布は設定問題 24.5%・外部利用 14.1%・運用操作ミス 12.7% を含み、障害注入で再現しにくい種別が過半を占める。学術ベンチマークが Infrastructure Issue（27.2%）やコードバグ（21.5%）を対象にしても、本番インシデントの半分以上はカバーできない可能性がある。(Source: [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **インシデントタイムライン(Slack スレッド)が「専門家アノテーションの一次源」として AI 評価に直接使われ始めた**: [[ARFBench]]([[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]])は、[[Datadog]] エンジニアの Slack インシデントタイムライン(障害検知から緩和までの議論スレッド)を、専門家の推論(問う質問・調べる証拠・導く結論)のリアルタイム記録とみなし、時系列質問応答([[時系列質問応答]])ベンチマークの正解ラベルの一次証拠に転用する。これは [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] が OCE の事後インシデント報告を分析対象にしたのと同じく、**人間の運用記録を AI 研究の一次データに昇格させる**流れ。ARFBench は ICSE 研究と同じインシデント対応の段階構造(報告→診断→トリアージ→緩和→復旧→RCA→postmortem)を引きつつ、その中で TSQA がトリアージ・緩和・RCA に効くと位置づける(Appendix A.2)。(Source: [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]], [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]) - **アラートライフサイクル全体最適化という処理単位の出現**: 既存のインシデント管理スレッドが単発の検知/診断/緩和や [[LogPilot]]([[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]])の**単発アラート診断**を扱うのに対し、[[AlertGuardian]]([[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]])は denoise→summary→rule refinement を**一気通貫のライフサイクル**として扱う初の experience paper で、本番([[Tencent]] と読める Company-X)で MTTR 156→21 分(7.4 倍)・日次アラート 30 万→1.5 万を達成する。同じ ASE2025 の LogPilot と並べると「単発アラート診断 対 ライフサイクル全体最適化」という対比軸が立つ——両者は同じ大規模オンラインサービスの本番アラートを対象にしながら、処理の切り出し単位(単発の 1 アラート 対 アラート群のライフサイクル)が異なる。(Source: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - **rule refinement という上流介入(下流の抑制でなく上流のルール品質でアラート疲弊を断つ)**: [[LogPilot]] の単発アラート診断や ICSE 研究の事後分析を含め、多くのインシデント管理研究は「鳴ったアラートをどう捌くか」(下流)に集中する。これに対し [[AlertGuardian]] は**アラートルール自体を改善する**フィードバックループ(オーケストレータなし 4 エージェント Detect/RAG/Rule/Review + 反復、停止条件=構文・重要アラート保持・ノイズ比 5%、30 反復上限)を持ち、human-in-the-loop で 1,174 提案→375 受容(32%)という上流介入を行う。アラート疲弊を下流の抑制でなく上流のルール品質で断つ設計は、検知/診断の精度向上に閉じてきたインシデント管理研究に「ルール生成・改善」という新しい介入点を示す。(Source: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - **インシデント対応ループを「証拠 → 仮説 → 緩和 → 変更記録」の翻訳の連鎖として捉え、各継ぎ目にエージェントを置く**: 本 wiki は ICSE 研究で本番インシデントのライフサイクル(検知→トリアージ→診断→緩和→学習)を、ARFBench で Slack タイムラインを一次データ化する流れを記録してきた。[[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]] は同じライフサイクルを detect/triage/diagnose/mitigate/learn と置きつつ、エージェントの価値は段そのものでなく**段と段の継ぎ目**——チケット文 → テレメトリクエリ、テレメトリ結果 → 仮説、仮説 → 緩和、緩和 → 変更記録という人間が時間を費やす翻訳——にあると整理する(§VI-C)。タスク taxonomy(表IV)も incident triage & routing・evidence acquisition・RCA・remediation planning・change safety & rollout control を、各々の入力・ツール面・運用上の成功基準で定義する。本 wiki がライフサイクルの「段」を縦に切ってきたのに対し、サーベイは「継ぎ目の翻訳」を agentic 化の主戦場として横に切る視座を加える。(Source: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]], [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]) - **LLexus が示す「計画フェーズ前置」と「FLASH/NissIST との設計原理の収束と分岐」**: [[LLexus]]([[@2024__OSR__LLexus - an AI agent system for incident management]])は、Microsoft の SaaS 製品向けに TSG の実行を自動化する AI エージェントシステムである。FLASH や NissIST(An et al. [2])が「インシデント時に LLM を使う」のに対し、LLexus は LLM の使用を**インシデント時でなく計画フェーズ(TSG 作成・更新時)に前置**し、実行時は決定論的プランをそのまま走らせる。これにより、インシデント件数が増えるほどコスト優位性が拡大し(少数インシデントでオンライン方式とコストが逆転)、実行時のハルシネーションリスクが最小化される。一方で FLASH と同様、**TSG の品質が自動化の律速**という共通の壁にぶつかる——品質の低い TSG は多くの反復ラウンドを要し、計画コストが 3 倍近く増大する。LLexus 独自の重要な知見は「TSG を source of truth として扱うことで、自動化の副産物として TSG の品質も向上する」という正のフィードバックループが成立する点である。(Source: [[@2024__OSR__LLexus - an AI agent system for incident management]], [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]) - **TSG 駆動のワークフロー自動化という反復インシデント固有の診断パターン**: [[FLASH]]([[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]])は、反復インシデントが TSG(Troubleshooting Guide)という構造化ドキュメントを持つ固有性に着目し、「TSG を与えれば LLM エージェントが診断を自動実行できるか」という問いを設定する。既存の RCA 研究が「何が根本原因か」の同定に集中するのに対し、FLASH は「TSG に書かれた診断ステップをエージェントが信頼実行できるか」という実行信頼性問題として問いを立て直す。5 シナリオ・250 件の評価で TaskWeaver 比 +13.2% を達成したが、CAPA のような外部ツール依存シナリオでは精度が 50% 程度にとどまり、TSG の品質(Ambiguous Action が全 TSG の約 40%)が自動化可否の主要律速となることを定量化した。これは本 wiki の他のインシデント管理ソース(AlertGuardian・LogPilot)が「アラートのライフサイクル」を単位にするのと異なり、FLASH は**反復インシデントという特定パターンのインシデント種別**を単位として診断ワークフローを閉じる。(Source: [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]) - **「軽量 MAS+自己進化」という新しいトレードオフ軸が MAS 型 IM に出現**: 既存 MAS 型 IM([[D-Bot|@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]]・Flow-of-Action)は GPT-4 等の closed-source LLM と静的 SOP/知識ベースに依存し、再学習なしの経験蓄積機構を持たない。[[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]] の OpsAgent は 14B の軽量オープンモデルを推論コアとし、PPO 強化学習(内部パラメータ更新)と反省ベース知識蒸留(外部 RAG 蓄積)の二重自己進化で継続的能力成長を可能にする。[[OpenRCA]] ベンチマークで SOTA(RCA-Agent w/Claude 3.5 Sonnet)比 Correct +46.63%、[[Lenovo]] 本番 53 日・10,492 件で 84.09% 精度・解決時間 2.5 時間→126 秒を達成した。「大型 closed-source モデルで高精度」対「小型 open-source モデル+自己進化で高汎化・低コスト」というトレードオフは、本番展開可能な MAS 型 IM の新しい設計軸となる。(Source: [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]], [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]]) - **異種テレメトリの統一テキスト化が MAS 協調の前提条件**: OpsAgent の training-free データプロセッサ(メトリクス: 3σ 検知+CNN 形状分類、ログ: keyword+TF-IDF、トレース: 95 パーセンタイル高レイテンシスパン+3 ホップ呼び出しパス)は、異種オブザーバビリティデータを全エージェントが共通利用できるテキスト記述に変換する。アブレーション研究でプロセッサ除去時の Correct 率は 16.54%→2.26% と激減し、LLM が生の数値入力を苦手とすることを定量的に裏付ける。これは [[マルチモーダル障害診断]] で DL モデルが生テレメトリを直接処理するのとは対照的な「テキスト変換によるモダリティ統一」アプローチで、cross-system 汎化と解釈可能性を同時に実現する。(Source: [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]] §3.2, Table 2) - **IMAG の上に被せる agentic orchestration layer は、人間 ICS の 4 役割をエージェントに写像する**: SRE Book Ch14 の ICS 4 役割(Incident Commander / Operations / Communications / Planning)に対し、Google SRE AI は IMAG プロセスの上に **4 種のエージェント**を被せる:(1) **コミュニケーション面の監視・集約**(incident response tools / chat / videos / tracking docs を横断的に要約)、(2) **SRE 間ハンドオフ文書生成**、(3) **ポストモーテム下書き作成**(品質向上 + SRE 工数削減 + 必要情報の網羅性確保)、(4) **内外コミュニケーション管理**。いずれも**人間 IC を置き換えない補助層**で、これは [[SRE AI Autonomy Levels]] の Self-Direct 軸を Mitigate と分離して保つ Google の方針を IMAG 側でも貫いている。([[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] が抑制した「フリーランシング」を、agentic 補助層でも抑制する形式と解釈できる。)(Source: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]], [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]], [[SRE AI Autonomy Levels]]) - **プレイブックは静的ドキュメントでなく「使われながら直る」production artifact**: SRE Book Ch6 は「プレイブックは MTTR を 3 倍改善する」と人間運用での効果を示したが、本ブログは一段先に進み、Google SRE AI は**プレイブックの保守自体を agentic loop に組み込む**(エージェントが利用実態を監視 → 改善提案 → インシデントから新規プレイブック生成)。これは [[TSG自動化]] が論じる「TSG の品質が自動化可否の主要律速」という FLASH/LLexus の知見(Ambiguous Action が TSG の 40% を占める問題)に対する、Google 流の対処パスとも読める——**律速になる TSG を、それ自身を agentic に育てるフィードバックループ**で解こうとする方向。(Source: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]], [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]], [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]], [[TSG自動化]]) - **FlowXpert が示す「ワークフロー生成」——TSG 実行(Microsoft 3 本)の上流問題**: [[FlowXpert]]([[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]], KDD 2025)は、[[FLASH]]/[[LLexus]]/[[StepFly]] が前提とする「既存 TSG の存在」を仮定せず、**運用ドキュメントから TSG を生成する**問題に取り組む。Huawei Cloud では 189 種のインシデントに対してワークフローを手作成していた(7 人×7 時間/1 件)が、FlowXpert は 22.1 秒に短縮し 10 週間本番展開で承認率約 80% を達成した。ワークフロー生成 → 実行の 2 段パイプライン(FlowXpert が生成し FLASH/LLexus 型が実行)は論文未検討だが、次の自然な発展として立つ。また FlowXpert は「Scorer の AI フィードバック品質」を DPO で改善する共進化アーキテクチャを持ち、Microsoft 3 本が「TSG 品質が自動化の律速」と指摘したのと並行して「AI フィードバック品質が RL の律速」という別のボトルネックを同時に解決しようとする。(Source: [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]]) - **TSG 自動化という反復インシデント固有のサブ問題が、Microsoft 3 本で設計空間として立ち上がった**: [[FLASH]](オンライン status supervision)・[[StepFly]]([[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]]、オフライン DAG+QPP 抽出 + 並列 scheduler-executor)・[[LLexus]](計画前置 + 決定論的実行)は、いずれも「既存 TSG を LLM エージェントで実行する」という同じ問いを、LLM を働かせる時点(インシデント時/計画時/両方)で別々に解く。3 本に共通する最強の発見は **TSG 品質が自動化の律速**であること——FLASH の Pass 約 8.5%、StepFly の専用ツール [[TSG Mentor]]、LLexus の低品質 TSG で計画コスト約 3 倍が独立に同じ壁を指す。この反復インシデント固有のサブ問題は [[TSG自動化]] に切り出して横断集約する。(Source: [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]], [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]], [[@2024__OSR__LLexus - an AI agent system for incident management]]) - **SRE Book の ICS に基づくインシデント管理は、マルチエージェント SRE の役割設計の直接の前駆である**: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] は非管理型インシデントの最大の悪化要因を「善意に基づく独断行動（フリーランシング）」と特定し、ICS（インシデントコマンドシステム）に基づくインシデントコマンダー・オペレーション・コミュニケーション・プランニングの 4 役を処方する。この役割分離は [[Stratus]] の 4 エージェント構成（Commander/Investigator/Executor/Undo）や [[OpsAgent]] の MAS 設計と構造的に対応する。Ch13（[[@2016__OReilly__SRE Book - Chapter 13 Emergency Response]]）はテスト誘発型障害と訓練なし障害の対比で人間の判断力の価値を浮かび上がらせ、Ch15（[[@2016__OReilly__SRE Book - Chapter 15 Postmortem Culture - Learning from Failure]]）はブレームレスポストモーテム文化を「人でなくシステムの欠陥に焦点」という原則で定着させる。Ch33（[[@2016__OReilly__SRE Book - Chapter 33 Lessons Learned from Other Industries]]）は航空（CHIRP）・医療・製造業（CAPA）から非難なき振り返りが業界横断で有効であることを確認し、Ch16（[[@2016__OReilly__SRE Book - Chapter 16 Tracking Outages]]）の Outalator はパッシブ集約とタグベースメタデータでアウテージ追跡を自動化する。LLM エージェントが自動生成する RCA レポートの「非難なき説明」要件は、このブレームレス文化の自動化版として読める。(Source: [[@2016__OReilly__SRE Book - Chapter 13 Emergency Response]], [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]], [[@2016__OReilly__SRE Book - Chapter 15 Postmortem Culture - Learning from Failure]], [[@2016__OReilly__SRE Book - Chapter 16 Tracking Outages]], [[@2016__OReilly__SRE Book - Chapter 33 Lessons Learned from Other Industries]]) - **SRE Workbook は ICS 原則を事例・訓練・テンプレートへ落とす**: Incident Response は、インシデントの解決（影響緩和・復旧）とインシデントの管理（対応者調整・情報流通）を分け、IC/CL/OL の役割を Google Home、GKE、Persistent Disk、PagerDuty の事例で検証する。Postmortem Culture は、悪いポストモーテムと良いポストモーテムを比較し、広い共有・アクションアイテム追跡・文化的インセンティブを強調する。Appendix C はポストモーテム分析から、変更起因障害やプロセス失敗を集計して、個別事故を組織学習へ変える入口を示す (Source: [[@2018__Google SRE Workbook__Incident Response]], [[@2018__Google SRE Workbook__Chapter 10 Postmortem Culture - Learning from Failure]], [[@2018__Google SRE Workbook__Appendix C Results of Postmortem Analysis]])。 - **オペレータエラーの支配性は 20 年超にわたって構造的に持続しており、現代の AIOps エージェント評価の障害モデルにも影を落とす**: Gray (1986) が Tandem システムでオペレータエラーを最大の障害原因（42%）として同定し、[[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] が 17 年後のインターネットサービスで同じ傾向（Online 33%、Content 36%）を再確認した。設定エラーがオペレータエラーの 50% 以上を占める点も両時代で共通する。一方、2026 年の ICSE 研究は GenAI クラウドサービスの本番インシデントで設定問題 24.5%・運用操作ミス 12.7% を報告しており、「人間起因の障害が全体の 3〜4 割を占める」というパターンは技術世代とアーキテクチャを超えて持続している。この構造的持続性は、障害注入ベースの AIOps ベンチマークが人間起因障害を再現しにくいという前述の乖離問題の根底にある。(Source: [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]], [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]) - **workflow artefacts(runbook・チケット・postmortem)は「知識ベース」かつ「攻撃面」という二面性を持つ**: 本 wiki の ARFBench スレッドは Slack タイムラインや OCE の事後報告を AI 評価の一次データに昇格させる流れを肯定的に記録した。[[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]] は同じ artefacts を「知識ベースであると同時に攻撃面」として両義的に扱い、untrusted な成果物(自由形式チャット・外部文書・ユーザー影響下のログ文字列)は独立チェックなしに特権行動を駆動してはならない、と規律づける(§II-D、§VI-E)。さらに runbook は古び・postmortem は機微情報を省き・チケットは曖昧/敵対的なテキストを含みうる系統的バイアス源だとし、authoritative / advisory / untrusted の信頼階層(表I)で扱うことを求める。インシデント記録を AI の燃料にする流れと、それを攻撃面として警戒する流れは、信頼階層と独立検証の規律で初めて両立する([[エージェント運用安全性]] に詳述)。(Source: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]], [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]]) - **クラウド三社の 354 件ポストモーテム分析が MTTM=304 分・TTM 支配という構造を実測で示した**: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]](Li+ 2022)の TTX 実測値(MTTD=16.9 分・MTTI=77.8 分・MTTM=304.2 分・MTTR=572.8 分)は、インシデント管理の時間コスト分布を AWS・Azure・Google Cloud 横断で初めて定量化した。TTR の 53% を緩和フェーズが占めるという事実は、[[インシデントTTM予測]] が TTM 短縮を重要視する根拠を empirical に裏付け、[[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]] の「T3(緩和フェーズ)が TTM の 70% を占める」という Microsoft 単社データと大局的に整合する。障害発生から緩和まで平均 9 時間以上という事実は、自動緩和ツール([[障害緩和]])の研究動機の定量的根拠となる。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) - **検知段の失敗（ミス検知）は緩和コストの増大を通じてインシデント管理全体のコストを律速する**: [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]] は Microsoft 300 超サービス・2022 年間の約 950 インシデントを分析し、ミス検知されたインシデントの 27.25% がアウテージに発展し、顧客報告インシデントはモニタ報告比で TTD が 10.7 倍・TTM が 3.75 倍長くなることを示した。この結果は「検知（Detection）」段の失敗が緩和段で指数的にコストを増大させることを定量的に裏づけ、「Detection Is Better Than Cure（検知は治療より優れる）」という命題を経験的に確認する。インシデント管理ライフサイクルを「検知→トリアージ→診断→緩和」の 4 段として見るとき、本論文は第 1 段の改善が最もコスト効率が高いことを示す最初の大規模実証研究の一つ。(Source: [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]]) - **ミス検知の 6 カテゴリタクソノミは「モニタ設計の問題」と「モニタ運用の問題」を分離する**: Ganatra et al. 2023 は 579 修正項目から 6 カテゴリを導出した。「Missing monitor/alert（40.41%）」と「Missing/improper signal（18.13%）」は設計上の問題（何を監視すべきか）、「Incorrect alerting logic（12.78%）」と「Improper monitor coverage（10.02%）」と「Buggy monitor（5.87%）」は既存モニタの運用上の問題（どう監視しているか）、「Others（6.39%）」は文書化の問題に分類できる。本 wiki の [[変更起因インシデント]] が「不足したモニタリング指標（筆頭課題）」と「不正確な変更モニタリング」を挙げるのと整合的で、モニタ不在と誤設定は独立した介入軸を持つ。(Source: [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]], [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]]) - **変更起因インシデントのライフサイクル分析が「緩和プロセス設計」という新しい介入軸を示した**: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]] は大規模オンラインサービス(ビリオンユーザー規模)の 2 年間・231 件のインシデントを「導入 → 検知 → 緩和」の 3 段で分析し、RaIC(即時原因除去後に回復、64.5%)と RbIC(即時原因除去前に回復、35.5%)という緩和プロセスの分岐を初めて定式化した。RbIC を選択できる場合、緩和時間(TTM)を 40.6% 短縮できる(65.3 対 38.8 時間単位)。これは本 wiki のインシデント管理が「検知 → 診断 → 緩和」を段として縦に切ってきたのに対し、**「いつ・どのプロセスで緩和するか」というプロセス選択自体が TTM を律速する**という横断的な知見を加える。緩和失敗は 18.6% のインシデントで発生し、TTM を 87% 延長する(88.2 対 47.2)。(Source: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]]) - **モニタリングが変更起因インシデントの半数を検知できない構造的失敗パターンが 3 類型で整理された**: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]] によると、変更起因インシデントの 50.6% で利用者がモニターより先に検知する——モニター TTD は利用者の 7.67 倍速い(65.6 対 564.0)にも関わらず。失敗原因は「モニター未設定(46.2%)」「監視不能なインシデント(35.0%)」「異常未認識(18.8%)」の 3 類型。本 wiki の [[異常検知]] が整理する「偽陽性バイアス([[TelecomTS]])」「文脈なし検知の限界([[LogPilot]])」という 2 問題に、**変更後の新たな異常パターンへのカバレッジ不足**という実務上の第 3 問題が加わる。[[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]] も Ant Group での 4 課題の筆頭として「不足したモニタリング指標」を挙げており、異なる企業・データセットで同型の失敗が再現する。(Source: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]], [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]]) - **インシデントライフサイクルの T3(最終担当チーム確定後の緩和フェーズ)が TTM の 70% を占めるという発見は、「トリアージ改善だけでは TTM 短縮に限界がある」という重要な示唆を持つ**: [[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]] は Microsoft 20 システムの 4 年分データで T3 が平均 70.20% を占めることを初めて定量化した。これは [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]] が指摘する「RbIC(即時原因除去前に回復)で TTM を 40.6% 短縮できる」という知見と組み合わせると、T3 フェーズの**緩和プロセス選択**が最大の TTM 改善機会であることを示す。両論文は別独立データ(Microsoft 4 年 vs. ビリオンユーザービジネス 2 年)で同型の問題構造(T3 支配)を指している点が重要。(Source: [[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]], [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]]) - **インシデント報告ソース(モニタ/エンジニア/顧客)が TTM に構造的に影響する**: [[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]] は顧客報告インシデントが最長 TTM を持つ理由を「症状のみ記述で担当チーム特定が困難」に帰属させた。これは [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]] が「顧客報告インシデントは TTD が 10.7 倍・TTM が 3.75 倍長い」と報告したのと一致する——発見した年代(2021 vs. 2023)や企業内部の研究方法が異なるにもかかわらず、顧客報告インシデントの非効率性という同型の知見が Microsoft 内の複数の独立研究で再現される。(Source: [[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]] §II-B, [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]]) - **変更起因インシデントは通常インシデントより重篤度・解決困難度が構造的に高く、4 つの固有課題がある**: [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]] は Ant Group(3000 以上のマイクロサービス、日に数万件の変更)の 161 件を分析し、変更起因インシデントは High/Critical 重篤度が通常インシデントの 2.6 倍(13% 対 5%)、TTD の 75 パーセンタイルが 26.8 倍長いことを示した。4 つの固有課題——①不足したモニタリング指標・②不正確な変更モニタリング・③低ビジネストラフィック・④非効率な異常変更箇所特定——は、変更の「影響伝播 × モニタリング設計のミスマッチ」が根本にある。[[変更起因インシデント]] に詳細を切り出す。(Source: [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]]) - **カナリアリリースは変更起因インシデントの早期顕在化に有効だが、性能問題起因のインシデントは遅延顕在化で捉えられない**: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]] は、カナリアリリースでは 76.8% がデプロイ中に発生(早期検知に有利)する一方、性能問題起因のインシデントの 54.5% がデプロイ後しばらく経過してから顕在化することを示す。これは自動化されたリリースパイプラインの「リリース直後のモニタリング終了」設計の盲点であり、[[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] が同定した「変更(メンテナンス)起因障害が全体の 25% 以上を占める」という長期的課題と接続する。変更後の監視期間設計(特に性能系メトリクス)は標準的なカナリア解析では不十分。(Source: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]], [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]) - **[[Bian Que]] の統一運用パラダイムはインシデント管理の射程を「アラート発火後」から「アラート発火前」へ拡張した**: 既存のインシデント管理研究([[AlertGuardian]]・[[LogPilot]]・[[FLASH]]・[[LLexus]] 等)はアラート発火を所与のエントリポイントとし、その後の診断・緩和・ライフサイクル管理を対象にしてきた。[[Bian Que]] は統一運用パラダイムを 3 カノニカルパターン——リリース遮断(リリース起因インシデントの未然防止)・積極的点検(潜在的システムリスクの定期発見)・アラート根本原因分析(アラート後診断)——として定式化し、3 つ目のみがアラート後対応で前 2 者はアラート発火前の介入である。これにより[[PAGER]]([[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]])が提案した積極的監視と、従来のリアクティブな IM を 1 つの統一フレームワークに収める。KuaiShou 本番で 75% のアラート量削減は主にリリース遮断と積極的点検が閾値到達前に問題を解決した結果であり、「インシデントが鳴らないことが最良のインシデント管理」という設計思想を数値で裏付ける。(Source: [[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]] §1, §2.1, §3.2, Table 2) - **alert と incident を別ライフサイクルとして分離する設計(Yu+ JNCA2024)と Microsoft の合一設計の対比軸**: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]] は ITIL/ITSM 由来の概念(event ⊃ alert、severe alert + user complaint → incident)に基づき alert management と incident management を別ライフサイクルとして扱い、本サーベイ自身が「Microsoft は全アラートを incident として扱う」と Table 4 で明示する(Chen+ 2020a/c の incident 分析は実質的にアラート分析である)。本 wiki がインシデント管理を「検知→トリアージ→診断→緩和」の段で縦に切ってきたのに対し、Yu+ 2024 は「上流(alert)で減らせる工数は下流(incident)に送らない」という対比軸を提供する。同じ Dan Pei 系統の [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]] が AlertGuardian で「denoise→summary→rule refinement」を一気通貫の alert ライフサイクルとして実装した方向と整合し、[[アラート管理]] に上流側の集約を切り出す。(Source: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **incident management 8 プロセスの統一アーキテクチャ(Yu+ JNCA2024 Fig.5)が LLM 時代の研究地図にどこまで耐えるか**: Yu+ 2024 は 2008-2022 の 89 件を representation・linking・triage・mitigation・resolution の 5 プロセス(+ alert 側 3 プロセス)で分類した。本 wiki の LLM 時代の主要論文を当てはめると、[[FLASH]]・[[StepFly]]・[[LLexus]] は mitigation/resolution の TSG 実行、[[FlowXpert]] は mitigation の TSG 生成(Yu+ 2024 には対応セル無し)、[[OpsAgent]] は triage + RCA + mitigation の融合、[[AlertGuardian]] は representation/linking を跨ぐ rule refinement と、分類セル単位で切れない多段融合が主流になっている。「LLM エージェントは Yu+ 2024 の 8 プロセスを横断結合する」というメタ動向は、本サーベイの分類が前 LLM 時代を最後に区切る境界研究であることを示す。(Source: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]], [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]], [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]]) - **「半数以上のインシデントが対処不要」という構造的事実は、severity 割当と OCE 工数配分の根本的見直しを迫る**: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] は Microsoft 18 サービスの 6 か月分インシデントで incidental incidents が平均 50.32%(11.92%〜71.43%)・TTR の 55.05% を消費することを定量化した。さらに「潜在影響顧客数」に基づく現行の severity 0〜4 割当では、最高 severity 0 ですら incidental が 57.96% を占め essential(42.04%)を上回るという逆転を Table 1 で実証している。これは Detection Is Better Than Cure([[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]])の「ミス検知が緩和コストを増大させる」という主張と相補的で、前者は「検知側の精度」、後者(DeepIP)は「報告された後の優先順位付け」の両端から OCE 工数浪費を攻める。AlertGuardian の rule refinement(上流のルール品質)も含めると、Microsoft 系研究は「同じ問題=低重要度アラート/インシデントへの工数浪費」を上流・中流・下流の 3 か所で並行的に攻めている構図が見える。(Source: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]], [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **インシデント管理の自動化効果は「診断精度」だけでなく調査範囲縮小として測れる**: [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems|GRLIA]] は、根本原因を直接当てるのではなく、同一障害のインシデントクラスタを作って OSE の調査範囲を狭める。本番展開後の Huawei Cloud Networking サービスでは、2020 年 11 月の 26 障害で平均障害対応時間が 8 月比 24.8%、9 月比 21.9%、10 月比 18.6% 短縮した。これは [[インシデントTTM予測]] や [[インシデント優先順位付け]] が「時間を予測/優先度を決める」のに対し、GRLIA は「見るべき候補集合を縮める」ことで TTM に効く別の介入点である。(Source: [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems]], [[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]], [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]]) - **incident 固有の時間相関(関連 incident の attention 統合)が bug severity prediction 流用との性能差を生む**: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] は bug severity prediction の代表手法 Rule(Menzies and Marcus 2008)と Bayes(Lamkanfi et al. 2010)を流用して 18 全システムで比較し、AUC が Rule 0.624 / Bayes 0.586 にとどまることを示した。DeepIP が AUC 0.808 を出せた最大の差分は、target incident だけでなく直前 10 件の relevant incidents を attention で統合した点(time window 0 vs 10 の Wilcoxon 検定 $p < 0.05$ で有意改善)。bug は個別報告・低相関、incident は monitor 自動報告・高相関という構造の違いが、手法設計に固有要件をもたらすことを実証している。これは [[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]] が TTMPred で「漸進的議論の蓄積」を取り込んだのと同じ思想——incident は孤立した報告でなく時系列で文脈を持つ——の早期実装。(Source: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]], [[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]]) - **DSL クエリ推薦という調査フェーズ支援が、LLM 活用の新しい介入点として実証された**: [[FLASH]]/[[LLexus]]/[[StepFly]] が「既存 TSG の実行自動化」を対象にするのに対し、[[@2024__ICSE__Xpert - Empowering Incident Management with Query Recommendations via Large Language Models|Xpert]]([[@2024__ICSE__Xpert - Empowering Incident Management with Query Recommendations via Large Language Models]])は OCE が手動記述する KQL クエリの**自動推薦**という調査フェーズの別介入点を設計した。Microsoft 大規模クラウドでの実証研究から (1) インシデントの 50% 以上が KQL 1 件で管理され(少数集中)、(2) クエリはサービス間で非移転性(テーブルとテンプレートをサービスをまたいでほとんど共有しない)、(3) 月次でのテンプレート変化率が高い(時変性)——という 3 特性が明らかになった。この特性は「LLM の ICL でパラメータ更新なく適応できる」という設計判断を裏付け、オンライン Xpert はオフライン fine-tune 型 CodeT5+ を Identicality(完全一致率)で 17.69 vs 2.62 と大幅に上回った。インシデント管理の自動化研究が「検知→トリアージ→診断→緩和」の段を横断する LLM エージェントに向かう中、Xpert は診断フェーズの「テレメトリクエリ生成」という特定操作に絞った DSL 生成システムとして位置づけられる。(Source: [[@2024__ICSE__Xpert - Empowering Incident Management with Query Recommendations via Large Language Models]]) - **「user-centric incident management」という従来 paradigm を逆転する設計が AI ワークロード文脈で本格化**: 既存のインシデント管理研究はすべて provider-centric(ユーザがチケット報告→プロバイダが診断)を所与とし、AlertGuardian・LogPilot・FLASH・LLexus・OpsAgent も provider 側エージェントを設計対象としてきた。[[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] はこの paradigm を逆転し、ユーザ側で**チケット提出前に**自動診断する pre-ticket interception layer として [[TSGuard]] を位置づける。Azure 本番 1 年の median TTM=52.5 時間 / mean 83.0 時間という inefficiency を「報告品質のばらつき + 知識ギャップ + 一律トラブルシューティング負荷」が生むと分析し、ユーザの初動診断によって unsolvable 案件をプロバイダへ高品質チケット付きでエスカレートする。これは AlertGuardian が「上流のアラートルール品質」で介入したのと同じく「上流のチケット品質」を介入点に選ぶが、介入主体を**ユーザ側のエージェント**に移している点が新しい。(Source: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **AI ワークロードのインシデント分布は従来クラウドと根本的に異なる(GPU 偏重・recurrence 高)**: 本 wiki の ICSE 研究は GenAI 提供サービス(Azure OpenAI 等)の事業者側インシデントを Microsoft 4 年データで分析したが、TSGuard はその下層の **AI ワークロード基盤(GPU クラスタ訓練・推論)の運用インシデント**を 1 年・778 件で分析した。Figure 2 では GPU 52.47%・System Software 27.79%・Networking 8.18%・User 8.83% で、従来クラウドワークロード([19] Ghosh+ SoCC 2022)の code/dependency ~40% + dependency 16.4% + infrastructure 15.6% という分布と質的に異なる。recurrence rate(同種障害の繰り返し度)は GPU 8.78・Networking 3.15・System Software 2.34 と一桁高く、code error 中心の従来クラウドの「パッチで止まる」recurrence パターンとは別系統。これはインシデント管理のベンチマーク設計([[RCA評価設計]])が AI ワークロード固有データセットを取り込むべき定量的根拠となる。(Source: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]], [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]) - **症状-原因の多対多マッピング問題が AI ワークロードで特に深刻、能動検証(hypothesis-iteration + verification)が one-shot RCA を上回る**: ICSE 研究(GenAI クラウド)の Figure 7 で症状-原因の多対多マッピングが報告されていたが、TSGuard は AI ワークロードでこれが特に深刻と論じる(§2.1)。CUDA "invalid device ordinal" + NVIDIA Xid 119 という同一症状の真の原因が「GPU 故障」でなく「CUDA ドライババージョン不一致」だった事例(本論文 §2.1 末尾)。RCACopilot や DID-o1 のような one-shot RCA は症状と原因のセマンティック近傍検索に依存するため、この多対多関係で誤解する。TSGuard の Pipeline #2 がタクソノミー誘導 DFS で hypothesis → 検証スクリプト実行 → 結果反省 → 再仮説 のサイクルを回すことで、Macro F1=0.816(RCACopilot: 0.380、+43.6%)を達成。OpsAgent の MAS 設計と同じく「能動検証 + 反復」が one-shot を超える、という構図が GenAI 上層と AI ワークロード下層で並行して確認された。(Source: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]], [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]], [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]) - **半自動タクソノミー構築という TSG 自動化問題のもう一つの側面**: FLASH/StepFly/LLexus が「既存 TSG を実行する」サブ問題を扱い、FlowXpert が「TSG を生成する」上流問題を扱ったのに対し、TSGuard はインシデント記録から**階層タクソノミー(根本原因ラベル体系)自体を半自動構築する**(Algorithm 1: LLM 判定で既存ノードへ紐付け / 新規ノード作成 / 曖昧→スキップ + 専門家のスクリプト割当)。Microsoft Azure 1 年分の本番データから 6 main / 28 sub / 97 detailed の 3 階層を 570 GPT-4o invocations + 448.4 秒 + $9.89 で構築。これは AutoARTS [14](Dogga+ ATC 2023)の人手構築 multi-person-year に対する自動化路線で、TSG 生成(FlowXpert)・タクソノミー生成(TSGuard)・ルール生成(AlertGuardian)が共通して「人間向け運用知識を AI 向けに半自動構築する」上流側で発展している構造が見える。(Source: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]], [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **Remil+ 2024 が提案した 4 フェーズ × 9 タスク手続きは、本ページの「検知 → トリアージ → 診断 → 緩和」4 段に *triage の内部分解* を加える形で再整理する**: 本ページは長らくインシデント管理ライフサイクルを 4 段で縦に切ってきた([[AIOps]] の 4-level taxonomy と連動)が、[[@2024__arXiv__AIOps Solutions for Incident Management]] §3.3 はトリアージを {Prioritization, Assignment, Classification, Deduplication} の 4 タスクに、診断を {RCA, Correlation} の 2 タスクに、検知を {Detection, Prediction} の 2 タスクに細分化する(緩和は単一タスク)。本 wiki が LLM 期の MAS 設計を見るのに使ってきた粒度では「triage」と「RCA」が大きな箱になっていたが、Remil+ 2024 の細分粒度を入れると、(1) [[OpsAgent]] の 4 エージェント設計を {Prioritizer, Classifier, Deduplicator, Router} の分業として読み直せる、(2) [[AlertGuardian]] の rule refinement は Classification と Deduplication を横断する上流介入、(3) [[FLASH]]/[[StepFly]]/[[LLexus]] の TSG 自動化は Mitigation + Correlation(過去類似の参照)に該当する、と細かい位置づけが可能。Notaro+ 2021 はトリアージを assignment 中心に扱っていたので、Remil+ 2024 の細分(classification と deduplication の独立)は LLM 期の MAS 設計を分析するための新しい解像度を提供する。(Source: [[@2024__arXiv__AIOps Solutions for Incident Management]] §3.3, [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **Maintenance Strata の 4 層モデル(Technical/Application/Functional/Business)は本 wiki のインシデント分布議論に縦軸を補う**: 本ページは ICSE 2026・TSGuard・LogPilot 等を介して「どのコンポーネントの障害が多いか(GPU/Networking/Code/Configuration 等)」を議論してきたが、[[@2024__arXiv__AIOps Solutions for Incident Management]] §2.3 の 4 層モデル(Technical 物理層 → Application アプリ層 → Functional 機能層 → Business 事業層)は、これを業務インパクトの縦軸として再編する。同じ「Networking 障害」でも Technical 層では NIC 故障、Application 層では RPC タイムアウト、Functional 層では応答時間 SLO 違反、Business 層では取引失敗率増として顕在化し、検知・トリアージ・診断・緩和の各段で扱うべきレイヤが分かれる。本 wiki が LLM-era の各論文の障害分布をどの層で扱っているかを 4 層モデルで再ラベリングすると、[[TSGuard]] が Technical 中心、[[AlertGuardian]] が Functional/Business 中心、[[Bian Que]] が Application/Functional 横断、と整理できる。(Source: [[@2024__arXiv__AIOps Solutions for Incident Management]] §2.3, [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **Sillito & Kutomi 2020 の 30 インシデント定性研究が確立したインシデント対応の基礎構造は、LLM 時代の自動化研究が前提とする実態と乖離している**: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]] は 2020 年時点のソフトウェアインシデント対応の実態を 4 フェーズ（発生・検知・調査・緩和）で体系化した。特に (1) 手動検知が常に遅延検知であること、(2) 汎用的モニタリングが遅行指標になること、(3) 調査が日和見的と体系的の組み合わせであること、(4) 緩和が根本原因修正だけでは完了しない（連鎖した障害状態が残る）こと、の 4 点が LLM 時代の研究が前提とする「自動検知→トリアージ→RCA→緩和」の線形パイプラインモデルと比べてより複雑な実態を示す。本 wiki の AlertGuardian（ライフサイクル最適化）・TSGuard（ユーザ側診断）・Bian Que（積極的点検）が扱う課題は、それぞれ Sillito & Kutomi の観察 6（しきい値検知の脆弱性）・観察 7（支援ツール自体の監視不足）・観察 5（遅行指標問題）への応答として位置づけられる。(Source: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]] §IV) - **「モニタリング・通知支援ツール自体が最も監視されていない」という観察 7 は、現代の AIOps エージェント評価の設計的盲点を指摘する**: AIOpsLab・SREGym・OpenRCA 等のベンチマークはエージェントの診断精度を評価するが、診断の基盤となるモニタリングシステム自体の欠陥（通知遅延・バックアップ失敗の未検知等）を評価対象にしない。Sillito & Kutomi 2020 の観察 7 は 20 件以上のインシデントで支援ツールの欠陥がインシデント対応の全側面に影響したことを記録しており（例: incident 2.1 で通知 4 時間遅延、incident 2.6 でバックアップ失敗を把握できず）、「ツールが正常に動作する」という前提自体が本番環境では成立しないことを示す。(Source: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]] §IV-B 観察 7) - **Google の 8 フェーズインシデントタイムラインは「Incident Duration = Detect から Resolve」と定義し、修正機会を Stop / Faster / Prevent and Fix Culture の 3 方向に分類する**: [[Sue Lueder]]（[[Google]] SRE Program Manager）は SREcon 2015 で、Root Cause → Hits Production → Detect（BEEP!）→ Escalate（page oncall）→ Mitigate（Drain/Failover/Push/Rollback）→ Resolve（if A==B）→ Retrospect（Postmortem）→ Action Items の 8 フェーズからなるタイムラインを定義した。Incident Duration を Detect から Resolve の区間に限定することで、アラート発火前の潜伏フェーズ（Root Cause → Hits Production）と事後フェーズ（Retrospect・Action Items）を別途管理する。修正機会は「根本原因が本番に到達する前に STOP する」「Detect → Mitigate を FASTER にする」「Resolve 後に Prevent and Fix Culture を醸成する」の 3 方向として整理される。本 wiki が整理してきた T3 フェーズ支配（TTM の 70%）・RbIC による TTM 40.6% 短縮・Detection Is Better Than Cure という 3 知見は、それぞれ「FASTER の Mitigate 段」「FASTER の Resolve 前緩和」「FASTER の Detect 段」に写像できる。(Source: [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]], p.12, p.26) - **技術的オブザーバビリティと人間のオブザーバビリティは並存する別次元の観測問題**: AIOps/LLM 系の研究群（AlertGuardian・OpsAgent・FLASH 等）はメトリクス・ログ・トレースを対象とする技術的オブザーバビリティを扱う。一方 [[Matt Davis]]（[[@2023__SREcon23Americas__Human Observability of Incident Response]]）は「インシデント対応中に参加者が互いの状態・意図・注意をどう把握し合うか」という**人間のオブザーバビリティ**を独立した観測問題として提起した。Silliko & Kutomi 2020 が示した「手動検知の遅延・日和見的調査」は技術的オブザーバビリティの不足として説明されるが、同時に「コンダクターが他の参加者の疲労・注意分散・競合優先事項を把握できていない」という人間のオブザーバビリティ不足の問題でもある。両次元を独立に最適化する必要がある。(Source: [[@2023__SREcon23Americas__Human Observability of Incident Response]], [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]]) - **2021〜2024 年の AI 支援インシデント管理研究は Detect・Contain に集中し Prepare・Post-incident は著しく過少研究である**: [[Dahlia Ziqi Zhou]] と [[Marios Fokaefs]]（[[York University]]）が実施した SLR([[@2024__arXiv__AI Assistants for Incident Lifecycle in a Microservice Environment - A Systematic Literature Review]])は、309 件から選定した 31 件の一次研究を NIST 4 フェーズで分類した結果、Detect 54.8%・Contain 35.4%・Prepare 9.7%・Post-incident 3.2% という偏りを定量化した。Prepare フェーズは「tooling セットアップ・ハンドブック整備・プロセス定義」など構造化が難しい作業を含むため研究が少なく、Post-incident フェーズは「インシデント解決後に振り返りの必要を感じない」という組織文化(Atlassian 調査)が一因とされる。また 31 論文中ユーザースタディを実施したのは 5 件のみ(Oasis・Groot・LLMAD・Zhang+[24]=[[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture|mABC]]・Zhang+[25])であり、本番環境での実証評価が不足している。非伝統的データソース(過去インシデントレポート・サービス依存グラフ・開発者アクティビティ・コードリポジトリ)は従来のログ/トレース/メトリクス三本柱を補完する将来機会として特定された。この定量的スナップショットは、本 wiki の多くの横断的知見が Detect・Contain フェーズの研究に偏って形成されている可能性を示唆する。(Source: [[@2024__arXiv__AI Assistants for Incident Lifecycle in a Microservice Environment - A Systematic Literature Review]] RQ1・RQ4) - **Response Trio（コンダクター・コミュニケーター・問題解決者）は SRE Book の Incident Command System と相補する**: [[Matt Davis]] の Response Trio（[[Laura Maguire]] の Adaptive Choreography に基づく）は、Google SRE Book（[[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]]）の Incident Command System（IC・Ops Lead・Communications Lead 等）と役割構成が対応する。SRE Book が役割定義と権限の形式化を重視するのに対し、Davis は **Joint Activity** としての即興的適応（コンダクタリング質問・Support Humans）を重視する点で補完的。AIOps エージェントが IC・Ops Lead の役割を代替しようとする設計（LLexus・OpsAgent 等）にとって、「人間が担う Support Humans 機能（Listen・Update・Guide・Monitor・Repair）はエージェントに移譲できるか」という問いが生まれる。(Source: [[@2023__SREcon23Americas__Human Observability of Incident Response]], [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]]) - **IC は「最強エンジニアのバッジ」ではなく「条件を整えるリーダーシップスキル」であり、SRE Book の ICS 定義と10年の実践知が一致する**: [[Vanessa Huerta Granda]]（[[@2026__SREcon26 Americas__So You Want a New Incident Commander]]）は10年超・複数 SRE 組織での IC プログラム構築から、IC の仕事を People（重複作業回避・コミュニケーション・意思決定フロー）/ System（状況認識の共有）/ Business（組織にとって重要なことの把握）の3軸に整理した。これは [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] の「IC は調整・統制役割であり、善意に基づくフリーランシングを抑制する」という教科書的定義と収束する。IC が技術問題を自ら解くのでなく「解ける環境を整える」という役割定義は、両ソースで10年以上の時差を超えて一致する。(Source: [[@2026__SREcon26 Americas__So You Want a New Incident Commander]], [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]]) - **IC プログラムの3チーム類型は「一貫性」と「文脈」と「普及」のトレードオフ軸で分かれる**: Huerta Granda は Deliberate IC Team（意図的専任・推奨、デメリット:過負荷）/ IC per domain team（良い出発点、デメリット:一貫性）/ IC volunteer team（スキル普及、デメリット:ストレス）の3類型を定義した。どの構造を選んでも「IC の役割が優先事項・仕事の一部であることを全 IC に明示する」ことが普遍的要件となる（スライド p.17 の強調スライド）。[[クロスインシデント分析]] で Enova が採用する「4名専任チームへの集中化」は Deliberate IC Team の発展形として整合する。(Source: [[@2026__SREcon26 Americas__So You Want a New Incident Commander]], [[@2025__SREcon25 Americas__Learning from Incidents at Scale - Actually Doing Cross-Incident Analysis]]) - **MTTR・インシデント件数はインシデント管理プロセスの健全さを測れず、目標ベースの指標群に置き換える必要がある**: 本 wiki の [[インシデント管理]] は AIOps 研究文脈で「MTTM=304 分・T3 支配」「Detection Is Better Than Cure」「TTM の 40.6% 短縮」など時間指標を多用してきた。一方 [[Jamie Luck]]・[[Laura de Vesine]]([[@2025__SREcon25Americas__Incident Management Metrics that Matter]])は、MTTR は統計的にノイズ優位(低頻度・高分散イベントで平均値の変化のほぼ全てがノイズ)かつ逆インセンティブ(最速低下策=同じインシデントの繰り返し)という二重の欠陥を持つと論じる。インシデント管理プロセスの成功は「顧客信頼性」と切り離し、オンコール健全性・プロセス品質・エンジニア能力・学習・エスカレーション等の 8 次元を直接測定すべきだとする。顧客信頼性は SLO で別途測る。この「MTTR は測らない」というパラダイム転換は、本ページが引用するパフォーマンスデータ(MTTM 短縮・TTM 予測精度)を「学術的リファレンス値」として保持しつつ、「KPI として組織に適用してはならない」という文脈を付与する。(Source: [[@2025__SREcon25Americas__Incident Management Metrics that Matter]], [[Štěpán Davidovič]]) - **SAE 自動運転レベルとの対応による IR 自動化レベル(IR0〜IR5)が実務的な自律度フレームワークを提供する**: [[Ryota Yoshikawa]]([[@2025__SRE NEXT 2025__Rethinking Incident Response - Context-Aware AI in Practice]])は SAE J3016™ の L0〜L5 に対応する [[インシデントレスポンスAIレベル]](IR0〜IR5)を提唱した。IR1 は通知・記録補助、IR2 は判断支援・提案、IR3 は実行・監視責任も AI が担う段階であり、「2025 年時点で IR0〜IR2 は実現済み、MCP + Coding Agent により IR2〜IR3 が現実的になった」と整理する。AIOpsLab の 4-level taxonomy(検知/局所化/RCA/緩和)が「何ができるか」の能力軸を縦に切るのに対し、IR Levels は「AI がどこまで自律的に動くか」の自律度軸を横に切る。IR3 到達には「AI に任せられる安全な操作の定義」が必要とされる。(Source: [[@2025__SRE NEXT 2025__Rethinking Incident Response - Context-Aware AI in Practice]]) - **インシデント対応成熟度モデルは「検知だけ整備して対応フロー未定義」という失敗パターンを段階構造で説明する**: [[Narimichi Takamura]]（[[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]]）の [[インシデント対応成熟度モデル]] は、Pre-Incident フェーズの Detection（検知）・Workflow（対応フロー）・Training（トレーニング）を分離して評価する。Absent→Reactive 移行のキーポイントとして「検知の仕組みだけを整備しても、対応フローが未定義では失敗に終わることが多い」と明記している。これは [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]] の「ミス検知がアウテージに発展する（27.25%）」という知見とは別の失敗モード——「検知はできているが対応が属人化していて組織的に動けない」——を言語化しており、検知精度の向上だけでは解決しない組織的成熟の問題を構造化する。またReactive→Proactive 移行の注意点として「組織全体を巻き込む施策を一気に進めず段階的に進める」ことを挙げており、[[Incident Commander]] のような上級ベストプラクティス導入にも前提条件が必要だという実践知と整合する。(Source: [[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]], [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]]) - **MTTR は改善評価指標として統計的に機能せず、TTX メトリクスへの細分化が代替**: [[Narimichi Takamura]]（[[Topotal]]）は SRE Kaigi 2025 で、有名インターネット企業 3 社の実インシデントデータを使ったモンテカルロシミュレーション（10 万回）により、各インシデントの修復時間を 10% 短縮しても MTTR が 10% 以上改善されるのは 49%・50%・64% のケースのみと実証した。インシデント期間のばらつきが大きく、ブラックスワンイベント 1 件で平均が動くためである。代替として、改善対象フェーズを特定して細粒度の TTX（TTDetect・TTAcknowledge・TTEngage・TTInvestigate・TTIdentify・TTMitigated・TTFix・TTRecovery 等）を計測することで変動性を抑えられる。この知見は Štěpán Davidovič（Google Cloud）の O'Reilly レポート "Incident Metrics in SRE: Critically Evaluating MTTR and Friends" や Courtney Nash（SREcon23 Americas「Far from the Shallows」）のMTTR 批判とも整合する。[[TTXメトリクス]] に詳細を切り出す。(Source: [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]], [[@2023__SREcon23Americas__Far from the Shallows]]) - **「X-lifecycle データ補完」という新介入軸が示す「コンテキスト選択」問題**: FLASH・LLexus・StepFly が「TSG の品質が自動化の律速」という共通の壁を示したのと並行して、[[@2024__FSE__X-lifecycle Learning for Cloud Incident Management using LLMs]] は「どの SDLC 段階の情報を LLM に渡すか」というコンテキスト選択が RCA 精度の律速になることを示す。依存サービス障害には上流依存サービス説明が有効（InC DEP: BLEU 5〜38% 向上・NUBIA 54.67% 向上）、モニタ SLO 分類にはサービス説明が有効（accuracy 0.75→0.79）だが、リソースクラスにはコンポーネント説明が逆効果になりうる。「追加情報がタスクに意味的に対応しているときだけ有効」という知見は、TSG 品質問題と双対の問題——「何を渡すか」のコンテキスト選択問題——をインシデント管理自動化に加える。共通する根は「OCE が参照する多層の情報を LLM プロンプトに再現する」設計思想であり、インシデントメタデータ単独への依存（siloed view）からの脱却が主題。(Source: [[@2024__FSE__X-lifecycle Learning for Cloud Incident Management using LLMs]], [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]], [[@2024__OSR__LLexus - an AI agent system for incident management]]) - **pre-LLM 期の最初期産業 AIOps フレームワーク BRAIN が TTB という新指標を実証した**: [[@2020__ESEC-FSE__Towards Intelligent Incident Management - Why We Need It and How We Make It|Chen+ ESEC/FSE 2020]] は Microsoft 6 コアサービス 2 年超の実証研究から、インシデントライフサイクルを TTD/TTE/TTM/TTB/TTF の 5 指標で定量化した。特筆すべきは **TTB(Time to Broadcast: 担当者着手から全影響サービスへの周知完了まで)がほぼ全サービスで TTM と同等の時間を要する**という発見で、下流依存性の不完全性が根本原因とされる。IcM BRAIN フレームワーク(インシデント検知・自動トリアージ・インシデント相関の 3 機能)の本番展開により、BRAIN 関与インシデント(全体の 44.8%)では 5 指標すべてで統計的に有意な短縮が確認された(Mann-Whitney-Wilcoxon 検定、すべて p < 1e-10)。本論文は LLM 以前の AIOps フレームワーク設計の典型産業例であり、本 wiki の他論文が LLM エージェントで再設計しようとする「検知→トリアージ→相関→緩和」の段を、機械学習モデル(LSTM・Random Forest・GRU・CNN)で実装した先行設計として位置づけられる。(Source: [[@2020__ESEC-FSE__Towards Intelligent Incident Management - Why We Need It and How We Make It]]) - **SAS(2013)が実証した「問題主導への転換」という産業 AIOps 研究の基本教訓**: [[@2013__ASE__Software Analytics for Incident Management of Online Services - An Experience Report]](ASE 2013)は、最初に技術主導(分類ベース hand-on)で開始した研究を、Service X チームからの「ログを見ていないのか」「根本原因を見つけられるか」というフィードバックを受けて問題主導に転換した経験を報告する。この転換が CAR マイニング・FCA+DMI・GVSM 治癒行動推薦という SAS の 3 コア技術を生んだ。本 wiki の LLM 期 AIOps 研究(FLASH・OpsAgent・AlertGuardian 等)も同様に、既存技術の適用よりも「OCE が実際に時間を費やしているステップを明示的に特定すること」が技術選択を規律する——この教訓は 2011 年の経験から始まり 2020 年代の LLM-era まで継続している。(Source: [[@2013__ASE__Software Analytics for Incident Management of Online Services - An Experience Report]] §VI-A) - **HITL(Human-in-the-loop)設計は 2011 年の SAS 本番展開から 2020 年代の LLM エージェントまで一貫して必要条件として維持されている**: SAS は「完全自動診断は現実的でない」としてOCE が意思決定に関与する HITL 設計を選択した(2011 年展開)。14 年後の OpsAgent([[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]])・Bits AI SRE・[[インシデントレスポンスAIレベル|Yoshikawa 2025]] の IR Level フレームワークも、「AI が完全自律化する前に人間の承認を得る段階を維持する」という同型の設計方針を選択している。この継続性は「現実の本番インシデントでは自動化の誤判断コストが高く、HITL が基本設計原則として必要」という実践的制約の持続性を示す。(Source: [[@2013__ASE__Software Analytics for Incident Management of Online Services - An Experience Report]] §III-A-4, [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]], [[@2025__SRE NEXT 2025__Rethinking Incident Response - Context-Aware AI in Practice]]) - **SAS の段階的展開(v1.0→内部環境→1DC→世界展開)は信頼構築による産業 AIOps 技術移転の最初期テンプレートである**: SAS は最初にログ解析機能だけ持つ v1.0 を作り、Service X 内部環境で SAS がサービスに影響を与えないことを実証し、1 データセンターに本番展開してから世界展開へと段階的に信頼を積み上げた。この「小さな動作する実証→製品チームとの信頼形成→世界展開」という技術移転テンプレートは、後続の LLM 期 AIOps 論文が「本番展開実績」を主要な貢献として強調する(FLASH: 1 製品、LLexus: SaaS 製品全体、OpsAgent: Lenovo 53 日)構図の先駆となる。(Source: [[@2013__ASE__Software Analytics for Incident Management of Online Services - An Experience Report]] §VI-D) - **SAS が示す「異種データ統合の必要性」は、単一ログソース研究への限界指摘として今も有効**: SAS が「単一データソース(分類ベース・メトリクスのみ)では実際の問題を解決できない」という事実に気づいたのは 2011〜2012 年である。しかし 2020 年代に入っても多くの研究が単一データソース(ログのみ・メトリクスのみ)に限定した手法を提案し続けており、SAS の 2013 年の発見が研究コミュニティ全体に浸透するには時間がかかった。マルチモーダル障害診断([[マルチモーダル障害診断]])が 2020 年代の独立した研究トレンドとして立ち上がったのは、SAS 的な「統合の必要性」への独立した収束と読める。(Source: [[@2013__ASE__Software Analytics for Incident Management of Online Services - An Experience Report]] §III-B-A, §V) - **ChatOps は 2016 年時点で Netflix の本番インシデント管理に実装されており、「チャットを操作プレーン化する」アプローチが LLM エージェント設計の先駆と読める**: [[Al Tobey]]（[[Netflix]]）の Scorebot([[@2016__SREcon16__Incident Management and Chatops @ Netflix Feat Scorebot]]、SREcon16、2016-03-16)は、Slack を操作インターフェイスとして SRE が反復実行していたタスク(人員グラフ探索・ステータスページ更新・メトリクス参照)を Go 製ボットで自動化した実践報告である。bookmarking(インシデント開始の時刻固定)・presence(関係者への通知)・after-hours(時間外担当者特定)・secrets 管理という 4 機能は、2020 年代の FLASH/LLexus が扱う「TSG の決定論的実行」と、機能構造として対応する——チャットコマンド駆動から LLM 推論駆動への進化として連続して読める。また「itch: the bot is obnoxious(ボットが騒々しい)」というペインポイントは、AlertGuardian が本番で 30 万/日のアラートを 1.5 万/日に削減した課題——「通知ノイズが運用を圧迫する」——の初期形態として位置づけられる。SAS(2011〜2013)と Scorebot(2015〜2016)は LLM 以前の産業 AIOps 自動化の二本柱であり、「機械学習モデルによる診断(SAS)」と「チャットボットによる操作自動化(Scorebot)」という異なる介入軸を代表する。(Source: [[@2016__SREcon16__Incident Management and Chatops @ Netflix Feat Scorebot]], [[@2013__ASE__Software Analytics for Incident Management of Online Services - An Experience Report]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **Slack の Response/Review/Analysis という組織・人間主導の3部構成は、本 wiki の LLM 期研究が前提とする「検知→トリアージ→診断→緩和」ライフサイクルと並行しつつ異なる粒度で切られている**: [[Brent Chapman]]（[[@2021__SREcon21__Evolution of Incident Management at Slack]]）は Incident Management を Response(緊急対応)・Review(事後のブレームレス学習)・Analysis(複数インシデント横断の共通要因抽出)の3部で定義する。これは本 wiki の AIOps 研究群が採用する検知(Detection)→トリアージ(Triage)→診断(RCA)→緩和(Mitigation)の技術的ライフサイクル段とは軸が異なり、Response が検知〜緩和までを一括りにし、Review・Analysis がポストモーテム文化([[@2018__Google SRE Workbook__Chapter 10 Postmortem Culture - Learning from Failure]])側に相当する。同じ「インシデント管理」という語が、技術的ライフサイクル(いつ・何を自動化するか)と組織的ライフサイクル(誰が・どう学習するか)という異なる分割軸で語られている実例であり、LLM エージェントの自動化対象を検討する際は両軸のどちらを指しているかを区別する必要がある。(Source: [[@2021__SREcon21__Evolution of Incident Management at Slack]], [[@2018__Google SRE Workbook__Chapter 10 Postmortem Culture - Learning from Failure]]) - **「インシデントのサイクル(Circle of Incidents)」は Slack の Response/Review/Analysis 3部構成を「平常運転→インシデント→事後学習→システム変化→新たな平常運転」という円環として図示した具体版である**: [[Vanessa Huerta Granda]] と [[Emily Ruppe]]（[[@2023__SREcon23Americas__Incident Commanders]]、SREcon23 Americas）は、インシデントを「変化し続ける社会技術システムの中で繰り返される循環」として図式化した。これは Chapman の Response(検知〜対応)/Review(学習)/Analysis(横断分析)という組織的3部構成と軸を共有しつつ、「学習が次のシステム変化に還元され、新たな平常運転を経て再びインシデントが起こりうる」という循環構造を明示した点で補完的である。両ソースとも [[Incident Commander]] と [[インシデントアナリスト]] という異なる役割がこの円環の異なる局面（対応 vs 事後分析）を担当するという役割分離の根拠を提供する。(Source: [[@2023__SREcon23Americas__Incident Commanders]], [[@2021__SREcon21__Evolution of Incident Management at Slack]]) - **共通基盤(共通 Linux ディストリビューション)は、アーキテクチャ上「グローバルなもの」を意図的に排除した設計であっても、事実上のグローバルな障害波及経路になりうる**: [[@2023__SREcon23EMEA__The World Blew Up but We're All Okay - How We Managed a Massive-scale Incident at Datadog]] は、[[Datadog]] が「グローバルなネットワーク・設定・コントロールプレーンを持たない」という明示的な設計方針を掲げていたにもかかわらず、全フリート共通の Ubuntu ディストリビューションへの自動セキュリティ更新(systemd/networkd の経路フラッシュ)が誘因となり、AWS・GCP・Azure 複数リージョンでほぼ同時多発的な Kubernetes ノード障害を引き起こした事例を報告する。本 wiki が集約してきた「変更起因インシデント」([[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]])や「サイレントな自動更新」の議論は主にアプリケーション/サービスのデプロイに焦点を当ててきたが、本ソースは**OS レイヤーの自動パッチ適用という運用者が直接コントロールしない変更**が同型のグローバル障害波及経路になりうることを示し、「デプロイの段階的ロールアウト」だけでは防げない障害クラスがあることを示唆する。 - **500人超・14時間・70超チャンネルという規模のインシデント対応でも、IC ローテーション+ワークストリーム自己組織化という最小限の骨格で機能した**: [[@2026__SREcon26 Americas__So You Want a New Incident Commander]] が示す「IC は条件を整えるリーダーシップスキルであり最強エンジニアのバッジではない」という定義、[[@2023__SREcon23Americas__Incident Commanders]] の「インシデントのサイクル」円環構造は、いずれも比較的少人数規模の事例を念頭に置く。[[@2023__SREcon23EMEA__The World Blew Up but We're All Okay - How We Managed a Massive-scale Incident at Datadog]] は同じ骨格(IC・コミュニケーションリード・roving troubleshooter)が 500 人超・単一 Zoom 通話に14時間で493人が入退室という規模でも機能した実例を提供し、Laura de Vesine は「事前の綿密な計画やテーブルトップ演習よりも、信頼・非難なき文化・即興力が規模のスケーリングを支えた」と総括する。これは [[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]] のインシデント対応成熟度モデルが説く「検知だけでなく対応フローの組織的定着が必要」という知見の、超大規模側での実証例と読める。 - **急激なスケールアウトはクラウドプロバイダの API レート制限・非公開クォータという新種のボトルネックを生む**: TSGuard([[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]])は AI ワークロード基盤における GPU/ネットワーキング系の障害分布を報告したが、[[@2023__SREcon23EMEA__The World Blew Up but We're All Okay - How We Managed a Massive-scale Incident at Datadog]] は復旧局面での大量ノード同時作成が AWS `CreateNetworkInterfaces` API のレート制限・GCP の非公開インスタンスグループ上限・サブネット IP 枯渇・HashiCorp Vault 証明書発行のボトルネックを連鎖的に引き起こした事例を示す。両者に共通するのは「平常時には見えないクラウドプロバイダ側の制限が、インシデント対応中の急激なスケール変化でボトルネックとして顕在化する」という構造で、インシデント対応の自動化研究が扱う検知・診断・緩和のいずれとも異なる「復旧オペレーションのスケーラビリティ」という論点を加える。 - **Kingsman の「Incident Loop 認識論」は、インシデント対応の各フェーズを「知識の問い」として再定義し、証拠収集・探索・仮説・テストに認識論的ツールを与える**: [[Jack Kingsman]]（[[Atlassian]]）は SREcon26 Americas で、Google SRE Book の Incident Loop を 5 フェーズ（検知/宣言・生存/トリアージ・検査・診断・テスト/処置）に体系化し直し、各フェーズで「何を知る必要があるか」を問いとして立てた。特に新規性があるのは証拠 2×2 マトリクス（出所の直接性 × 変化状況）・3 種の探索パターン（Linear/Binary/Induced-Change）・仮説 3 条件（testable/relevant/specific）・テスト 6 基準（仮説への作用・相互排他性・交絡因子排除・効果測定可能性・リスク管理・最小介入）の 4 ツールで、これらは本 wiki が AIOps 研究文脈から集約してきた「仮説駆動 RCA」「TSG 自動化」「検知精度」の実践的ハンドブック版として位置づけられる。"Incidents are all about knowledge"（インシデントはすべて知識の問題）という閉幕のフレーズは、本ページが集約するライフサイクル研究の目的関数を人間実践の言葉で言い換えている。([[インシデント認識論]] に詳述。Source: [[@2026__SREcon26Americas__Epistemology of Incident Management]]) - **「データ完全性 vs. 部分可視性」のトレードオフが、部分障害を全停止に増幅するスクエアウェーブパターンを生む**: [[@2025__Datadog Engineering Blog__Failure is inevitable - Learning from a large outage and building for reliability in depth at Datadog]] は [[Datadog]] の 2023 年 3 月障害分析から、「完全なデータセットが揃わないと結果を返さない」という設計方針が、50〜60% のノードが生存していても 100% 停止に見えるスクエアウェーブ障害パターンを引き起こしたと報告する。緩和策として[[グレースフルデグレーデーション]]（不完全な結果でも継続提供する設計原則）に転換し、重大インシデントを 30%・ログ製品の緩和時間を中央値 10%/95 パーセンタイル 50% 改善した。この知見は本 wiki のインシデント管理研究が「検知精度・診断速度・緩和自動化」を改善軸としてきたのに対し、**システムアーキテクチャの設計方針そのものが障害影響範囲を決定的に広げる**という別軸を加える。ISSRE 2022（TTX 実測で TTM が TTR の 53%）や Detection Is Better Than Cure（ミス検知が緩和コストを指数増大）と並べると、「緩和フェーズ」の高コストの一因が「グレースフルデグレーデーション不在による復旧困難」にある可能性が浮かぶ。(Source: [[@2025__Datadog Engineering Blog__Failure is inevitable - Learning from a large outage and building for reliability in depth at Datadog]], [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]], [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]]) - **インシデント管理の「入口の手前」には 30〜60% の学習機会が失われている**: [[Andreas Deuschl]]（[[@2025__SREcon25EMEA__The Un-Incident]]、Dynatrace）は、潜在インシデントの 30〜60% が正式トラッキングに乗らないまま通過するという実務推計を提示し、これを [[アンインシデント]] と命名した。4 類型(No-CI / NOF / Near Miss / Fear Miss)に分類し、「インシデントか否か」ではなく「何を学べるか」という問いの転換を Gray Zone Playbook として体系化する。この観察は本 wiki の検知→トリアージ→診断→緩和のライフサイクルモデルが「宣言された事象のみ」を対象とすることへの構造的批判であり、[[インシデントメトリクス]] の「宣言議論コスト」問題とも連動する。なお 30〜60% の数値の根拠は Deuschl 個人の実務経験であり、外部研究での検証は未着手。(Source: [[@2025__SREcon25EMEA__The Un-Incident]]) - **LLM ベースのインシデントトリアージ研究(COMET)は、ライフサイクル研究群が主に扱ってきた「検知後の診断・緩和の自動化」よりも手前の「担当チーム割り当て」という工程で、テキスト表現の選択(生ログ vs 議論 vs 要約 vs キーワード)自体を実証比較の対象にした点が特徴的**: [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]](COMET)は、[[DeepCT]]・[[DeepTriage]] が使う議論(discussions)テキストよりもフィルタ済みログ(TrimmedLogs)の方が、さらに LLM 生成要約よりもキーワードの方がトリアージ精度が高いことを、同一データセット上での直接比較(Table I・Table II)で示した。本 wiki が集約してきた FLASH の TSG 品質調査(Ambiguous Action 約40%)や AlertGuardian のルール改善受容率(7.5〜32%)が「既存の人間向けドキュメントをそのまま AI に渡しても機能しない」ことを示すのと同じ構造で、COMET は「人間向けの豊富なテキスト(議論・要約)よりも機械的に絞り込んだ疎な表現(キーワード)の方が下流タスクに有効」という逆説的な知見を、トリアージという別タスクで裏付けている。(Source: [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]], [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **ルールベース手法(AutoAnalysis)の出力は、精度が低くても後段 LLM 処理の補助信号として活用価値がある**: COMET のアブレーション(Table VI method 4→5)は、AutoAnalysis の出力(不正確でも)をタイトルとして追加するだけで ACC@1 が+5%改善したことを示す。これは AlertGuardian の rule refinement が「既存ルールを完全に置き換えず段階的に改善する」設計や、DeepIP が「AutoAnalysis 的な既存シグナルを補助情報として活用する」設計と同じ思想で、AIOps における「レガシールールベースシステムを廃棄せず LLM の補助入力として再利用する」という設計パターンが複数のライフサイクル段階で独立に再発見されていることを示唆する。(Source: [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]]) ## 未解決の問い - Prepare フェーズの AI アシスタント研究(SLR 時点で 3 件のみ)は、インフラ設定ミス自動検知(GenKubeSec)・IaC 宣言型コード分析(Lanciano+)を超えて、どのサブタスク(インシデント演習自動化・TSG 事前生成・リソース配置最適化)に広がるか。また Post-incident フェーズの AI 支援(FaultProfIT のみ)はポストモーテム下書き生成以外にどこを攻められるか。([[@2024__arXiv__AI Assistants for Incident Lifecycle in a Microservice Environment - A Systematic Literature Review]] RQ1) - OpsAgent の自己進化(PPO+反省)は、訓練データ分布と乖離した新種インシデント(未知の障害種別・未監視コンポーネント)でどれだけ汎化するか。53 日本番で「初出パターンが後から解決できるようになった」観測はあるが、汎化の上限と失敗条件は未解析。([[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]]) - OpsAgent の training-free プロセッサの閾値(3σ・95 パーセンタイル・TF-IDF 80 パーセンタイル)はシステムごとに調整が必要か。OPENRCA の 3 環境(Telecom/Bank/Market)では共通閾値で機能したが、異なるアーキテクチャ・監視密度を持つシステムへの移植時に人手チューニングが生じないか。([[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]]) - 反省ベース知識ベースは誤診断の反省でなく成功診断だけを蓄積する設計だが、稀で重要な障害パターン(複雑インシデント)は成功例が少なく知識ベースに過小収録される。定型インシデント 97% 対 複雑 54% の差は知識ベースの偏りを反映しているか。([[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]]) - 反復インシデントの TSG 品質を自動的に評価・改善する仕組みはどう設計すべきか。FLASH が提案する TSG 自動リファイニングツール(将来課題として記載)は、AlertGuardian の rule refinement エージェントと同型の問いを持つが、「診断ステップの文書」対「アラートルール」という対象の違いがある——前者は人間向け手順書、後者は機械実行可能ルールで、AI 向け再構成の難しさは質的に異なるか。([[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]) - ステータス監視(status supervision)による命令分解は TSG 以外の知識ベース(runbook・KB 記事・postmortem)に適用できるか。反復インシデントに限定せず、非反復インシデントの診断にも有効か。命令分解のステータス設計はドメインごとに人手で定義する必要があるか、それとも自動抽出できるか。([[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]) - GenAI クラウドサービスの監視未成熟（38.3% 人手検知・偽陽性 11.0%）は成熟とともに収束するか、それとも GenAI 固有の症状（無効推論・応答品質劣化）は本質的に自動検知が困難か。 - 症状と根本原因の多対多マッピング（図 7）は、LLM エージェントの hypothesis-driven RCA（[[Bits AI SRE]]・[[Stratus]]）でどこまで解けるか。人手 OCE の事後報告で得られた分類体系を、エージェントの推論空間にどう埋め込むか。 - 自己回復（19.7%）は「障害が自然に解消する」パターンだが、[[AIOpsLab]] や [[SREGym]] のベンチマークは自己回復シナリオを含んでいるか。含まないなら、エージェント評価は 2 割近い「介入不要」ケースの判別能力を測っていない。 - GenAI インシデントの TTM が 1.83 倍長い構造的原因は、監視の未成熟・症状の複雑さ・緩和の多様化のどれが支配的か。TTM 短縮は検知精度の改善・診断の自動化・緩和の自動化のどこに最も効くか。 - 本研究は Microsoft 単社のデータに基づく。他の GenAI プロバイダー（AWS Bedrock・Google Cloud・Anthropic Claude 等）のインシデント特性が質的にどう異なるか、産業横断的な比較研究は未着手。 - [[FLASH]]([[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]])の実世界 TSG 品質調査(52 件)は、Ambiguous Action(約 40%)・Unavailable Tools(約 20%)が主要な自動化阻害要因であり、「Pass」(そのまま自動化可能)は約 8.5% にすぎないことを示す。この知見は「TSG さえあれば自動化できる」という楽観的仮定への反証であり、AlertGuardian の rule refinement(1,174 提案→375 受容=32%)と並べると「既存の人間向けドキュメント/ルールをそのまま AI に渡しても機能しない」という共通の壁が浮かぶ——ドキュメント品質と AI 向け再構成は別問題として扱う必要がある。(Source: [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - [[ARFBench]] はインシデント対応の問い(時系列の異常推論)をシングルターンの多肢選択 QA に切り出すが、実際のインシデント管理は検知→トリアージ→診断→緩和のマルチターン・非線形プロセス([[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] の自己回復 19.7% も含む)。シングルターン TSQA の能力は、エージェントがライフサイクル全体を進める能力にどこまで転移するか。緩和戦略の推奨やインシデントパターンへの紐づけといった自由形式の問いを含む評価は未着手。([[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]]) - [[AlertGuardian]] の上流介入(rule refinement)では Temporal Analysis 系のルール提案の受容率が極端に低い(7.5〜14.0%)。なぜ時間的分析に基づくルール改善は人間に受容されにくいのか——時間窓・閾値の妥当性が運用文脈に強く依存し自動提案が外しやすいのか、それとも提案の説明可能性が不足するのか。上流のルール改善が効きにくいルール種別は何で、ライフサイクル全体最適化のうちどの段が人間の信頼を得にくいかは未解明。([[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - RbIC(即時原因除去前に回復する緩和プロセス)を自動化するには、「原因が除去されていなくても一時的に業務を回復できる手段(ロールバック・フォールバック・トラフィックスイッチ)が何か」を自動判断する能力が必要になる。現状の AIOps エージェント評価([[AIOpsLab]]・[[SREGym]])でこの「原因除去前の緩和」を実行・評価できるシナリオは用意されているか。([[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]]) - TTMPred は「漸進的な議論テキストが蓄積するほど TTM 予測精度が向上する」ことを示したが、LLM エージェントが自律的に緩和を試みる環境では議論の性質が変わる。エージェント生成の診断ログ・仮説テキストを TTM 予測の入力として使う場合、人間のオペレータ間会話で学習したモデルはどの程度転移するか。([[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]]) - 変更起因インシデントの 4 課題(不足したモニタリング指標・不正確な変更モニタリング・低ビジネストラフィック・非効率な異常変更箇所特定)は、異なる企業(アリババ・Ant Group)で並行して確認されている。この 4 課題の優先度は企業規模・変更頻度・マイクロサービス数によって変わるか。特に「低ビジネストラフィック」は変更直後の問題で、ダーク起動・合成テスト・シャドウトラフィックといった代替手段でどこまで補えるか。([[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]]) - DeepIP の 6 カテゴリ taxonomy(by design / customer error / won't fix / unable to reproduce / transient / false alarm)は Microsoft 18 サービスから帰納的に導かれた。GenAI クラウド([[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]])・他社オンラインサービス・マイクロサービス基盤でも同じ 6 カテゴリで網羅できるか、それとも GenAI 固有の「無効推論」「応答品質劣化」が第 7 カテゴリとして必要か。([[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]], [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]) - 「severity 0 でも incidental が 57.96%」という逆転は、現行の「潜在影響顧客数」ベース割当の根本的な誤設計か、それとも事前情報の不足(報告時点では影響範囲しか分からない)による不可避的な誤差か。DeepIP の incidental 確率と severity を組み合わせる運用フローはどう設計すべきか。([[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]]) - TSGuard の user-centric paradigm は AI ワークロード(GPU 訓練)で実装されたが、従来クラウドワークロード(Web サービス・データベース)に転用するとどうか。前者が hardware/driver 系の決定論的検証ツール(SuperBench/DCGM/NCCL-test)で検証可能なのに対し、後者は code bug や設定ミスが主因で「ユーザ側で検証スクリプトを動かせる」前提が崩れる可能性がある。pre-ticket interception の paradigm はどのドメインで適用可能か。([[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]]) - TSGuard の User-related カテゴリ精度低下(infrastructure 起因のエラーメッセージを持ちつつ実は user 側操作ミス)は、semantic mismatch を伴うあらゆる多重原因シナリオで再現する一般的問題か。本論文の提案「Infrastructure Healthy 結論の reverse proof」は他ドメインで応用可能か。([[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]]) - TSGuard の階層タクソノミーは Microsoft Azure 内製スタックに紐付き(NVIDIA H100・InfiniBand・NCCL・CUDA 等)、他クラウド(AWS Bedrock/Trainium・Google TPU 等)では再構築が必要と本論文も指摘。タクソノミーの**転移学習**(既存タクソノミーを別クラウドへ転用する自動マッピング)は実現可能か。 - Remil+ 2024 が独立タスクとして立てた Classification と Deduplication は、本 wiki の LLM 期インシデント管理研究でどこまで明示的に扱われてきたか。[[OpsAgent]]・[[FLASH]]・[[Bits AI SRE]] 等の論文中、deduplication を独立フェーズとして測っているものはあるか、それとも triage / assignment / RCA に内包されたままか。LLM-era で Eclipse/Mozilla の bug repo の 20-40% 重複という pre-LLM 期の知見が、production incident でも再現するかは未確認。([[@2024__arXiv__AIOps Solutions for Incident Management]] §3.3 Incident Deduplication) - GRLIA の対応時間短縮はインシデント集約の運用価値を示すが、短縮が「候補数減少」「モニタ設定の品質改善」「OSE の認知負荷低下」のどれに由来するかは分解されていない。インシデント集約の本番価値を測る指標は NMI だけで足りるか、それとも investigation steps / MTWTF / TTM への寄与を直接測るべきか。(Source: [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems]]) - Remil+ 2024 の 4 層 Maintenance Strata で Business 層(SLA・取引数・ビジネス KPI)のインシデント検知・診断・緩和は、本 wiki の LLM 期論文ではほとんど扱われていない。これは「Business 層は人間の判断が必要で AI 化が遠い」のか、「Business KPI モニタリングは別領域(BI/A&O)として AIOps の射程外」なのか、それとも本 wiki の選定バイアスか。([[@2024__arXiv__AIOps Solutions for Incident Management]] §2.3) - X-lifecycle Learning([[@2024__FSE__X-lifecycle Learning for Cloud Incident Management using LLMs]])は依存サービス障害（IC3 の約 50%）で有効性を示したが、残り 50%（コードバグ・ハードウェア障害・設定ミス等）に有効な追加コンテキストは何か。ソースコード・コミット履歴・設定変更ログ等を補完する場合、トークン制限の超過をどう扱うか。また内部 DTS のような組織内専用データベースへのアクセスを前提とする設計は、組織外や中小規模チームへの汎化が困難——このアーキテクチャ的前提条件をどう緩和するか。 - [[@2023__SREcon23EMEA__The World Blew Up but We're All Okay - How We Managed a Massive-scale Incident at Datadog]] が報告する「共通 OS ディストリビューションが事実上のグローバル障害波及経路になる」問題に対し、AIOps エージェントの自動診断・自動緩和はどこまで有効か。OS レイヤーの自動セキュリティ更新のような「サービスオーナーが直接コントロールしない変更」を事前に検知・リスク評価する仕組み(依存関係グラフ・変更影響予測)は、本 wiki が集約する変更起因インシデント研究の対象に含まれているか、それとも既存研究の対象外(アプリケーションデプロイに限定)か。 ## 関連 - ソース: [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]] / [[@2018__Google SRE Workbook__Incident Response]] / [[@2018__Google SRE Workbook__Chapter 10 Postmortem Culture - Learning from Failure]] / [[@2018__Google SRE Workbook__Appendix C Results of Postmortem Analysis]] / [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] / [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]] / [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]] / [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] / [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]] / [[@2024__OSR__LLexus - an AI agent system for incident management]] / [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]] / [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]] / [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]] / [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems]] / [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] / [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] / [[@2021__SREcon21__Evolution of Incident Management at Slack]] / [[@2023__SREcon23EMEA__The World Blew Up but We're All Okay - How We Managed a Massive-scale Incident at Datadog]] / [[@2025__Datadog Engineering Blog__Failure is inevitable - Learning from a large outage and building for reliability in depth at Datadog]] - 概念: [[インシデントトリアージ]](本ソースが導入した工程別概念)/ [[AIOps]](4-level taxonomy)/ [[根本原因分析]](RCA、ライフサイクル第 3 段)/ [[障害緩和]](ライフサイクル第 4 段) / [[TSG自動化]] / [[時系列質問応答]] / [[SRE Benchmark]] / [[エージェント運用安全性]] / [[NetOps]] / [[変更起因インシデント]] / [[クラウドモニタリング]] / [[インシデント優先順位付け]] / [[LLM分散学習]] / [[耐障害LLM訓練]] / [[TTXメトリクス]] / [[アンインシデント]](宣言されない潜在インシデント・Gray Zone) / [[インシデント認識論]](5フェーズ・証拠2×2・探索パターン・仮説/テスト基準) / [[グレースフルデグレーデーション]](部分障害時の継続設計) - エンティティ: [[Microsoft]] / [[AIOpsLab]] / [[SREGym]] / [[Bits AI SRE]] / [[ARFBench]] / [[Datadog]] / [[AlertGuardian]] / [[LogPilot]] / [[Tencent]] / [[TSGuard]] / [[RCACopilot]] / [[Microsoft Azure]] / [[Brent Chapman]] / [[Slack Technologies]] / [[Laura de Vesine]] / [[Laurent Bernaille]] / [[Andreas Deuschl]] / [[Dynatrace]] / [[Jack Kingsman]] / [[Atlassian]] - 関連 MOC: [[AIOps - Failure Detection - MOC]] / [[LLM4SRE - MOC]] / [[SRE - MOC]] ## 出典 - [[@2025__SREcon25EMEA__The Un-Incident]]（Un-Incident 4 類型・Gray Zone Playbook・「インシデントか否かは問いではない」） - [[@2023__SREcon23Americas__Incident Commanders]]（「インシデントのサイクル」ライフサイクル図、IC/アナリスト役割区分） - [[@2021__SREcon21__Evolution of Incident Management at Slack]]（p.10 Response/Review/Analysis の3部構成図、口頭説明の背景・数値） - [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]（§I–VIII、Table I、Figure 7–9） - [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]]（Appendix A.2 インシデント対応ワークフローと TSQA の位置づけ） - [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]（§V-A 本番実績 MTTR 156→21 分・日次 30 万→1.5 万、表 III/IV、§IV-C rule refinement の 4 エージェントと 1,174 提案→375 受容） - [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]]（§II-C AIOps ライフサイクル detect/triage/diagnose/mitigate/learn、§VI-C 段の継ぎ目の翻訳、§II-D/§VI-E workflow artefacts の信頼階層と攻撃面、表IV タスク taxonomy、表I operational artefacts as data types） - [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]（表2 5 手法精度比較・平均 73.9% 対 60.7%(TaskWeaver)、表3 人手評価 TTM 5.3 分・総合 4.3/5、表4+図9 TSG 品質問題 6 カテゴリ・Pass 約 8.5%、§4.3 ヒントサイト統合効果 +6%〜+7.5%） - [[@2024__OSR__LLexus - an AI agent system for incident management]]（§1 問題設定・TSG の 3 課題、§3 設計原理・プランコンパイラ、§4 マルチステップ計画生成、表1〜2 コスト分析、図10 オンライン方式との費用対効果比較） - [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]]（§3 92 TSG 実証研究・並列性 ~46%、§4 TSG Mentor F1 0.81、§5 DAG 抽出 F1 94.89%・QPP 97.3%・GPT-4.1 約 94%・実行時間 32.9〜70.4% 削減） - [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]（3 大規模インターネットサービスの障害原因分析、オペレータエラー支配性、設定ミスが最大カテゴリ、TTR の 75% がオペレータ起因） - [[@2018__Google SRE Workbook__Incident Response]]（IC/CL/OL、3C、Google と PagerDuty の事例、事前訓練） - [[@2018__Google SRE Workbook__Chapter 10 Postmortem Culture - Learning from Failure]]（悪い/良いポストモーテム比較、共有とアクションアイテム追跡） - [[@2018__Google SRE Workbook__Appendix C Results of Postmortem Analysis]]（ポストモーテムの集計分析、変更起因障害とプロセス失敗） - [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]]（§4 変更種別・根本原因、§5 導入タイミング、§6 検知メカニズム・TTD・モニター失敗 3 類型、§7 緩和戦略・RaIC/RbIC・TTM 40.6%短縮、§8 実践的推奨事項） - [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]]（§3 重篤度・TTD/TTF 比較、§4 変更カテゴリ・根本原因、§5 緩和戦略、§6 4 課題: 不足したモニタリング指標/不正確な変更モニタリング/低ビジネストラフィック/非効率な異常変更箇所特定） - [[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]](§II T1/T2/T3 分解・影響因子の実証分析、§III TTMPred 設計、§IV Table1/2 実験結果) - [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]](§1 user-centric paradigm、§2.1 AI ワークロード障害分布(GPU 52.47%・recurrence 8.78)・症状-原因多対多、§3 オフライン知識統合 + オンライン 3 段パイプライン、§5 本番 208 件 Micro F1=0.854 / Macro F1=0.816・RCACopilot 比 +19.8/43.6%・検証時間 -63.4%) - [[@2024__arXiv__AIOps Solutions for Incident Management]](§2.1 用語法と時系列スキーマ、§2.2 reactive/proactive プロトコル・palliative/curative/predictive/prescriptive、§2.3 4 層 Maintenance Strata、§3.3 4 フェーズ × 9 タスク手続き、§4 9 軸 taxonomy・8 データソース・contamination zone) - [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]]（§IV OncallX 3 モジュール設計、§V-B 対応 Pass Rate 78.26%、§V-C トリアージ ACC@1 0.652、§V-E 本番 対応 21 秒・トリアージ 4 秒） - [[@2023__SREcon23EMEA__The World Blew Up but We're All Okay - How We Managed a Massive-scale Incident at Datadog]]（systemd/networkd 経路フラッシュによる 2023年3月8日大規模マルチクラウド障害、IC ローテーション・ワークストリーム自己組織化・クラウド API レート制限による復旧ボトルネック） - [[@2026__SREcon26Americas__Epistemology of Incident Management]]（Kingsman の 5 フェーズ Incident Loop 認識論・証拠 2×2・探索 3 パターン・仮説 3 条件・テスト 6 基準・3 ボーナスコミュニケーションスキル）