# インシデント管理 ## 定義 インシデント管理（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%）——を定量化した。 検知→トリアージ→診断→緩和の 4 段モデルは合意された骨格であり、Microsoft・Ant Group・ビリオンユーザー規模サービスなど複数の独立研究が、緩和フェーズ(特に T3: 最終担当チーム確定後の緩和)が TTM(Time to Mitigation)の大半を占めるという時間構造を実測で裏付けている。一方でこの骨格は、LLM エージェントが段そのものでなく段と段の継ぎ目(翻訳)に価値を持つという整理や、アラート発火前にまで遡る予防的介入(リリース遮断・積極的点検)へと射程を広げつつあり、静的な 4 段モデルは徐々に「継ぎ目の連鎖」「発火前後を貫く連続体」として読み替えられている。ICS(Incident Command System)由来の役割設計は SRE 実務の標準として広く定着したが、本番のライブインシデント対応の認知的複雑さを単純化しすぎているという民族誌的批判(Maguire, 2020)との間に争点が残る。MTTR 単体を KPI として扱うことへの批判は近年強まっており、TTX への細分化や複数次元の直接測定への移行が提案されている。GenAI・AI ワークロード基盤のインシデントは GPU 偏重・recurrence 高という従来クラウドと質的に異なる障害分布を示し、既存の AIOps ベンチマーク設計との乖離が指摘されている。 ## 子概念 - [[DSLクエリ推薦]] - [[ML障害管理の原則]] - [[TSG自動化]] - [[インシデントTTM予測]] - [[インシデントアナリスト]] - [[インシデントトリアージ]] - [[インシデントメトリクス]] - [[インシデント優先順位付け]] - [[インシデント対応成熟度モデル]] - [[インシデント認識論]] - [[インシデント調査戦略]] - [[オンコール自動化]] - [[クラウド障害ライフサイクル]] - [[クリティカルデジタルインフラ]] - [[コミュニティマネジメント]] - [[災害計画]] - [[自動化アーキタイプ]] - [[運用障害分析]] ## 検知と緩和のコスト構造 - **クラウド三社(AWS・Azure・Google Cloud)横断の 354 件ポストモーテム分析は、MTTM=304.2 分・緩和(Mitigation)フェーズが TTR の過半を占めるという時間コスト構造を初めて定量化した。** - 根拠: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]] — TTX 実測値(MTTD=16.9 分・MTTI=77.8 分・MTTM=304.2 分・MTTR=572.8 分)、TTR の 53% を緩和フェーズが占める - 関連: [[インシデントTTM予測]] — TTM 短縮を重要視する根拠を empirical に裏付ける - **検知段の失敗(ミス検知)は緩和コストを指数的に増大させ、「検知は治療に優る」という命題を実証する。** - 根拠: [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]] — Microsoft 300 超サービス・約 950 インシデントで、ミス検知の 27.25% がアウテージに発展、顧客報告インシデントはモニタ報告比で TTD が 10.7 倍・TTM が 3.75 倍 - 根拠: [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]] — Ant Group の 4 課題の筆頭も「不足したモニタリング指標」で、企業を跨いで同型の失敗が再現する - **ミス検知の 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%)は、モニタ設計の問題と運用の問題を分離する。** - 根拠: [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]] — 579 修正項目から帰納 - 関連: [[変更起因インシデント]] — 「不足したモニタリング指標(筆頭課題)」「不正確な変更モニタリング」と整合的 - **変更起因インシデントは緩和プロセスの選択(RaIC/RbIC)が TTM を律速し、T3(最終担当チーム確定後の緩和フェーズ)が TTM の約 70% を占める。** - 根拠: [[@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 時間単位)、緩和失敗は 18.6% で TTM を 87% 延長 - 根拠: [[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]] — Microsoft 20 システム・4 年分データで T3 平均 70.20% を定量化。別独立データ(Microsoft 4 年 vs. ビリオンユーザー 2 年)で同型の T3 支配が再現する - **モニタリングは変更起因インシデントの半数を検知できず、インシデントの報告ソース(モニタ/エンジニア/顧客)が TTM に構造的に影響する。** - 根拠: [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]] — 50.6% で利用者がモニターより先に検知(モニター TTD は利用者の 7.67 倍速いにも関わらず)。失敗原因は「モニター未設定 46.2%」「監視不能なインシデント 35.0%」「異常未認識 18.8%」の 3 類型 - 根拠: [[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]] §II-B — 顧客報告インシデントは症状のみ記述で担当チーム特定が困難なため最長 TTM を持つ - 関連: [[異常検知]] — 偽陽性バイアス([[TelecomTS]])・文脈なし検知の限界([[LogPilot]])に加え、変更後の新規異常パターンへのカバレッジ不足という第 3 の実務上の問題が加わる - **変更起因インシデントは重篤度・検知遅延が通常インシデントより構造的に高く、カナリアリリースは早期顕在化に有効だが性能問題起因のインシデントは遅延顕在化で捉えにくい。** - 根拠: [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]] — Ant Group(3000 以上のマイクロサービス)の 161 件で High/Critical 重篤度が通常の 2.6 倍、TTD の 75 パーセンタイルが 26.8 倍長い。4 固有課題(不足したモニタリング指標・不正確な変更モニタリング・低ビジネストラフィック・非効率な異常変更箇所特定) - 根拠: [[@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% 以上を占めるという長期的課題と接続し、標準的なカナリア解析だけでは変更後の監視期間設計(特に性能系メトリクス)が不十分 - **半数以上のインシデントは対処不要(incidental)であり、severity 割当の見直しと「候補集合を縮める」介入が工数削減に有効である。** - 根拠: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] — Microsoft 18 サービス・6 か月分で incidental incidents が平均 50.32%・TTR の 55.05% を消費。最高 severity 0 ですら incidental が 57.96% を占め essential(42.04%)を上回る逆転(Table 1) - 根拠: [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems]] — GRLIA は根本原因を直接当てず同一障害のインシデントクラスタで調査範囲を縮小し、Huawei Cloud Networking で平均対応時間を前月比 18.6〜24.8% 短縮 - 根拠: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] — incident 固有の時間相関(直前 10 件の relevant incidents を attention で統合)により AUC 0.808 を達成、bug severity prediction 流用(Rule 0.624/Bayes 0.586)を大きく上回る(time window 0 vs 10 の Wilcoxon 検定 $p < 0.05$) - **BRAIN(pre-LLM 期の産業 AIOps フレームワーク)の TTB(Time to Broadcast)指標は、担当者着手から全影響サービスへの周知完了までがほぼ TTM と同等の時間を要することを示した。** - 根拠: [[@2020__ESEC-FSE__Towards Intelligent Incident Management - Why We Need It and How We Make It]] — Microsoft 6 コアサービス・2 年超の実証研究。TTD/TTE/TTM/TTB/TTF の 5 指標で定量化し、下流依存性の不完全性を TTB 遅延の根本原因とする。IcM BRAIN(検知・自動トリアージ・相関の 3 機能)の本番展開で関与インシデント(44.8%)は 5 指標すべてで統計的に有意な短縮(Mann-Whitney-Wilcoxon 検定、すべて $p < 10^{-10}$) - **Google の 8 フェーズインシデントタイムラインは Incident Duration を「Detect から Resolve」に限定して定義し、修正機会を Stop・Faster・Prevent and Fix Culture の 3 方向に整理する。** - 根拠: [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]] p.12, p.26 — [[Sue Lueder]]([[Google]] SRE Program Manager)が Root Cause→Hits Production→Detect→Escalate→Mitigate→Resolve→Retrospect→Action Items の 8 フェーズを定義。潜伏フェーズと事後フェーズを Duration の外側で別管理する設計 - 関連: T3 支配・RbIC による TTM 40.6% 短縮・Detection Is Better Than Cure の 3 知見は、それぞれ「Faster の Mitigate 段」「Faster の Resolve 前緩和」「Faster の Detect 段」に写像できる ## メトリクス設計と KPI の妥当性 - **MTTR は統計的にノイズ優位(低頻度・高分散イベントで平均値の変化のほぼ全てがノイズ)かつ逆インセンティブ(最速低下策=同じインシデントの繰り返し)という二重の欠陥を持ち、インシデント管理プロセスの健全さを測る指標として機能しない。** - 根拠: [[@2025__SREcon25Americas__Incident Management Metrics that Matter]] — [[Jamie Luck]]・[[Laura de Vesine]] が提案。顧客信頼性は SLO で別途測り、プロセスの成功はオンコール健全性・プロセス品質・エンジニア能力・学習・エスカレーション等の 8 次元を直接測定すべきとする - 関連: 時間指標(MTTM 短縮・TTM 予測精度)は学術的リファレンス値として保持しつつ、KPI として組織に適用してはならない - **モンテカルロシミュレーションは、個別インシデントの修復時間を短縮しても MTTR が同程度改善するとは限らないことを実証し、TTX への細分化がその代替となる。** - 根拠: [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]] — [[Narimichi Takamura]]([[Topotal]])が 3 社の実インシデントデータで 10 万回シミュレーションを実施。各インシデントの修復時間を 10% 短縮しても MTTR が 10% 以上改善するのは 49%・50%・64% のケースのみ。代替として TTDetect・TTAcknowledge・TTEngage・TTInvestigate・TTIdentify・TTMitigated・TTFix・TTRecovery 等の細粒度 TTX を提案 - 関連: [[TTXメトリクス]] — 詳細を切り出し先とする - 根拠: [[@2023__SREcon23Americas__Far from the Shallows]] — Štěpán Davidovič(Google Cloud)の O'Reilly レポートおよび Courtney Nash の MTTR 批判とも整合 - **「合計顧客影響時間(TTR×影響顧客数)」という 2011 年の実務指標は、MTTR 単体批判の系譜に 10 年以上先行する早期の解決策を提供するが、分散・ノイズという統計的性質そのものには踏み込んでいない。** - 根拠: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 13 障害を活用する：ふりかえりの技芸と科学]] §13.2 — [[Jake Loomis]]([[Yahoo!]])が TTR 単体でなく合計顧客影響時間で計測すべきと主張 - 反証: 2025 年の [[Jamie Luck]]・[[Laura de Vesine]] の指摘や [[Narimichi Takamura]] のモンテカルロ実証は「生の解決時間だけでは組織の意思決定の根拠にならない」という同じ問題意識に基づくが、Loomis の解は顧客影響での重み付けにとどまり統計的再定義には至っていない - **重要度分類(severity)の逆転(最高 severity ですら incidental が essential を上回る)は、2011 年から標準化されてきた「潜在影響の大きさ」に基づく重要度設計が抱える構造的な誤分類リスクを、約 10 年後に定量的に裏づけたものと読める。** - 根拠: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 13 障害を活用する：ふりかえりの技芸と科学]] — 重要度 1〜3 を「潜在的な顧客影響の大きさ」で定義する早期の実務的枠組み - 根拠: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] — 最高 severity 0 ですら incidental が 57.96% を占める逆転を Table 1 で実証 - **Google 実務者による「エスカレーション・即時対応・組織的対応」の 3 条件によるインシデント定義は、宣言されたインシデントの過半が対処不要という誤分類コストを事前に抑制するための境界設定として機能する。** - 根拠: [[@2022__OReilly__Anatomy of an Incident - Chapter 1 Introduction]] — ITIL のような広い incident 定義とは意図的に区別。「インシデント件数そのものを測定対象にすると宣言をためらう心理が働き遅延宣言を招く」とも指摘 - 関連: [[@2025__SREcon25Americas__Incident Management Metrics that Matter]] の「MTTR・インシデント件数は逆インセンティブを持つ」という後年の批判と、狭義の定義選択とメトリクス選択という異なる角度から「件数を KPI 化しない」という同じ結論に至る - **メトリクス⊆アラート⊆インシデントという包含関係は成立せず、Google 実務者の明示は alert management と incident management を別ライフサイクルとして分離する学術的な設計の実務的根拠を与える。** - 根拠: [[@2022__OReilly__Anatomy of an Incident - Chapter 1 Introduction]] — 「すべてのメトリクスがアラートになるわけではなく、すべてのアラートがインシデントになるわけでもない。逆にアラートなしにインシデントが起きることもある(例: セキュリティチームからの侵害の疑いの報告)」 - 根拠: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]] — event ⊃ alert、severe alert + user complaint → incident という ITIL/ITSM 由来の分離を学術的に定式化 - **Google が明文化する「インシデント管理は 3 日以内」という組織ポリシー上の上限は、TTM 実測研究群が扱う分〜時間単位の粒度とは異なる階層で「インシデント管理の時間」を扱う。** - 根拠: [[@2022__OReilly__Anatomy of an Incident - Chapter 3 Scaling Incident Management (Response)]] — 特定から解決までは 3 日を超えるべきでなく、根本原因・トリガー条件の恒久対応(数か月〜数年)は緩和後の別プロセスへ切り離す - 関連: [[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]] の TTM 分布や [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]] の TTM 実測とはオーダーが異なり、実務ポリシー上の上限(日単位、緩和を諦めて長期対応へ切り替える判断基準)と研究上の実測値(分〜時間単位)という異なる階層で「時間」が語られる ## ICS 由来の役割設計と大規模インシデント対応の実践 - **SRE Book の ICS(Incident Command System)由来 4 役割(インシデントコマンダー/オペレーション/コミュニケーション/プランニング)は、非管理型インシデントの最大の悪化要因である「フリーランシング(独断行動)」の抑制を目的とし、マルチエージェント SRE の役割設計の直接の前駆である。** - 根拠: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] — ICS 処方。この役割分離は [[Stratus]] の 4 エージェント構成(Commander/Investigator/Executor/Undo)や [[OpsAgent]] の MAS 設計と構造的に対応 - 根拠: [[@2016__OReilly__SRE Book - Chapter 13 Emergency Response]] — テスト誘発型障害と訓練なし障害の対比で人間の判断力の価値を浮かび上がらせる - 根拠: [[@2016__OReilly__SRE Book - Chapter 15 Postmortem Culture - Learning from Failure]] — ブレームレスポストモーテム文化を「人でなくシステムの欠陥に焦点」という原則で定着させる - 根拠: [[@2016__OReilly__SRE Book - Chapter 33 Lessons Learned from Other Industries]] — 航空(CHIRP)・医療・製造業(CAPA)から非難なき振り返りが業界横断で有効であることを確認 - 根拠: [[@2016__OReilly__SRE Book - Chapter 16 Tracking Outages]] — Outalator はパッシブ集約とタグベースメタデータでアウテージ追跡を自動化する - **SRE Workbook は ICS 原則を事例・訓練・テンプレートへ落とし込み、インシデントの解決(影響緩和・復旧)と管理(対応者調整・情報流通)を分離する。** - 根拠: [[@2018__Google SRE Workbook__Incident Response]] — IC/CL/OL の役割を Google Home、GKE、Persistent Disk、PagerDuty の事例で検証 - 根拠: [[@2018__Google SRE Workbook__Chapter 10 Postmortem Culture - Learning from Failure]] — 悪いポストモーテムと良いポストモーテムを比較し、広い共有・アクションアイテム追跡・文化的インセンティブを強調 - 根拠: [[@2018__Google SRE Workbook__Appendix C Results of Postmortem Analysis]] — 変更起因障害やプロセス失敗を集計し、個別事故を組織学習へ変える入口を示す - **IC(Incident Commander)は「最強エンジニアのバッジ」ではなく「条件を整えるリーダーシップスキル」であり、人員配置は専任/兼任/外部委託あるいは Deliberate/per-domain/volunteer チームというトレードオフで選ばれる。** - 根拠: [[@2026__SREcon26 Americas__So You Want a New Incident Commander]] — [[Vanessa Huerta Granda]] が 10 年超の実践知から IC の仕事を People/System/Business の 3 軸に整理。Deliberate IC Team(専任・推奨、デメリット:過負荷)/IC per domain team(良い出発点、デメリット:一貫性)/IC volunteer team(スキル普及、デメリット:ストレス)の 3 類型 - 根拠: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] §Setting Up an Incident Response Team, §Identify Team Members and Roles — 専任フルタイムチーム/既存社員の兼任(two hats)/外部委託という、役割設計より一段下の人員配置レイヤーの選択肢を提示。ロール(role)は個人(individual)と独立で 1 人が複数ロールを兼ねシフト制で回してもよいと明記 - 関連: [[クロスインシデント分析]] — Enova が採用する「4 名専任チームへの集中化」は Deliberate IC Team の発展形として整合 - 留保: 専任/兼任/外部委託の選択が組織規模・インシデント頻度・予算のどの要因に支配的に効くかは未検証(未解決の問いを参照) - **Response Trio(コンダクター・コミュニケーター・問題解決者)は SRE Book の ICS と役割構成が対応しつつ、Joint Activity としての即興的適応を重視する点で補完的である。** - 根拠: [[@2023__SREcon23Americas__Human Observability of Incident Response]] — [[Matt Davis]] が [[Laura Maguire]] の Adaptive Choreography に基づき提唱。「人間が担う Support Humans 機能(Listen・Update・Guide・Monitor・Repair)はエージェントに移譲できるか」という問いを生む - 関連: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] — IC・Ops Lead・Communications Lead との役割対応 - **Slack の「Response/Review/Analysis」という組織的 3 部構成と「インシデントのサイクル(Circle of Incidents)」円環図は、技術的ライフサイクル(検知→トリアージ→診断→緩和)とは軸の異なる、組織的な学習サイクルを描く。** - 根拠: [[@2021__SREcon21__Evolution of Incident Management at Slack]] — [[Brent Chapman]] が Response(緊急対応)・Review(事後のブレームレス学習)・Analysis(複数インシデント横断の共通要因抽出)の 3 部で定義 - 根拠: [[@2023__SREcon23Americas__Incident Commanders]] — [[Vanessa Huerta Granda]]・[[Emily Ruppe]] が「平常運転→インシデント→事後学習→システム変化→新たな平常運転」という循環構造を図示。[[Incident Commander]] と [[インシデントアナリスト]] という異なる役割がこの円環の異なる局面(対応 vs 事後分析)を担当する根拠を提供 - 留保: 同じ「インシデント管理」という語が、技術的ライフサイクル(いつ・何を自動化するか)と組織的ライフサイクル(誰が・どう学習するか)という異なる分割軸で語られる実例であり、LLM エージェントの自動化対象を検討する際は両軸のどちらを指しているかを区別する必要がある - **Kingsman の「Incident Loop 認識論」は、インシデント対応の各フェーズを「知識の問い」として再定義し、証拠 2×2・探索 3 パターン・仮説 3 条件・テスト 6 基準という認識論的ツールを与える。** - 根拠: [[@2026__SREcon26Americas__Epistemology of Incident Management]] — [[Jack Kingsman]]([[Atlassian]])が Google SRE Book の Incident Loop を検知/宣言・生存/トリアージ・検査・診断・テスト/処置の 5 フェーズに体系化。"Incidents are all about knowledge" というフレーズは、ライフサイクル研究群の目的関数を人間実践の言葉で言い換えたものと読める - 関連: [[インシデント認識論]] に詳述 - **コミュニティマネージャは、ICS の「コミュニケーション担当」ロールが体系化される 5 年前に、ユーザ向け情報発信という下位機能を専任職として実務運用していた。** - 根拠: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 8 コミュニティ管理とウェブオペレーション]] — Flickr の実務。「詳細より先に問題を認知している事実を伝える」「事前確立したインシデントチームへ問い合わせを一本化し経営層の個別対応を防ぐ」という具体的運用ルール - 反証: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] は ICS の「コミュニケーション担当」がユーザ(社外)向けと組織内・経営層向けのどちらを主に想定するか明示しない。8 章の実例は、この役割の内部に少なくとも 2 種類の発信対象が分岐しうることを示唆する - 関連: [[コミュニティマネジメント]] - **500 人超・14 時間・70 超チャンネルという超大規模インシデント対応でも、IC ローテーション+ワークストリーム自己組織化という最小限の骨格が機能し、共通基盤(共通 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 ノード障害を発生。単一 Zoom 通話に 14 時間で 493 人が入退室する規模でも、IC・コミュニケーションリード・roving troubleshooter という骨格が機能した - 関連: [[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]] のインシデント対応成熟度モデルが説く「検知だけでなく対応フローの組織的定着が必要」という知見の、超大規模側での実証例と読める - 留保: [[Laura de Vesine]] は「事前の綿密な計画やテーブルトップ演習よりも、信頼・非難なき文化・即興力が規模のスケーリングを支えた」と総括する - **急激なスケールアウトはクラウドプロバイダの API レート制限・非公開クォータという新種のボトルネックを生み、応答者の増員は system-of-systems 障害の緩和を自動的には加速しない。** - 根拠: [[@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 証明書発行のボトルネックを連鎖的に引き起こした - 根拠: [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]] — Google の "Mayan Apocalypse"(2019-06-02)では 40 人超のオンコーラーが参加してもそれぞれ自分のスタックの専門家にとどまり、全システム横断の見通しを持つ者がいなかったため並列化が緩和を加速せず、Tech IRT のインシデントコマンダーがコミュニケーションと役割分担に構造を与えて初めて解消した - 関連: 技術スタックが 1 人の理解を超えて拡大すると、コンポーネント応答者(プロダクト特化)→SoS 応答者(Tech IRT)という二層構造が必要になる([[@2022__OReilly__Anatomy of an Incident - Chapter 3 Scaling Incident Management (Response)]])。この二層構造は Mayan Apocalypse 事例(規範と実例が相補的に補強し合う関係)の一般化された設計原理にあたる - **平常時に合理的な設計判断(外部ユーザー優先の通常方針)が、大規模障害時には対応能力そのものを削る二次的な障害波及経路になりうる。** - 根拠: [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]] — Google の「社内トラフィックよりユーザートラフィックを優先する」通常方針(0.1% のインシデント対応者は通常このスロットルを回避できる)がカスケード時には社内ツール自体を巻き添えにし、アラート配信を阻害。インシデントコマンダーが対応専用のアクセス機構でこのフラグを覆すことで初めて社内トラフィックの余地を確保できた - 関連: [[@2023__SREcon23EMEA__The World Blew Up but We're All Okay - How We Managed a Massive-scale Incident at Datadog]] が報告する「共通 OS ディストリビューションが事実上のグローバル障害波及経路になる」構造と同型 - **「ヒーロイズムは有害」という規範は、SRE Book のフリーランシング批判・Mayan Apocalypse の実例・結論章の 3 点が独立した文脈で収束させる。** - 根拠: [[@2022__OReilly__Anatomy of an Incident - Chapter 7 Conclusion and Moving Forward]] — 「少数のヒーローが劇的に火消しをするという想像は魅力的だが有害な考え方(a heroism mindset is harmful)」であり、上手さは個人ではなくチーム全体が準備・対応・緩和と復旧のサイクルを地道に改善し続けることだと明言 - 根拠: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] — 非管理型インシデントの最大の悪化要因として特定する「善意に基づく独断行動(フリーランシング)」という一般則 - 根拠: [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]] — 対象コンポーネントの経験を持たない Tech IRT メンバーが IC として機能したのは、技術的な英雄的介入によってではなくコミュニケーションと役割分担に構造を与えたことによる、という実例 - **FEMA/ICS 由来の 4 役割は SRE と ML で同一だが、検出のしやすさ・関与する役割とシステムの広さ・タイムラインの明確さの 3 点が ML で変化する。** - 根拠: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 11 障害対応]] §11.1.2 — FEMA の National Incident Management System から引く 4 役割(障害指揮官・コミュニケーションリーダー・オペレーションリーダー・計画リーダー)は「ML 障害であろうとなかろうと変わらない」と明言したうえで、上記 3 点の変化を特定 - 根拠: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] — 同一の ICS 4 役割処方 - 関連: [[ML障害管理の原則]] に詳細を集約する > [!contradiction] ICS 由来のインシデント管理モデルの妥当性 > 本ページはこれまで SRE Book の ICS(Incident Command System)由来の 4 役割(インシデントコマンダー/オペレーション/コミュニケーション/プランニング)を、Ch33 が挙げる業界横断の非難なき振り返り事例(航空 CHIRP・医療・製造業 CAPA)と併せて、フリーランシング抑制に有効な枠組みとして肯定的に集約してきた。これに対し [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 3 The domain of Critical Digital Infrastructure]] は、ソフトウェア工学領域が ICS を輸入する試み——本ページが繰り返し参照する SRE Book(Beyer, Jones, Petoff and Murphy, 2016)そのもの——を名指しし、「エンジニアリングチームが実際にどうインシデントに対応しているかを詳細に調べた研究は、このモデルが単純化しすぎている(an oversimplification)ことを示唆している」(Grayson, 2018; Woods, 2017 を引用)と述べる。著者はさらに「専門的な信頼性エンジニアが本番システムをトラブルシューティングする様子の記述的分析は、サービス停止時に直面する複雑さ・圧力・不確実性の全体を捉えきれておらず、これが協調を管理しようとする試みがパフォーマンスを支援するどころか制約してしまうことがある理由の一端である」と踏み込む。両者は同じ SRE Book の ICS 処方を参照しながら、一方(本ページが集約してきた文脈)は役割分離の設計原理としての有効性を産業横断比較やマルチエージェント SRE 設計との構造対応で裏づけ、他方(Maguire 2020)はその設計原理が本番のライブインシデント対応の認知的複雑さを記述するには不十分だと批判する。Grayson (2018)・Woods (2017) の一次研究は本 wiki に未取り込みであり、批判の具体的な論拠は現時点で検証できていない。(Source: [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 3 The domain of Critical Digital Infrastructure]], [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]]) ## TSG・ワークフロー自動化の設計空間 - **LLexus は LLM の使用をインシデント時でなく計画フェーズ(TSG 作成・更新時)に前置し、実行時は決定論的プランをそのまま走らせることでコスト優位性を拡大しハルシネーションリスクを最小化する。** - 根拠: [[@2024__OSR__LLexus - an AI agent system for incident management]] — Microsoft の SaaS 製品向け。インシデント件数が増えるほどコスト優位性が拡大し(少数インシデントでオンライン方式とコストが逆転)、「TSG を source of truth として扱うことで自動化の副産物として TSG の品質も向上する」という正のフィードバックループが成立 - 反証: FLASH と同様、TSG の品質が自動化の律速という共通の壁にぶつかる——品質の低い TSG は多くの反復ラウンドを要し計画コストが 3 倍近く増大する - **FLASH は反復インシデントが TSG(Troubleshooting Guide)という構造化ドキュメントを持つ固有性に着目し、「TSG に書かれた診断ステップをエージェントが信頼実行できるか」という実行信頼性問題として問いを立て直す。** - 根拠: [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]] — 5 シナリオ・250 件の評価で TaskWeaver 比 +13.2%(平均 73.9% 対 60.7%)。CAPA のような外部ツール依存シナリオでは精度が 50% 程度にとどまり、TSG の品質(Ambiguous Action が全 TSG の約 40%)が自動化可否の主要律速 - **FLASH・StepFly・LLexus の 3 本は「既存 TSG を LLM エージェントで実行する」という同じ問いを LLM を働かせる時点(インシデント時/計画時/両方)で別々に解くが、共通して TSG 品質が自動化の律速であることを独立に指摘する。** - 根拠: [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]] — オフライン DAG+QPP 抽出+並列 scheduler-executor。専用ツール [[TSG Mentor]] で F1 0.81 - 根拠: [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]] — Pass(そのまま自動化可能)は約 8.5% にすぎない - 根拠: [[@2024__OSR__LLexus - an AI agent system for incident management]] — 低品質 TSG で計画コスト約 3 倍 - 関連: [[TSG自動化]] に切り出して横断集約する - **FlowXpert は既存 TSG の存在を前提とせず、運用ドキュメントから TSG を自動生成する上流問題に取り組み、Scorer の AI フィードバック品質という別のボトルネックを DPO による共進化で同時に解こうとする。** - 根拠: [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]] — Huawei Cloud では 189 種のインシデントに対しワークフローを手作成(7 人×7 時間/1 件)していたのを 22.1 秒に短縮、10 週間本番展開で承認率約 80% - 留保: ワークフロー生成(FlowXpert)→実行([[FLASH]]/[[LLexus]] 型)の 2 段パイプラインは論文未検討 - **プレイブックは静的ドキュメントでなく、利用実態の監視→改善提案→インシデントからの新規生成という agentic loop に組み込まれる production artifact へ転換しつつある。** - 根拠: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]] — SRE Book Ch6 が示す「プレイブックは MTTR を 3 倍改善する」という人間運用の効果を一段先へ進め、プレイブック保守自体を agentic loop に組み込む - 根拠: [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]] — プレイブックの人間運用での効果 - 関連: [[TSG自動化]] が論じる「TSG の品質が自動化可否の主要律速」という FLASH/LLexus の知見(Ambiguous Action が TSG の 40% を占める)に対する、律速そのものを agentic に育てるフィードバックループという対処パス - **X-lifecycle 学習は「どの SDLC 段階の情報を LLM に渡すか」というコンテキスト選択が RCA 精度の律速になることを示し、TSG 品質問題と双対の問題を加える。** - 根拠: [[@2024__FSE__X-lifecycle Learning for Cloud Incident Management using LLMs]] — 依存サービス障害には上流依存サービス説明が有効(InC DEP: BLEU 5〜38% 向上・NUBIA 54.67% 向上)、モニタ SLO 分類にはサービス説明が有効(accuracy 0.75→0.79)だが、リソースクラスにはコンポーネント説明が逆効果になりうる。「追加情報がタスクに意味的に対応しているときだけ有効」 ## アラート・トリアージ・診断の上流下流介入点 - **AlertGuardian は denoise→summary→rule refinement を一気通貫のライフサイクルとして扱う初の experience paper であり、LogPilot の単発アラート診断と対比される「ライフサイクル全体最適化」という処理単位を確立した。** - 根拠: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]] — 本番([[Tencent]] と読める Company-X)で MTTR 156→21 分(7.4 倍)・日次アラート 30 万→1.5 万を達成 - 根拠: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] — 単発アラート診断。同じ ASE2025 の両論文は同じ大規模オンラインサービスの本番アラートを対象にしながら処理の切り出し単位(単発 vs ライフサイクル)が異なる - **AlertGuardian のルール改善(rule refinement)は下流の抑制でなく上流のアラートルール品質を直接改善するフィードバックループを持ち、alert/incident を別ライフサイクルとして分離する設計や、アラート発火前にまで介入を遡らせる統一運用パラダイムと同じ「上流回帰」の方向を共有する。** - 根拠: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]] — オーケストレータなし 4 エージェント(Detect/RAG/Rule/Review)+反復、停止条件=構文・重要アラート保持・ノイズ比 5%、30 反復上限。human-in-the-loop で 1,174 提案→375 受容(32%) - 根拠: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]] — Yu+ 2024 は ITIL/ITSM 由来の概念(event ⊃ alert、severe alert + user complaint → incident)に基づき alert management と incident management を別ライフサイクルとして扱う一方、Microsoft は全アラートを incident として扱うと Table 4 で明示する対比軸を提供 - 根拠: [[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]] §1, §2.1, §3.2 — [[Bian Que]] は統一運用パラダイムを 3 カノニカルパターン(リリース遮断・積極的点検・アラート根本原因分析)として定式化し、3 つ目のみがアラート後対応。KuaiShou 本番で 75% のアラート量削減は主にリリース遮断と積極的点検が閾値到達前に問題を解決した結果 - 関連: [[PAGER]]([[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]])が提案した積極的監視と従来のリアクティブな IM を Bian Que は 1 つの統一フレームワークに収める。[[アラート管理]] に上流側の集約を切り出す - **LLM エージェントの価値はライフサイクルの各段そのものでなく、段と段の継ぎ目(翻訳)にあるという整理が、8 プロセスの統一アーキテクチャや 4 フェーズ×9 タスクの細分化を横断結合する形で提出されている。** - 根拠: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]] §VI-C — detect/triage/diagnose/mitigate/learn と置きつつ、価値はチケット文→テレメトリクエリ、テレメトリ結果→仮説、仮説→緩和、緩和→変更記録という人間が時間を費やす翻訳にあると整理。タスク taxonomy(表IV)は incident triage & routing・evidence acquisition・RCA・remediation planning・change safety & rollout control を各々の入力・ツール面・運用上の成功基準で定義 - 根拠: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]] — 2008-2022 の 89 件を representation・linking・triage・mitigation・resolution の 5 プロセス(+alert 側 3 プロセス)で分類した Fig.5 のアーキテクチャに、[[FLASH]]・[[StepFly]]・[[LLexus]](mitigation/resolution の TSG 実行)、[[FlowXpert]](対応セル無し)、[[OpsAgent]](triage+RCA+mitigation の融合)、[[AlertGuardian]](representation/linking を跨ぐ rule refinement)を当てはめると、分類セル単位で切れない多段融合が LLM 期の主流であることが分かる - 根拠: [[@2024__arXiv__AIOps Solutions for Incident Management]] §3.3 — Remil+ 2024 はトリアージを {Prioritization, Assignment, Classification, Deduplication}、診断を {RCA, Correlation}、検知を {Detection, Prediction} に細分化する。この細分粒度を入れると [[OpsAgent]] の 4 エージェント設計を {Prioritizer, Classifier, Deduplicator, Router} の分業として、[[AlertGuardian]] の rule refinement を Classification と Deduplication を横断する上流介入として、[[FLASH]]/[[StepFly]]/[[LLexus]] の TSG 自動化を Mitigation+Correlation として再解像度化できる - 根拠: [[@2024__arXiv__AIOps Solutions for Incident Management]] §2.3 — Maintenance Strata の 4 層モデル(Technical/Application/Functional/Business)は障害分布の業務インパクトを縦軸として補い、[[TSGuard]] が Technical 中心・[[AlertGuardian]] が Functional/Business 中心・[[Bian Que]] が Application/Functional 横断と整理できる - **OpsAgent は 14B の軽量オープンモデル+PPO 強化学習と反省ベース知識蒸留の二重自己進化により、大型 closed-source モデルで高精度という既存 MAS 型 IM とは異なるトレードオフ軸(小型 open-source+自己進化で高汎化・低コスト)を示し、異種テレメトリの統一テキスト化を MAS 協調の前提条件とする。** - 根拠: [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]] — 既存 MAS 型 IM([[D-Bot|@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]]・Flow-of-Action)は GPT-4 等の closed-source LLM と静的 SOP/知識ベースに依存し再学習なしの経験蓄積機構を持たない。[[OpenRCA]] ベンチマークで SOTA(RCA-Agent w/Claude 3.5 Sonnet)比 Correct +46.63%、[[Lenovo]] 本番 53 日・10,492 件で 84.09% 精度・解決時間 2.5 時間→126 秒 - 根拠: [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]] §3.2, Table 2 — training-free データプロセッサ(メトリクス: 3σ 検知+CNN 形状分類、ログ: keyword+TF-IDF、トレース: 95 パーセンタイル高レイテンシスパン+3 ホップ呼び出しパス)。アブレーションでプロセッサ除去時の Correct 率は 16.54%→2.26% と激減 - 反証: [[マルチモーダル障害診断]] で DL モデルが生テレメトリを直接処理するのとは対照的な「テキスト変換によるモダリティ統一」アプローチ - **MagmaScope は IM グループチャットを根本原因変更特定の一次コンテキスト源として活用し、Google SRE AI は IMAG プロセスの上に人間 IC を置き換えない 4 種のエージェント(監視集約・ハンドオフ生成・ポストモーテム下書き・コミュニケーション管理)を補助層として被せる。** - 根拠: [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] §4.3, Figure 5 — [[ByteDance]] の緊急インシデント対応プラットフォーム上で 1 年超稼働・10 以上のビジネスグループに展開。チャット進行とともに精度がジャンプする(Figure 5)ことは、IM ライフサイクルの診断段階で人間の推論が蓄積することが機械的な根本原因変更特定を改善させるフィードバック構造を実証。[[ARFBench]] が Slack タイムラインを TSQA の評価データとして活用するのと同型の観察を本番システムとして実装 - 根拠: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]] — SRE Book Ch14 の ICS 4 役割に対し、コミュニケーション面の監視・集約/SRE 間ハンドオフ文書生成/ポストモーテム下書き作成/内外コミュニケーション管理という 4 エージェントを被せる。[[SRE AI Autonomy Levels]] の Self-Direct 軸を Mitigate と分離して保つ方針を、agentic 補助層でも貫く - **DSL クエリ推薦(Xpert)とユーザ側事前診断(TSGuard)は、従来 provider-centric な診断が扱わなかった調査フェーズ・報告フェーズという別の介入点を開拓した。** - 根拠: [[@2024__ICSE__Xpert - Empowering Incident Management with Query Recommendations via Large Language Models]] — OCE が手動記述する KQL クエリの自動推薦。Microsoft 大規模クラウドの実証で (1) インシデントの 50% 以上が KQL 1 件で管理(少数集中)、(2) クエリはサービス間で非移転性、(3) 月次でのテンプレート変化率が高い(時変性)という 3 特性から ICL でパラメータ更新なく適応する設計を裏付け、オンライン Xpert はオフライン fine-tune 型 CodeT5+ を Identicality で 17.69 対 2.62 と上回った - 根拠: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] — 既存研究([[AlertGuardian]]・[[LogPilot]]・[[FLASH]]・[[LLexus]]・[[OpsAgent]] 等)がすべて provider-centric(ユーザがチケット報告→プロバイダが診断)を所与とするのに対し、[[TSGuard]] はチケット提出前にユーザ側で自動診断する pre-ticket interception layer。Azure 本番 1 年の median TTM=52.5 時間/mean 83.0 時間という inefficiency を「報告品質のばらつき+知識ギャップ+一律トラブルシューティング負荷」が生むと分析 - 関連: AlertGuardian が「上流のアラートルール品質」で介入したのと同じく「上流のチケット品質」を介入点に選ぶが、介入主体をユーザ側のエージェントに移している点が新しい - **TSGuard の半自動タクソノミー構築は、TSG 生成(FlowXpert)・ルール生成(AlertGuardian)と並んで、人間向け運用知識を AI 向けに半自動構築する上流側の発展を示す。** - 根拠: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] — Algorithm 1(LLM 判定で既存ノードへ紐付け/新規ノード作成/曖昧→スキップ+専門家のスクリプト割当)。Microsoft Azure 1 年分の本番データから 6 main/28 sub/97 detailed の 3 階層を 570 GPT-4o invocations+448.4 秒+$9.89 で構築。AutoARTS(Dogga+ ATC 2023)の人手構築(multi-person-year)に対する自動化路線 - 根拠: [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]] — TSG 生成という並行する上流構築 - 根拠: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]] — ルール生成という並行する上流構築 - **トリアージ研究(COMET)は、人間向けの豊富なテキスト(議論・要約)よりも機械的に絞り込んだ疎な表現(キーワード)の方が下流タスクに有効という逆説を示し、精度の低いルールベース出力も後段 LLM 処理の補助信号として活用価値を持つ。** - 根拠: [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]] — [[DeepCT]]・[[DeepTriage]] が使う議論(discussions)テキストよりもフィルタ済みログ(TrimmedLogs)の方が、さらに LLM 生成要約よりもキーワードの方がトリアージ精度が高いことを、同一データセット上での直接比較(Table I・Table II)で示した - 根拠: [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]] Table VI method 4→5 — AutoAnalysis の出力(不正確でも)をタイトルとして追加するだけで ACC@1 が+5%改善。AlertGuardian の rule refinement が既存ルールを完全に置き換えず段階的に改善する設計や、DeepIP が既存シグナルを補助情報として活用する設計と同じ「レガシールールベースシステムを廃棄せず LLM の補助入力として再利用する」パターンが複数のライフサイクル段階で独立に再発見されている - 関連: [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]] の TSG 品質調査(Ambiguous Action 約 40%)や [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]] のルール改善受容率(7.5〜32%)が「既存の人間向けドキュメントをそのまま AI に渡しても機能しない」ことを示すのと同じ構造 ## 産業 AIOps の系譜と HITL・自動化実証研究 - **SAS(2011〜2013)は技術主導(分類ベース手動介入)から問題主導への転換を経験し、この教訓は LLM 期の AIOps 研究(OCE が実際に時間を費やすステップの明示的特定)まで継続している。** - 根拠: [[@2013__ASE__Software Analytics for Incident Management of Online Services - An Experience Report]] §VI-A — Service X チームからの「ログを見ていないのか」「根本原因を見つけられるか」というフィードバックを受けた転換が、CAR マイニング・FCA+DMI・GVSM 治癒行動推薦という SAS の 3 コア技術を生んだ - **HITL(Human-in-the-loop)設計は 2011 年の SAS 本番展開から 2020 年代の LLM エージェント・IR レベルフレームワークまで一貫して必要条件として維持されている。** - 根拠: [[@2013__ASE__Software Analytics for Incident Management of Online Services - An Experience Report]] §III-A-4 — 「完全自動診断は現実的でない」として OCE が意思決定に関与する HITL 設計を選択(2011 年展開) - 根拠: [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]] — 「AI が完全自律化する前に人間の承認を得る段階を維持する」という同型の設計方針 - 根拠: [[@2025__SRE NEXT 2025__Rethinking Incident Response - Context-Aware AI in Practice]] — [[Ryota Yoshikawa]] の IR レベル(IR0〜IR5)フレームワークも同じ HITL 設計方針。SAE J3016™ の L0〜L5 に対応し、IR1 は通知・記録補助、IR2 は判断支援・提案、IR3 は実行・監視責任も AI が担う段階。「2025 年時点で IR0〜IR2 は実現済み、MCP+Coding Agent により IR2〜IR3 が現実的になった」 - **SAS の段階的展開(v1.0→内部環境→1 データセンター→世界展開)は信頼構築による産業 AIOps 技術移転の最初期テンプレートであり、後続の LLM 期論文が「本番展開実績」を主要な貢献として強調する構図の先駆となる。** - 根拠: [[@2013__ASE__Software Analytics for Incident Management of Online Services - An Experience Report]] §VI-D — ログ解析機能だけの v1.0 を作り Service X 内部環境で無害性を実証してから段階的に展開 - 関連: FLASH(1 製品)・LLexus(SaaS 製品全体)・OpsAgent(Lenovo 53 日)の「本番展開実績」強調 - **SAS が示す「異種データ統合の必要性」(2011〜2012 年に判明)は、2020 年代のマルチモーダル障害診断研究が独立に到達した収束点として読める。** - 根拠: [[@2013__ASE__Software Analytics for Incident Management of Online Services - An Experience Report]] §III-B-A, §V — 単一データソース(分類ベース・メトリクスのみ)では実際の問題を解決できないという発見 - 関連: [[マルチモーダル障害診断]] が 2020 年代の独立した研究トレンドとして立ち上がったのは、SAS 的な「統合の必要性」への独立した収束と読める - **ChatOps(Scorebot, 2016)はチャットを操作プレーン化する実践として、2020 年代の LLM エージェントが扱う TSG 決定論的実行や通知ノイズ削減の初期形態を代表する。** - 根拠: [[@2016__SREcon16__Incident Management and Chatops @ Netflix Feat Scorebot]] — [[Al Tobey]]([[Netflix]])の Scorebot は Slack を操作インターフェイスに、人員グラフ探索・ステータスページ更新・メトリクス参照を Go 製ボットで自動化。bookmarking・presence・after-hours・secrets 管理という 4 機能は 2020 年代の [[FLASH]]/[[LLexus]] の「TSG の決定論的実行」と機能構造として対応 - 関連: 「itch: the bot is obnoxious(ボットが騒々しい)」というペインポイントは、[[AlertGuardian]] が本番で 30 万/日のアラートを 1.5 万/日に削減した課題(通知ノイズが運用を圧迫する)の初期形態。SAS(2011〜2013)と Scorebot(2015〜2016)は LLM 以前の産業 AIOps 自動化の二本柱で、「機械学習モデルによる診断」と「チャットボットによる操作自動化」という異なる介入軸を代表する - **オペレータエラーの支配性(構造的に約 3〜4 割)は 1986 年の Tandem から 2026 年の GenAI クラウドまで 20 年超にわたり持続しており、障害注入ベースの AIOps ベンチマークが人間起因障害を再現しにくいという乖離の根底にある。** - 根拠: [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] — Gray(1986)が Tandem システムでオペレータエラーを最大の障害原因(42%)として同定し、17 年後のインターネットサービスで同じ傾向(Online 33%、Content 36%)を再確認。設定エラーがオペレータエラーの 50% 以上を占める点も両時代で共通 - 根拠: [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] — GenAI クラウドサービスの本番インシデントで設定問題 24.5%・運用操作ミス 12.7% を報告 - **Sillito & Kutomi(2020)が確立したインシデント対応の基礎構造(手動検知の遅延・日和見的調査・支援ツール自体の監視不足)は、LLM 時代の自動化研究が前提とする「自動検知→トリアージ→RCA→緩和」の線形パイプラインモデルと比べてより複雑な実態を示す。** - 根拠: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]] §IV — 2020 年時点のソフトウェアインシデント対応の実態を発生・検知・調査・緩和の 4 フェーズで体系化。(1) 手動検知は常に遅延検知、(2) 汎用的モニタリングは遅行指標、(3) 調査は日和見的と体系的の組み合わせ、(4) 緩和は根本原因修正だけでは完了しない(連鎖した障害状態が残る) - 根拠: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]] §IV-B 観察 7 — モニタリング・通知支援ツール自体が最も監視されていないという観察は、20 件以上のインシデントで支援ツールの欠陥がインシデント対応の全側面に影響したことを記録する(通知 4 時間遅延、バックアップ失敗の未把握等)。AIOpsLab・SREGym・OpenRCA 等のベンチマークは診断精度を評価するが、モニタリングシステム自体の欠陥を評価対象にしない - 関連: [[AlertGuardian]](ライフサイクル最適化)・[[TSGuard]](ユーザ側診断)・[[Bian Que]](積極的点検)が扱う課題は、それぞれ観察 6(しきい値検知の脆弱性)・観察 7(支援ツール自体の監視不足)・観察 5(遅行指標問題)への応答として位置づけられる - **技術的オブザーバビリティと人間のオブザーバビリティは並存する別次元の観測問題であり、AI 支援インシデント管理研究は Detect・Contain に集中し Prepare・Post-incident は著しく過少研究である。** - 根拠: [[@2023__SREcon23Americas__Human Observability of Incident Response]] — [[Matt Davis]] が「インシデント対応中に参加者が互いの状態・意図・注意をどう把握し合うか」という人間のオブザーバビリティを独立した観測問題として提起。Sillito & Kutomi が示した「手動検知の遅延・日和見的調査」は技術的オブザーバビリティ不足として説明されるが、同時に「コンダクターが他の参加者の疲労・注意分散・競合優先事項を把握できていない」という人間のオブザーバビリティ不足の問題でもある - 根拠: [[@2024__arXiv__AI Assistants for Incident Lifecycle in a Microservice Environment - A Systematic Literature Review]] RQ1・RQ4 — [[Dahlia Ziqi Zhou]]・[[Marios Fokaefs]]([[York University]])の SLR は 309 件から選定した 31 件を NIST 4 フェーズで分類し Detect 54.8%・Contain 35.4%・Prepare 9.7%・Post-incident 3.2% という偏りを定量化。31 論文中ユーザースタディ実施は 5 件のみで本番環境実証も不足。非伝統的データソース(過去インシデントレポート・依存グラフ・開発者アクティビティ・コードリポジトリ)は将来機会として特定された - **VOID コーパスの主題分析は、自動化がインシデント管理ライフサイクルの複数段(寄与要因 77%・検知 34%・解決策 20%・妨害要因 14%)に同時に関与し単一の役割に固定できないことを実証し、組織的な IA(インシデント分析)支援の有無が分析結果の活用度・一貫性・データ収集の質を左右するという予備的な相関を示す。** - 根拠: [[@2024__Prowler__VOID Report 2024 - Exploring the Unintended Consequences of Automation in Software]] §III — 189 件中 87% が複数コードにまたがる。「自動化が意図通り機能しない場合、75% で人間の介入が必要であり、その介入は通常より複雑」という結果は [[障害緩和]] における人間-自動化の役割分担を再考する材料になる - 根拠: [[@2024__Prowler__VOID Report 2024 - Exploring the Unintended Consequences of Automation in Software]] §II — 予備調査(58 名・55 組織)は、経営層の明示的支援と専任ロールを持つ「High Support」群が Low Support 群より (1) IA 結果を製品計画へ組み込む (2) 組織横断で一貫した分析を実施する (3) 共通ツール・フォーマットでデータを収集する、の 3 点すべてで高い傾向を示す - 留保: サンプルが小規模(統計的検定不可)で自己申告に基づく予備調査であり、著者自身が「今年実施中の本調査で検証する」と明言している ## GenAI・AI ワークロード時代のインシデント特性とベンチマーク乖離 - **AIOps エージェント評価が想定するインシデント像と本番インシデントの根本原因分布は乖離しており、学術ベンチマークは本番インシデントの半分以上をカバーできない可能性がある。** - 根拠: [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] — 本番インシデントの根本原因分布は設定問題 24.5%・外部利用 14.1%・運用操作ミス 12.7% を含み、障害注入で再現しにくい種別が過半を占める - 反証: [[AIOpsLab]] や [[SREGym]] は障害注入([[ChaosMesh]]/eBPF)によるインシデントを評価対象にし、Infrastructure Issue(27.2%)やコードバグ(21.5%)を対象にする - 根拠: [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] - **インシデントタイムライン(Slack スレッド)は専門家アノテーションの一次源として AI 評価に直接転用され始め、人間の運用記録を AI 研究の一次データに昇格させる流れを示す。** - 根拠: [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]] — [[Datadog]] エンジニアの Slack インシデントタイムライン(障害検知から緩和までの議論スレッド)を、専門家の推論(問う質問・調べる証拠・導く結論)のリアルタイム記録とみなし、時系列質問応答([[時系列質問応答]])ベンチマークの正解ラベルの一次証拠に転用する。ICSE 研究が OCE の事後インシデント報告を分析対象にしたのと同型の流れ - 根拠: [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] — ARFBench は ICSE 研究と同じインシデント対応の段階構造(報告→診断→トリアージ→緩和→復旧→RCA→postmortem)を引きつつ、TSQA がトリアージ・緩和・RCA に効くと位置づける(Appendix A.2) - **workflow artefacts(runbook・チケット・postmortem)は「知識ベース」かつ「攻撃面」という二面性を持ち、信頼階層と独立検証の規律で初めて両立する。** - 根拠: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]] §II-D, §VI-E — 同じ artefacts を「知識ベースであると同時に攻撃面」として扱い、untrusted な成果物(自由形式チャット・外部文書・ユーザー影響下のログ文字列)は独立チェックなしに特権行動を駆動してはならないと規律づける。runbook は古び・postmortem は機微情報を省き・チケットは曖昧/敵対的なテキストを含みうる系統的バイアス源とし、authoritative/advisory/untrusted の信頼階層(表I)で扱うことを求める - 関連: インシデント記録を AI の燃料にする流れ(ARFBench)と、それを攻撃面として警戒する流れは、信頼階層と独立検証の規律で初めて両立する([[エージェント運用安全性]] に詳述) - **AI ワークロード基盤(GPU クラスタ訓練・推論)の運用インシデントは、GPU 偏重・recurrence 高という点で従来クラウドワークロードと質的に異なる障害分布を示す。** - 根拠: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] Figure 2 — GPU 52.47%・System Software 27.79%・Networking 8.18%・User 8.83%(1 年・778 件)。従来クラウドワークロード([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 ワークロード固有データセットを取り込むべき定量的根拠となる - **症状-原因の多対多マッピング問題は AI ワークロードで特に深刻であり、能動検証(hypothesis-iteration+verification)が one-shot RCA を上回る。** - 根拠: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] §2.1 — CUDA "invalid device ordinal"+NVIDIA Xid 119 という同一症状の真の原因が「GPU 故障」でなく「CUDA ドライババージョン不一致」だった事例。RCACopilot や DID-o1 のような one-shot RCA は症状と原因のセマンティック近傍検索に依存するためこの多対多関係で誤解する - 根拠: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] — Pipeline #2 のタクソノミー誘導 DFS(hypothesis→検証スクリプト実行→結果反省→再仮説)により Macro F1=0.816(RCACopilot: 0.380、+43.6%) - 関連: [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]] の MAS 設計と同じく「能動検証+反復」が one-shot を超える構図が GenAI 上層と AI ワークロード下層で並行して確認された - 根拠: [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] Figure 7 — GenAI クラウドの症状-原因多対多マッピングも報告 ## 未解決の問い - BSRS ch.16 が示す専任/兼任/外部委託の3人員配置モデルの選択は、組織規模・インシデント頻度・予算のどの要因が支配的に効くか。また、この選択が Maguire (2020) の「ICS モデルは本番の複雑さを捉えきれない」という批判にどこまで実証的に応えられるかは、両資料を横断する事例研究がなければ検証できない。 - Google が公式に明文化する「インシデント管理は 3 日以内」という組織ポリシーは、TTM 研究群で報告される実測 TTM の分布(平均・中央値・裾)のどのあたりに位置するか。3 日という上限は緩和自体の目標時間なのか、それとも「インシデントとして扱う」対応モード全体の上限なのか、本書の記述だけでは境界が明確でない。 - 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 は、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)のインシデント検知・診断・緩和は、LLM 期の論文ではほとんど扱われていない。これは「Business 層は人間の判断が必要で AI 化が遠い」のか、「Business KPI モニタリングは別領域(BI/A&O)として AIOps の射程外」なのか、それとも文献選定のバイアスか。([[@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 レイヤーの自動セキュリティ更新のような「サービスオーナーが直接コントロールしない変更」を事前に検知・リスク評価する仕組み(依存関係グラフ・変更影響予測)は、変更起因インシデント研究の対象に含まれているか、それとも既存研究の対象外(アプリケーションデプロイに限定)か。 - [[@2022__OReilly__Anatomy of an Incident - Chapter 1 Introduction]] の 3 条件定義(エスカレーション・即時対応・組織的対応)は定性的な基準にとどまり、「誰が・どの時点で・どう判定するか」という運用上の意思決定プロセスは第 1 章では明示されない。後続章(Response・Scaling Incident Management 等)でこの判定プロセスがどこまで具体化されるか、また 3 条件のいずれかを満たすが残りを満たさない境界事例(例: 組織的対応は要るが即時性は低い)をどう扱うかは未確認。 - VOID Report 2024 の「High/Low Support」相関は自己申告・小規模サンプルに基づく予備調査であり、著者自身が「今年実施中の本調査で検証する」と明言している。本調査の結果は wiki に未取り込みであり、相関が統計的に有意か、交絡因子(組織規模・業種)を制御してもなお成立するかは今後の課題。 - 自動化アーキタイプ(Sentinel/Gremlin/Meddler/Unreliable Narrator/Spectator/Action Item)は VOID Report 2024 が rule-based automation を主対象に導出した分類だが、LLM エージェントによる自動化(agentic SRE)にも同じ分類がそのまま当てはまるか、それとも新しいアーキタイプ(例: 説明は流暢だが誤った Unreliable Narrator の強化版)が必要か。 - Grayson (2018)・Woods (2017) が指摘する「ICS モデルは実際のエンジニアリングチームのインシデント対応を単純化しすぎている」という批判の具体的な論拠は何か。両論文は未取り込みであり、単純化の対象が役割分担そのものなのか、役割間の情報伝達様式なのか、あるいは時間圧力下での意思決定プロセスなのかが特定できていない。この論拠が判明すれば、SRE Book の ICS 処方(IC/Ops/Comms/Planning の 4 役割)のどの部分が本番のライブインシデント対応で機能不全を起こしやすいかを特定できる可能性がある。 - Maguire(2020)第 3 章は、CDI(クリティカルデジタルインフラ)領域で協調を管理しようとする試み(ICS 輸入・SLA/SLO・ChatOps 等のツール類)を列挙するが、これらの試みが実際にどう機能不全を起こすかの事例分析は同論文の第 5・6 章(Findings・Discussion)に委ねられている。第 5・6 章は未取り込みであり、ICS 批判を具体的な事例(役割の競合・情報の断絶・時間圧力下の誤判断等)で裏づけられるかは今後の章別 ingest 待ちとなる。 ## 未編纂の観察 > [!note]- 編纂前の観察 2026-09 > - **組織的な IA(インシデント分析)支援の有無が、分析結果の活用度・実施の一貫性・データ収集の質を左右するという予備的だが一貫した相関が観測された**: VOID Report 2024 の予備調査(58 名・55 組織)は、経営層の明示的支援と専任ロールを持つ「High Support」群が、Low Support 群に比べて (1) IA 結果を製品計画へ組み込む、(2) 組織横断で一貫した分析を実施する、(3) 共通ツール・フォーマットでデータを収集する、という 3 点すべてで高い傾向を示したと報告する。サンプルが小規模(統計的検定不可)で自己申告に基づく点は限界だが、本 wiki の他ソースが扱う「自動化されたインシデント処理パイプライン」の観点とは異なり、**組織構造そのものが IA の質を左右する**という補完的な軸を示す。(Source: [[@2024__Prowler__VOID Report 2024 - Exploring the Unintended Consequences of Automation in Software]]) > - **自動化はインシデント管理ライフサイクルの複数段に同時に関与し、単一の役割に固定できない**: VOID コーパス 189 件の主題分析では、自動化が寄与要因(77%)・検知(34%)・解決策(20%)・妨害要因(14%)のいずれの役割も演じうることが確認され、189 件中 87% が複数コードにまたがった。これは、本 wiki が「検知→トリアージ→診断→緩和」と縦に切ってきたライフサイクルの各段に、自動化が善玉にも悪玉にもなりうる形で同時に絡むことを実証データで裏付ける。特に「自動化が意図通り機能しない場合、75% で人間の介入が必要であり、その介入は通常より複雑」という結果は、[[障害緩和]] における人間-自動化の役割分担を再考する材料になる。(Source: [[@2024__Prowler__VOID Report 2024 - Exploring the Unintended Consequences of Automation in Software]]) > - **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) > > - **MagmaScope は緊急インシデント(emergency incident)という重篤度の高いサブセットに絞り込み、IM グループチャットを根本原因変更特定の一次コンテキスト源として活用する——インシデント管理ライフサイクルにおいて「インシデント対応中の人間のチャットストリーム」が診断品質に直接影響する実証例を提供する**: [[MagmaScope]]([[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]], ICSE-SEIP '26)は、[[ByteDance]] の緊急インシデント対応プラットフォーム上で 1 年超稼働し、10 以上のビジネスグループに展開された本番システムである。IM グループチャット(Figure 1)は、インシデント発生時にオンコールエンジニア・変更オーナー・サービスオーナーが集まって症状・仮説・確認結果をリアルタイムで共有する場であり、MagmaScope はそのチャット内容を細粒度の LLM エージェント推論の文脈入力として利用する。ARFBench([[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]])が Slack タイムラインを TSQA の評価データとして活用するのと同型の観察——「インシデント中の人間のコミュニケーションが後処理によって AI 診断の有用な一次情報になる」——を、MagmaScope は本番システムとして実装している。Figure 5 が示すようにチャット進行とともに精度がジャンプすることは、IM ライフサイクルの「診断段階」で人間の推論が蓄積することが機械的な根本原因変更特定を改善させるというフィードバック構造を実証する。(Source: [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] §4.3, Figure 5) > > - **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]]) > > - **Google 実務者による 3 条件定義(エスカレーション・即時対応・組織的対応)は、本 wiki が定量化してきた「誤分類コスト」を事前に防ぐための運用規範と読める**: [[@2022__OReilly__Anatomy of an Incident - Chapter 1 Introduction]] は Google のインシデント判定基準を「(1) エスカレーションされる、(2) 即時対応を要する、(3) 組織的対応を要する」の 3 条件で定式化し、ITIL のような広い incident 定義とは意図的に区別する。これは [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] が実証した「宣言されたインシデントの平均 50.32% が incidental(対処不要)」という現実と対照的に読める——本書が掲げる狭い 3 条件は、まさに Microsoft データが示す誤分類コスト(TTR の 55.05% が incidental 処理に消費)を事前に抑制するための境界設定だと解釈できる。また「インシデント件数そのものを測定対象にすると宣言をためらう心理が働き遅延宣言を招く」という本書の指摘は、[[@2025__SREcon25Americas__Incident Management Metrics that Matter]] の「MTTR・インシデント件数は逆インセンティブを持つ」という後年の批判と、狭義の定義とメトリクス選択という異なる角度から同じ結論(件数を KPI 化しない)に至っている。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 1 Introduction]], [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]], [[@2025__SREcon25Americas__Incident Management Metrics that Matter]]) > > - **本書の 3 段階ライフサイクル(Preparedness→Response→Mitigation and Recovery)は、TTX の 4 段階(検知→特定→緩和)より粗い粒度で「組織の反復学習サイクル」を描く**: [[@2022__OReilly__Anatomy of an Incident - Chapter 1 Introduction]] は「復旧が終わると再び準備段階に戻る」円環としてインシデント管理ライフサイクルを提示する。これは [[クラウド障害ライフサイクル]] が定式化する TTD/TTI/TTM/TTR という単一インシデントの時間分解モデル([[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]])とは軸が異なる——TTX モデルが「1 件のインシデントが発生してから解決するまでの時間」を縦に切るのに対し、本書のライフサイクルは「準備投資が対応品質を決め、復旧後の学習が次の準備につながる」という**インシデントをまたいだ組織の反復サイクル**を横に描く。両者を重ねると、TTX の各段階(検知・特定・緩和)は本書の Response フェーズと Mitigation and Recovery フェーズの内部に位置づけられ、TTX モデルには対応する概念がない Preparedness フェーズ(コードレビュー・ロールアウトプロセス・トレーニング・モニタリング整備)が、複数インシデントを通じた TTX 改善の前提条件として機能すると解釈できる。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 1 Introduction]], [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) > > - **メトリクス⊆アラート⊆インシデントという包含関係は成立しない、という Google 実務者の明示は Yu+ JNCA2024 の alert/incident 分離設計を実務側から裏付ける**: 本書 ch.1 は「すべてのメトリクスがアラートになるわけではなく、すべてのアラートがインシデントになるわけでもない。逆に、アラートなしにインシデントが起きることもある(例: セキュリティチームからの侵害の疑いの報告)」と明示する。これは [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]] が「event ⊃ alert、severe alert + user complaint → incident」という関係で alert management と incident management を別ライフサイクルとして分離した設計の実務的根拠を与える——本書は学術サーベイに先立つ 2022 年の実務者向けレポートとして、この分離が単なる分類上の便宜ではなく「アラートを介さないインシデント」が実在するという運用上の事実に基づくことを示す。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 1 Introduction]], [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]]) > > - **外部ユーザー優先というインシデント対応外の運用方針が、インシデント対応そのものを自己阻害しうる**: [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]] が報告する Google の "Mayan Apocalypse"(2019年6月2日)は、ネットワーク自動化ツール Maya の誤フラグが計画メンテナンス中のジョブスケジューリングと衝突しカスケード障害へ発展した事例だが、Google の「社内トラフィックよりユーザートラフィックを優先する」通常方針(0.1% のインシデント対応者は通常このスロットルを回避できる)がカスケード時には社内ツール自体を巻き添えにし、アラート配信を阻害して大量のページを一斉発報させた。インシデントコマンダーは対応専用のアクセス機構でこのフラグを覆すことで初めて社内トラフィックの余地を確保できた。[[@2023__SREcon23EMEA__The World Blew Up but We're All Okay - How We Managed a Massive-scale Incident at Datadog]] が報告する「共通 OS ディストリビューションが事実上のグローバル障害波及経路になる」構造と同様、**平常時に合理的な設計判断が、大規模障害時には対応能力そのものを削る二次的な障害波及経路になりうる**という論点を、独立した実例が補強する。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]], [[@2023__SREcon23EMEA__The World Blew Up but We're All Okay - How We Managed a Massive-scale Incident at Datadog]]) > - **応答者の増員は緩和を自動的には加速しない——system-of-systems 障害では並列化が効かない**: Mayan Apocalypse の事例では、40人超のオンコーラーが参加してもそれぞれが自分のシステムスタックの専門家であるにとどまり、全システム横断の見通しを持つ者はいなかったため、根本原因と二次的影響が絡み合い並列化が緩和を加速しなかった。この状態はエスカレーションによって Tech IRT のインシデントコマンダーがコミュニケーションと役割分担に構造を与えて初めて解消した。これは [[@2026__SREcon26 Americas__So You Want a New Incident Commander]] の「IC は条件を整えるリーダーシップスキル」という定義や、[[@2023__SREcon23EMEA__The World Blew Up but We're All Okay - How We Managed a Massive-scale Incident at Datadog]] が示す「大規模インシデントでも IC ローテーション+ワークストリーム自己組織化という最小骨格が機能する」実例と同じ構造で、**人数の増加ではなく調整構造の付与こそが大規模 SoS 障害での緩和加速の要因である**という知見を、書籍事例が改めて裏付ける。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]], [[@2026__SREcon26 Americas__So You Want a New Incident Commander]]) > > - **「インシデント管理は 3 日以内」という Google の組織ポリシー上の上限は、本 concept が集約する定量的 TTM 研究群とは異なる時間の粒度で「インシデント管理の時間」を扱う**: [[@2022__OReilly__Anatomy of an Incident - Chapter 3 Scaling Incident Management (Response)]] は、インシデント特定から解決までの時間は 3 日を超えるべきではないと明文化し、根本原因・トリガー条件の恒久対応(数か月〜数年かかりうる)は緩和後の別プロセスへ切り離すべきだと主張する。これは TTMPred([[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]])や ISSRE の変更起因インシデント研究([[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]])が扱う分〜時間単位の実測 TTM 分布とはオーダーが異なり、両者を並べると「インシデント管理の時間」が実務ポリシー上の上限(日単位、いつ緩和を諦めて長期対応へ切り替えるかの判断基準)と、研究対象としての実測値(分〜時間単位、緩和自体にかかる時間)という異なる階層で扱われていることが見える。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 3 Scaling Incident Management (Response)]], [[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]]) > > - **コンポーネント応答者→SoS 応答者という二層構造は、Mayan Apocalypse 事例(ch.6)が示す「並列化が効かない」問題に対する Google の事前設計上の解と読める**: 本書 ch.3 は、技術スタックが 1 人の理解を超えて拡大すると複数の応答者が単一コンポーネントを分担するようになり、複数コンポーネントにまたがる問題への無知というリスクが生じると述べ、これに対処するために SoS 応答者(プロダクト特化 IRT・Tech IRT)という二次応答者の階層を構築したと説明する。これは同じ書籍内の ch.6 が報告する Mayan Apocalypse 事例——40 人超のオンコーラーが集まってもシステム横断の見通しを持つ者がおらず、Tech IRT のインシデントコマンダーによる構造化で初めて解消した——の一般化された設計原理にあたる。ch.3 は「なぜこの階層が必要か」という設計思想を、ch.6 は「階層がない/機能する前の実例」を提供しており、同一書籍内の章でも設計原理(規範)と実例(記述)が相補的に補強し合う関係にある。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 3 Scaling Incident Management (Response)]], [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]]) > > - **「ヒーロイズムは有害」という本書の結論規範は、SRE Book のフリーランシング批判と Mayan Apocalypse の実例の両方によって独立に裏づけられる**: [[@2022__OReilly__Anatomy of an Incident - Chapter 7 Conclusion and Moving Forward]] は結論として「少数のヒーローが劇的に火消しをするという想像は魅力的だが有害な考え方(a heroism mindset is harmful)」であり、インシデント管理が上手いとは個人ではなくチーム全体が準備・対応・緩和と復旧のサイクルを地道に改善し続けることだと明言する。この規範は 2 つの独立した経験的裏づけと符合する。1 つは [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] が非管理型インシデントの最大の悪化要因として特定する「善意に基づく独断行動(フリーランシング)」——ヒーロイズムが実際に事態を悪化させるという一般則。もう 1 つは同じ書籍内の ch.6 が報告する Mayan Apocalypse 事例で、対象コンポーネントの経験を持たない Tech IRT メンバーがインシデントコマンダーとして機能したのは、技術的な英雄的介入によってではなく、コミュニケーションと役割分担に構造を与えたことによってだった。規範(ch.7)・一般則(SRE Book)・実例(ch.6)の 3 点が、独立した文脈で同じ「個人の英雄的行動より構造化された協調が有効」という結論に収束する。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 7 Conclusion and Moving Forward]], [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]], [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]]) > > - **FEMA/ICS 由来の 4 役割は SRE と ML で同一だが、『信頼性の高い機械学習』は「何が ML で変わるか」を明示的に 3 軸へ切り出す点で SRE Book と補完的**: 本ページが集約する SRE Book Ch14 は、インシデントコマンダー・オペレーション・コミュニケーション・プランニングという ICS(Incident Command System)の 4 役を、フリーランシング(独断行動)の抑制という一般的な文脈で処方する。[[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 11 障害対応]] §11.1.2 はほぼ同一の 4 役割(障害指揮官・コミュニケーションリーダー・オペレーションリーダー・計画リーダー)を FEMA の National Incident Management System から引き、「これらの役割は ML 障害であろうとなかろうと変わらない」と明言したうえで、検出のしやすさ・関与する役割とシステムの広さ・タイムラインの明確さの 3 点が ML で変化すると特定する。同じ役割設計が ML/非 ML で不変であることを独立した 2 ソース(SRE Book・本書)が確認しつつ、11 章はその上で変化点を明示的に切り出すという点で、本ページが蓄積してきた ICS 起点の知見に「ML という 1 ドメインでの役割設計の頑健性の実証」を加える。詳細は [[ML障害管理の原則]] に集約する。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 11 障害対応]] §11.1.2, [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]]) > > - **「合計顧客影響時間(TTR×影響顧客数)」という2011年の実務指標は、本ページが集約する「MTTRは単体で機能しない」批判の系譜に、10年以上先行する早期の解決策を提供する**: [[Jake Loomis]]([[Yahoo!]]、[[@2011__OReillyJapan__ウェブオペレーション - Chapter 13 障害を活用する：ふりかえりの技芸と科学]])は、「TTR(Time to Resolve)の短縮は問題数削減と同じくらい重要」としつつ、TTR 単体でなく「合計顧客影響時間(TTR×影響を受けた顧客数)」で計測すべきだと2011年時点で述べている。本ページが集約する [[Jamie Luck]]・[[Laura de Vesine]] の2025年の指摘(「MTTRは低頻度・高分散イベントでノイズ優位であり、単体の平均値としてKPI化すべきでない」、[[@2025__SREcon25Americas__Incident Management Metrics that Matter]])や [[Narimichi Takamura]] のモンテカルロ実証(改善が MTTR に反映されるのは49〜64%のケースのみ)は、いずれも「生の解決時間だけでは組織の意思決定の根拠にならない」という同じ問題意識に基づくが、Loomis の解は「顧客影響で重み付けする」という単純な次元追加にとどまり、分散・ノイズという統計的性質そのものには触れていない。10年以上を隔てた2つの時代が同じ問題(「TTR/MTTRだけでは測れない」)に到達しつつ、解決の精緻さ(重み付け vs. 統計的再定義)が大きく異なる点が対照的である。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 13 障害を活用する：ふりかえりの技芸と科学]], [[@2025__SREcon25Americas__Incident Management Metrics that Matter]]) > > - **8章(2011)のコミュニティマネージャは、ICS の「コミュニケーション担当」ロールが体系化される5年前に、ユーザ向け情報発信という下位機能を専任職として実務運用していた**: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] は ICS(Incident Command System)の 4 役割の一つとして「コミュニケーション担当(利害関係者への情報発信)」を処方するが、この役割が組織内の利害関係者向け発信とユーザ(社外)向け発信のどちらを主に想定しているかは明示しない。[[@2011__OReillyJapan__ウェブオペレーション - Chapter 8 コミュニティ管理とウェブオペレーション]] が描く Flickr の実務は、この5年前の時点ですでに、ユーザコミュニティ向け発信だけを専任するコミュニティマネージャという職種を置き、「詳細より先に問題を認知している事実を伝える」「事前確立したインシデントチームへ問い合わせを一本化し経営層の個別対応を防ぐ」という具体的な運用ルールを実践していた。ICS が抽象的な役割として一括する「コミュニケーション担当」の内部に、少なくとも「ユーザ向け」と「組織内・経営層向け」という異なる対象への発信が分岐しうることを、8 章の具体例は示唆する。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 8 コミュニティ管理とウェブオペレーション]], [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]]) > > - **3段階の重要度分類(顧客影響の大きい機能停止/デグレード・回避困難な機能障害/顧客影響の小さい問題)は、本ページが集約する「severityとincidentalの逆転」問題の前提となる早期の実務的枠組みである**: Loomis は重要度1〜3を「潜在的な顧客影響の大きさ」で定義し、改善・トリアージの判断に用いるとする(2011年)。この設計思想は、本ページが集約する [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] が実証する「最高 severity 0 ですら incidental(対処不要)が 57.96% を占め essential を上回る」という逆転現象の前提条件そのものである——Microsoft の severity 割当も Loomis が示す「潜在影響の大きさ」という同じ設計原理に基づいており、2020年の実証データは、2011年から標準化されてきたこの種の重要度設計が抱える構造的な誤分類リスクを、約10年後に定量的に裏づけたと読める。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 13 障害を活用する：ふりかえりの技芸と科学]], [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]]) > > > [!contradiction] ICS 由来のインシデント管理モデルの妥当性 > > 本ページはこれまで [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] の ICS(Incident Command System)由来の 4 役割(インシデントコマンダー/オペレーション/コミュニケーション/プランニング)を、Ch33 が挙げる業界横断の非難なき振り返り事例(航空 CHIRP・医療・製造業 CAPA)と併せて、フリーランシング(独断行動)抑制に有効な枠組みとして肯定的に集約してきた。これに対し [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 3 The domain of Critical Digital Infrastructure]] は、ソフトウェア工学領域が ICS を輸入する試み——本ページが繰り返し参照してきた SRE Book(Beyer, Jones, Petoff and Murphy, 2016)そのもの——を名指しし、「エンジニアリングチームが実際にどうインシデントに対応しているかを詳細に調べた研究は、このモデルが単純化しすぎている(an oversimplification)ことを示唆している」(Grayson, 2018; Woods, 2017 を引用)と述べる。著者はさらに「専門的な信頼性エンジニアが本番システムをトラブルシューティングする様子の記述的分析は、サービス停止時に直面する複雑さ・圧力・不確実性の全体を捉えきれておらず、これが協調を管理しようとする試みがパフォーマンスを支援するどころか制約してしまうことがある理由の一端である」と踏み込む。両者は同じ SRE Book の ICS 処方を参照しながら、一方(本ページがこれまで集約してきた文脈)は役割分離の設計原理としての有効性を産業横断比較やマルチエージェント SRE 設計との構造対応で裏づけ、他方(Maguire 2020)はその設計原理が本番のライブインシデント対応の認知的複雑さを記述するには不十分だと批判する。Grayson (2018)・Woods (2017) の一次研究は本 wiki に未取り込みであり、批判の具体的な論拠(何が・なぜ単純化されているのか)は現時点で検証できていない。(Source: [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 3 The domain of Critical Digital Infrastructure]], [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]]) > > - **BSRS ch.16 の3人員配置モデル(専任/兼任/外部委託)は、ICS 由来の役割分離モデルへの「単純化しすぎ」批判(Maguire 2020)に対し、役割設計とは独立な「誰がその役割を担うか」という運用レイヤーの選択肢を提示する**: 本ページが既に集約する ICS 由来 4 役割批判([[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 3 The domain of Critical Digital Infrastructure]])は、役割分離という設計そのものの認知的妥当性を問題にする。これに対し BSRS 16章は「役割は決まっているが、それを専任フルタイムチームが担うか、既存社員が兼任(two hats)するか、外部委託するか」という、役割設計より一段下の人員配置レイヤーの選択肢を提示し、さらに「これはロール(role)であって個人(individual)ではなく、1人が複数ロールを兼ね、シフト制で回してもよい」と明記する。この人員配置レイヤーの柔軟性は、Maguire が批判する「本番のライブインシデント対応の複雑さを役割固定モデルが捉えきれない」という問題を、役割の再設計ではなく人員のシフト制運用・複数ロール兼任という別の緩和策で部分的に吸収しようとする、独立した対処軸として読める。また「エグゼクティブの代理人を各タイムゾーンに置く」という単一障害点回避の指針は、[[@2011__OReillyJapan__ウェブオペレーション - Chapter 8 コミュニティ管理とウェブオペレーション]] が示す「事前確立インシデントチーム」というオンコール以前の実務知見を、地理的冗長性という次元で拡張したものにあたる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] §Setting Up an Incident Response Team, §Identify Team Members and Roles, [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 3 The domain of Critical Digital Infrastructure]]) ## 関連 - ソース: [[@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]] / [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]] / [[@2022__OReilly__Anatomy of an Incident - Chapter 7 Conclusion and Moving Forward]] / [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 3 The domain of Critical Digital Infrastructure]] / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] - 概念: [[災害計画]] / [[コミュニティマネジメント]](ユーザ向け情報発信という ICS「コミュニケーション担当」の下位機能を専任職として先行実務化) / [[インシデントトリアージ]](本ソースが導入した工程別概念)/ [[AIOps]](4-level taxonomy)/ [[根本原因分析]](RCA、ライフサイクル第 3 段)/ [[障害緩和]](ライフサイクル第 4 段) / [[TSG自動化]] / [[時系列質問応答]] / [[SRE Benchmark]] / [[エージェント運用安全性]] / [[NetOps]] / [[変更起因インシデント]] / [[クラウドモニタリング]] / [[インシデント優先順位付け]] / [[LLM分散学習]] / [[耐障害LLM訓練]] / [[TTXメトリクス]] / [[アンインシデント]](宣言されない潜在インシデント・Gray Zone) / [[インシデント認識論]](5フェーズ・証拠2×2・探索パターン・仮説/テスト基準) / [[グレースフルデグレーデーション]](部分障害時の継続設計) / [[ポストモーテム]] / [[クリティカルデジタルインフラ]](ICS 輸入批判の一次出典が定義する研究対象領域) / [[ChatOps]] - エンティティ: [[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]] / [[Google]] / [[Ben Treynor Sloss]] / [[Courtney Nash]] / [[Prowler]] / [[Jake Loomis]] / [[Yahoo!]] / [[Laura Maguire]] - 関連 MOC: [[AIOps - Failure Detection - MOC]] / [[LLM4SRE - MOC]] / [[SRE - MOC]] ## 出典 - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 8 コミュニティ管理とウェブオペレーション]] — ヘザー・チャンプ, 聞き手 ジョン・オルスポー, John Allspaw・Jesse Robbins 編, 角 征典 訳, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, 8章(コミュニティマネージャによるユーザ向け障害コミュニケーション、事前確立インシデントチーム) - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 13 障害を活用する：ふりかえりの技芸と科学]] — ジェイク・ルーミス, 「障害を活用する：ふりかえりの技芸と科学」, John Allspaw・Jesse Robbins 編, 角 征典 訳, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, 13章(§13.2: TTR・合計顧客影響時間・重要度分類) - [[@2022__OReilly__Anatomy of an Incident - Chapter 1 Introduction]]（Google 実務者による 3 条件インシデント定義、メトリクス/アラート/インシデントの非包含関係、3 段階インシデント管理ライフサイクル、Figure 1-1） - [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]]（Google の実インシデント "Mayan Apocalypse"(2019-06-02) の全経過。外部優先方針の自己阻害・40人超参加でも並列化が緩和を加速しない構造・Tech IRT エスカレーション・IC による社内トラフィック解放） - [[@2022__OReilly__Anatomy of an Incident - Chapter 7 Conclusion and Moving Forward]]（結論章。インシデント管理を適切な場面に限って使うべきという行動喚起、ヒーロイズムの精神は有害という規範、非難のなさが心理的安全性を育むという主張） - [[@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__Prowler__VOID Report 2024 - Exploring the Unintended Consequences of Automation in Software]]（§II 予備調査の High/Low Support 比較、§III 189 件主題分析の定量結果） - [[@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 ボーナスコミュニケーションスキル） - [[@2020__PhD__Controlling the Costs of Coordination in Large-scale Distributed Software Systems - Chapter 3 The domain of Critical Digital Infrastructure]]（Service outages 節・Tooling to manage incident response 節・Attempts to manage coordination for incident response 節。ICS 輸入への批判、ChatOps の透明性と協調コスト） - [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]]（IRチームの3人員配置モデル・チームチャーター・severity/priority 2軸モデル・運用パラメータ）