## Memo - Microsoftの研究グループによるarXiv論文。 - 依存サービスの障害かの判定は[[2023__arXiv__Assess and Summarize - Improve Outage Understanding with Large Language Models|Oasis]]とどう違う？ 本論文は、大規模クラウドサービスにおけるインシデント管理の自動化について、以下の問題意識と解決策を提示しています。 問題意識: - インシデント管理は複雑で手間がかかり、オンコールエンジニア(OCE)の多大な手作業を要する - 既存研究はソフトウェア開発ライフサイクル(SDLC)の単一段階のデータのみを利用し、サイロ化された視点でインシデント管理の特定タスクを解決する傾向にある 既存手法とその課題: - 依存サービス障害のルート原因分析では、インシデントメタデータのみを利用して言語モデル(LLM)をファインチューニングしたり、事前学習済みLLMをクエリする - モニター分類では、モニターメタデータのみを利用してLLMでリソースクラスと[[SLO]]クラスを分類する - これらの手法は、インシデント解決に必要な様々なコンテキストデータを考慮していない 提案する解決策: - SDLCの異なる段階から得られるクロスライフサイクル(X-lifecycle)データをLLMのプロンプトに追加し、OCEと同様の推論を可能にする - 依存サービス障害のルート原因分析では、インシデントメタデータに加え、上流の依存サービス情報をプロンプトに追加 - モニター分類では、モニターメタデータに加え、サービスアーキテクチャと機能の情報を追加 - Microsoftの実際のインシデントとモニターのデータセットを用いた実験により、提案手法がベースラインを上回る性能を示した 以上のように、本論文はSDLC全体の情報を活用することで、既存のLLMベースのインシデント管理自動化手法の課題を解決し、性能向上を実証しています。 --- X-lifecycle (クロスライフサイクル) データとは、ソフトウェア開発ライフサイクル (SDLC) の異なる段階から得られる様々なデータを指します。 SDLCは通常、以下のような段階で構成されます: 1. 要件定義 2. 設計 3. 実装 4. テスト 5. デプロイ 6. 運用・保守 これらの各段階で生成される多様なデータがX-lifecycleデータに含まれます。例えば: - 要件定義段階: 要求仕様書、ユースケース文書など - 設計段階: アーキテクチャ設計書、詳細設計書など - 実装段階: ソースコード、設定ファイルなど - テスト段階: テスト仕様書、テストコード、バグレポートなど - デプロイ段階: デプロイスクリプト、環境設定など - 運用・保守段階: ログデータ、モニタリングデータ、インシデントレポートなど 従来、これらのデータは個別の段階で生成・管理されることが多く、全体として活用されることは少なかったのですが、本論文ではこれらのデータを統合的に利用することで、インシデント管理タスクにおける言語モデルのパフォーマンスを向上させることを提案しています。つまり、X-lifecycleデータを活用することで、OCEと同様にサービス全体の文脈を考慮した推論が可能になるというわけです。 --- 本論文では、以下の既存手法が取り上げられています。 1. [[2023__ICSE__Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models|Ahmed+, ICSE2023]] [3] (FtGPT) - インシデントメタデータを用いてGPTモデルをファインチューニングし、ルート原因と緩和策の推奨を自動生成する手法。 - Microsoftの過去3年分のインシデントデータを用いてGPT-3モデルをファインチューニングし、インシデント管理ドメインのセマンティクスを学習させる。 2. [[2024__arXiv__Automated Root Causing of Cloud Incidents using In-Context Learning with GPT-4|Zhang+, arXiv2024]] [52] (InC NoDEP) - 類似する過去のインシデント事例をコンテキスト情報としてプロンプトに含めることで、事前学習済みのLLMを用いてルート原因を推定する手法。 - [[FAISS]]ライブラリを用いて、過去のインシデントデータからタイトル、サマリー、ルート原因が類似する上位5件を検索し、プロンプトに追加する。 3. [[2023__arXiv__Empowering Practical Root Cause Analysis by Large Language Models for Cloud Incidents|Chen+, arXiv2023]] (RCACopilot) [11] - インシデントメタデータのみを用いて、事前学習済みのLLMをクエリし、特定タイプのサービスのルート原因を分類する手法。 4. [[2024__ICSE__Intelligent Monitoring Framework for Cloud Services - A Data-Driven Approach|Srinivas+, ICSE2024]] [45] - モニターメタデータのみを用いて、LLMでモニターのリソースクラスとSLOクラスを分類する手法。 - 13のリソースクラスと9のSLOクラスを定義し、モニターメタデータからコンテキスト学習によって各クラスを予測する。 これらの既存手法はいずれも、インシデントやモニターのメタデータのみを利用しており、サービス全体のアーキテクチャや依存関係、機能などの情報は考慮していません。本論文では、これらの情報をLLMのプロンプトに追加することで、OCEと同様の推論が可能になり、性能が向上することを示しています。 --- 本論文では、インシデント管理の2つのタスクについて、X-lifecycleデータを活用した言語モデル（LLM）ベースの手法を提案しています。 1. 依存サービス障害のルート原因分析 - 目的: インシデントメタデータに加えて、上流の依存サービスの情報をプロンプトに追加することで、ルート原因の推定精度を向上させる。 - 手法: a) インシデントメタデータ（タイトル、サマリー、影響を受けたサービス名と機能）を取得。 b) 過去のインシデントデータから、FAISSライブラリを用いて類似する上位5件を検索し、コンテキスト情報としてプロンプトに追加。 c) 影響を受けたサービスの上流依存サービスとそのプロパティ情報を取得し、プロンプトに追加。 d) GPT-4モデルを用いて、ルート原因を推定し、依存サービス障害か否かを分類。 2. モニターの分類 - 目的: モニターメタデータに加えて、サービスのアーキテクチャと機能の情報を追加することで、リソースクラスとSLOクラスの分類精度を向上させる。 - 手法: a) モニターメタデータ（モニター名、メトリック名、サービス名、アラートタイトル、アラート条件）を取得。 b) サービスの機能説明、マイクロサービスやコンポーネントの情報を社内ディレクトリから取得。 c) モニターメタデータとサービス情報を組み合わせてプロンプトを作成。 d) GPT-4モデルを用いて、以下の4つのケースでリソースクラスとSLOクラスを分類。 - Case 1: モニターメタデータのみ（ベースライン） - Case 2: モニターメタデータ＋サービス機能説明 - Case 3: モニターメタデータ＋サービス機能説明＋コンポーネント説明 - Case 4: モニターメタデータ＋コンポーネント説明 これらの手法により、インシデントやモニターのメタデータだけでなく、サービス全体のコンテキストを考慮することで、OCEと同様の推論が可能になり、精度が向上することが示されています。 ## Abstract 大規模なクラウド・サービスのインシデント管理は複雑で面倒なプロセスであり、オンコール・エンジニア（OCE）による多大な手作業が必要である。OCEは通常、ソフトウェア開発ライフサイクル[SDLC]のさまざまな段階からのデータ（コード、構成、モニタデータ、サービスプロパティ、サービス依存関係、トラブルシューティング文書など）を活用して、インシデントの検出、根本原因、緩和のための洞察を生成します。最近の大規模言語モデル[[LLM]](例えば、ChatGPT、GPT-4、Gemini)の進歩は、OCEsが重要な問題を迅速に特定し、緩和するのを支援する文脈的な推奨を自動的に生成する機会を創出した。しかしながら、既存の研究は、SDLC の単一のステージからのデータを活用することで、インシデント管理における特定のタスクを解決するためのサイロ化されたビューを取るのが一般的です。(1)依存性障害に関連するインシデントの根本原因の推奨を自動的に生成すること、(2)インシデントを自動的に検出するために使用されるサービスモニタのオントロジーを特定すること、である。マイクロソフトの353のインシデントと260のモニタのデータセットを活用することで、SDLCの異なるステージからのコンテキスト情報を補強することで、State-of-the-Artの手法よりも性能が向上することを実証する。