# X-lifecycle Learning for Cloud Incident Management using LLMs > [!abstract] 概要（arXiv abstract 日本語訳） > クラウドサービスの大規模インシデント管理は複雑かつ労力を要するプロセスであり、オンコールエンジニア（OCE）による多大な手作業を必要とする。OCE は通常、ソフトウェア開発ライフサイクル（SDLC）の異なる段階からのデータ（コード・設定・モニタデータ・サービス属性・サービス依存関係・トラブルシューティングドキュメントなど）を活用して、インシデントの検知・根本原因分析・緩和に向けた洞察を生成する。大規模言語モデル（LLM）（ChatGPT・GPT-4・Gemini 等）の最近の進展は、OCE を支援してクリティカルな問題を迅速に特定・緩和する文脈的推薦を自動生成する機会を生み出した。しかし既存研究は、SDLC の単一段階のデータを活用してインシデント管理の特定タスクを解くという孤立した視点（siloed view）にとどまっている。本論文では、SDLC の異なる段階からの追加文脈データを補完することで、実践的に重要かつ困難な 2 つのタスクの性能が向上することを示す。（1）依存サービス障害に起因するインシデントの根本原因推薦の自動生成、（2）インシデントを自動検知するために使用されるサービスモニタのオントロジー識別。Microsoft からの 353 件のインシデントと 260 件のモニタのデータセットを活用することで、SDLC の異なる段階からの文脈情報を補完することが最先端手法に対する性能改善をもたらすことを実証する。 ## 論文情報 - **タイトル**: X-lifecycle Learning for Cloud Incident Management using LLMs - **著者**: Drishti Goel・Fiza Husain・Aditya Singh・Supriyo Ghosh・Anjaly Parayil・Chetan Bansal・Xuchao Zhang・Saravan Rajmohan（全員 Microsoft） - **連絡先**: t-drgoel, t-fizahusain, t-aditysingh, supriyoghosh, aparayil, chetanb, xuchaozhang, saravan.rajmohan @microsoft.com - **媒体**: ESEC/FSE 2024 Companion Proceedings（ACM FSE '24 Companion） - **DOI**: 10.1145/3663529.3663861 - **arXiv**: 2404.03662（投稿: 2024-02-15） - **データ**: Microsoft IC3 サービス（Teams バックエンド、2.5 億ユーザー超）の 353 インシデント（2023-01〜2024-01）+ 260 モニタ ## 概要 本論文は LLM によるインシデント管理自動化において、既存研究が「単一 SDLC 段階のデータ」だけを使う孤立視点の限界を指摘し、**X-lifecycle データ**（サービスアーキテクチャ・依存関係・機能説明など複数ライフサイクル段階の情報）を LLM プロンプトに補完する手法を提案する。依存サービス障害の根本原因推薦とモニタ分類という 2 タスクで効果を実証した。 ## 問題設定 ### 背景: SDLC サイロの問題 クラウドインシデント管理の 4 段階（検知→トリアージ→根本原因分析→緩和）において、OCE は実際にはコード・設定・モニタデータ・サービス依存関係・TSG 等、SDLC 全体に散在する情報を横断的に参照する。しかし既存の LLM ベース RCA 研究（Ahmed+ [3]、Zhang+ [52]）はインシデントメタデータ（タイトル・概要・サービス名）のみに依存し、その他のライフサイクル情報を無視している。 ### タスク 1: 依存サービス障害インシデントの RCA 依存サービス障害（partner service からの障害伝播）が原因のインシデントでは、上流サービスの依存関係とその機能説明を考慮しなければ正確な根本原因を特定できない。入力: インシデントタイトル・概要・所有サービス名 + 上流依存サービス情報。出力: 根本原因の自然言語推薦文 + 依存サービス障害か否かの 2 値分類。 ### タスク 2: モニタのオントロジー識別（モニタ分類） クラウドサービスの監視は構造化されておらず、何を（リソースクラス）・どのメトリクスで（SLO クラス）監視しているかがモニタメタデータからは不明瞭。入力: モニタ名・メトリクス名・アラートタイトル等のモニタメタデータ + サービス説明・コンポーネント説明。出力: 13 リソースクラス / 9 SLO クラスの分類ラベル。 **Figure 1: Incident management lifecycle** ![[_attachments/arxiv-2404.03662/fig01-incident-lifecycle.png]] (Figure 1. インシデント管理のライフサイクル。大規模クラウドシステムから検知されたインシデントが IcM システムに報告され、OCE がトリアージ・根本原因分析・緩和を行う。左側のコード・設定・サービス依存関係や、右上の TSG・サービス情報が OCE の判断材料となる。Source: Adapted from Fig.1.) ## 提案手法 ### X-lifecycle データの構成 X-lifecycle データとは、SDLC の各段階に存在するが従来孤立して管理されていた情報群: - **上流サービス依存関係**: 依存性追跡システム（DTS）から取得した UpstreamServiceIds と、各サービスのプロパティ・機能説明 - **サービスアーキテクチャ情報**: サービスとそのコンポーネント（サブサービス）の機能説明 - **インシデントコーパス**: 過去インシデントのタイトル・概要・根本原因（RAG のベクターデータベースとして格納） ### RCA パイプライン（タスク 1） 1. **データ収集**: IC3 サービスの 353 件の解決済みインシデント + DTS から上流サービスの UpstreamServiceIds を取得 → 各サービスのプロパティ・機能説明データベースを参照 2. **データクリーニング**: HTML タグ・スタックトレース・テーブル・画像を除去（トークン数削減とノイズ除去） 3. **要約**: GPT-3.5-turbo で根本原因・概要・冗長なサービス説明を圧縮（図4のプロンプト参照） 4. **類似例検索**: FAISS ライブラリで上位 5 件の類似インシデントを取得（Zhang+ [52] に準拠） 5. **GPT-4 推論**: タスク説明 + インコンテキスト例 + 回答形式 + インシデント詳細 + 上流サービス情報を組み合わせたプロンプト（図5）で GPT-4（温度 0）に照会 **5 手法の比較**: | 手法 | 説明 | |---|---| | **InC DEP**（提案）| インシデント情報 + インコンテキスト例 5 件 + 上流依存サービス説明 | | NoDEP | インシデント情報のみ（ゼロショット） | | DEP | インシデント情報 + 依存サービス説明（例なし） | | InC NoDEP | インシデント情報 + インコンテキスト例 5 件（Zhang+ [52]） | | FtGPT | GPT-3 をインシデントデータでファインチューニング（Ahmed+ [3]） | ### モニタ分類パイプライン（タスク 2） 4 つのケースでモニタメタデータに追加する情報の影響を比較: | ケース | 入力 | |---|---| | C1（ベースライン）| モニタメタデータのみ | | C2 | モニタメタデータ + サービス説明 | | C3 | モニタメタデータ + サービス説明 + コンポーネント説明 | | C4 | モニタメタデータ + コンポーネント説明のみ | GPT-4 に段階的な質問（Q1: 監視対象エンティティの特定 → Q2: リソースクラスへの分類）を行う Chain-of-Thought 形式のプロンプト（図6）を使用。 ## 新規性 - **X-lifecycle data の実証**: 既存の LLM ベース RCA は全てインシデントメタデータのみを使うが、本論文は依存関係データ・サービス機能説明という「別のライフサイクル段階の情報」を初めて大規模本番データで検証した - **インコンテキスト例 × 依存情報の相乗効果**: 依存情報単体（DEP）は InC NoDEP より低く、インコンテキスト例だけでも限界がある。両者を組み合わせた InC DEP だけが一貫して性能が向上する - **Microsoft 本番データでの最初の実証**: IC3（Teams バックエンド）の実際のインシデントと本番モニタを使い、学術ベンチマークでなく production 環境での改善を定量化した初の研究 ## 実験設定 - **ハードウェア/環境**: OpenAI API 経由の GPT-4（temperature=0）・GPT-3.5-turbo、ファインチューニングは GPT-3 - **データセット（RCA）**: IC3 サービスの 353 インシデント（2023-01-01〜2024-01-10）、うち約 50% が依存サービス障害。残りは RAG コーパスとして使用（過去 3 年分） - **データセット（モニタ）**: 260 モニタ（リソースクラス用）+ 180 モニタ（SLO クラス用）手動ラベル付き - **評価指標（RCA）**: 語彙的メトリクス（BLEU-4・ROUGE-L・METEOR）+ 意味的メトリクス（BERTScore・NUBIA）+ 人間評価（30 インシデント、1〜5 スコア） - **評価指標（モニタ）**: 適合率・再現率・F1 スコア・正解率（クラス別 + マイクロ/マクロ/重み付き平均） ## 実験結果 ### RCA 結果 表 1（全 353 インシデント、平均 ± 標準偏差）: | 手法 | BLEU | METEOR | ROUGE | BERTScore | NUBIA | |---|---|---|---|---|---| | FtGPT [3] | 5.64 ± 5.05 | 20.14 ± 8.27 | 17.72 ± 9.75 | 85.60 ± 3.04 | 20.63 ± 20.12 | | NoDEP | 6.26 ± 2.14 | 26.41 ± 6.16 | 16.32 ± 3.66 | 85.83 ± 1.40 | 12.32 ± 17.26 | | DEP | 6.14 ± 2.55 | 26.03 ± 6.58 | 16.03 ± 4.11 | 85.73 ± 1.48 | 11.68 ± 15.12 | | InC NoDEP [52] | 6.86 ± 2.69 | 26.54 ± 6.98 | 17.59 ± 4.35 | 86.11 ± 1.47 | 13.17 ± 18.14 | | **InC DEP（提案）** | **9.43 ± 4.23** | **26.72 ± 8.56** | **21.14 ± 6.34** | **86.65 ± 1.67** | **20.37 ± 21.70** | **主な知見**: - NUBIA スコアを除き、ファインチューニング済み GPT-3（FtGPT）は全手法で最低水準。GPT-4 での推論と GPT-3 でのファインチューニングという非対称比較が一因 - 依存情報単体（DEP）は NoDEP とほぼ同等または若干低下。インコンテキスト例なしでは依存情報が「ノイズ」になりうる - InC DEP は語彙メトリクスで他手法比 5〜38% 向上（METEOR が最小、BLEU が最大）、NUBIA スコアで 54.67% 向上 - 依存サービス障害（SD）インシデントで非依存（NoSD）より一貫して高い改善（BLEU: 9.285 NoSD vs 9.551 SD） **依存サービス障害分類の F1 スコア**: - NoDEP: 0.4 → InC NoDEP: 0.16（インコンテキスト例がノイズ）→ DEP/InC DEP: 0.58（依存情報追加で大幅改善） **人間評価（30 インシデント、1〜5 スコア）**: - FtGPT: 平均 1.8 ± 1.1 / InC NoDEP: 2.67 ± 1.24 / **InC DEP: 2.77 ± 1.36** - InC DEP は FtGPT 比 53.89% 向上、InC NoDEP 比 3.6% 向上 ### モニタ分類結果 SLO 分類（表 4）: - ベースライン C1: accuracy 0.75、macro-F1 0.73 - **C2（+ サービス説明）**: accuracy **0.79**、macro-F1 **0.77** - Availability クラスの再現率: C1 0.85 → **C2 1.00**（サービス説明が可用性 SLO の判定に効く） - Freshness クラスの F1: C1 0.80 → **C2 0.86** リソース分類（表 5）: - サービス説明の効果はより小さく、マクロ平均での改善は限定的 - コンポーネント説明（C4）は SLO・リソース分類ともに一貫した改善をもたらさない **SLO vs リソース分類の非対称性**: サービス説明はサービスレベル目標（SLO クラス）の理解に有効だが、リソースクラス（CPU/RAM 等の低レベル情報）への寄与は限定的。コンポーネント説明はリソースクラスに対して予測不安定を招くことがある。 ## 考察 **追加文脈が有効な条件**: 追加情報がタスクに意味的に対応しているとき。サービス説明は SLO クラスに効くが CPU/RAM 等のリソースクラスには効きにくい。依存情報は依存サービス障害インシデントに効くが非依存インシデントには限定的。 **関連性のない追加情報はむしろ低下させる**: コンポーネント説明の追加（C4 vs C2）や、依存情報なしでのインコンテキスト例追加（InC NoDEP が DEP より SLO で劣る場合がある）は逆効果になりうる。 **RCA 以外のタスクへの拡張可能性**: 非依存インシデント（コードバグ・ハードウェア障害等）に対してはソースコード・ログ等の別のライフサイクル情報が有効なはず。 ## 強み / 弱点・課題 **強み**: - 実際の本番データ（Microsoft IC3、Teams 2.5 億ユーザー）での大規模検証 - 複数評価指標（語彙・意味・人間評価）の一致的な傾向 - シンプルな「プロンプト拡張」として実装可能で、モデルのファインチューニング不要 **弱点・課題**: - IC3 単一サービス（Teams バックエンド）のデータ。他サービス・他組織への汎化は未検証 - 人間評価は 30 インシデントのみの小規模サンプル - 組織内の依存性追跡システム（DTS）等の内部データへのアクセスを前提とする - 非依存インシデント（約 50%）に対する X-lifecycle 拡張は今後の課題