以大型語言模型自動分析雲端事件的根本原因

原題： Automatic Root Cause Analysis via Large Language Models for Cloud Incidents
原始檔： 2305.15778v4.pdf
版本： arXiv:2305.15778v4 [cs.SE]，2023 年 11 月 13 日
發表： EuroSys ‘24，2024 年 4 月 22–25 日，希臘雅典。
DOI： https://doi.org/10.1145/3627703.3629553

翻譯說明：依本地 PDF 全文翻譯為繁體中文；保留原章節編號、引用編號、公式、數值及圖表。原頁位置以註記標示，跨頁段落依內容連續排列。程式名稱、例外名稱、分類標籤及書目資料保留英文；圖中的英文標籤另附中文對照，數值曲線與 GUI 保留原圖。文中對模型「目前／最新」的描述均指論文撰寫當時。原文中的操作步驟與 prompt 是論文內容。

作者： Yinfang Chen⋄§、Huaibing Xie⋄¶、Minghua Ma△∗、Yu Kang∗、Xin Gao∗、Liu Shi∗、Yunjie Cao∗、Xuedong Gao∗、Hao Fan∗、Ming Wen†、Jun Zeng‡、Supriyo Ghosh∗、Xuchao Zhang∗、Chaoyun Zhang∗、Qingwei Lin∗、Saravan Rajmohan∗、Dongmei Zhang∗、Tianyin Xu§。

所屬機構： Microsoft∗；University of Illinois at Urbana-Champaign§（伊利諾大學厄巴納－香檳分校）；Peking University¶（北京大學）；Huazhong University of Science and Technology†（華中科技大學）；National University of Singapore‡（新加坡國立大學）。

⋄ 本研究主要於 Microsoft Research Asia 的實習期間進行。
△ Minghua Ma 為通訊作者。

摘要

要確保雲端服務的可靠性與可用性，就必須對雲端事件進行有效率的根本原因分析（Root Cause Analysis，RCA）。傳統 RCA 方法依賴人工調查日誌與追蹤等資料來源，對值班工程師而言往往費工、容易出錯，而且相當困難。本文提出 RCACopilot，這是一套由大型語言模型驅動的創新值班系統，可自動分析雲端事件的根本原因。RCACopilot 根據告警類型，將新事件配對至對應的事件處理器，彙整重要的執行期診斷資訊，預測事件的根本原因類別，並提供敘述性的解釋。我們以 Microsoft 一整年的真實事件資料集評估 RCACopilot。評估顯示，RCACopilot 的 RCA 準確度最高可達 0.766。此外，RCACopilot 的診斷資訊蒐集元件已在 Microsoft 成功使用超過四年。

CCS 分類： 電腦系統組織 → 雲端運算；軟體與軟體工程 → 軟體維護。

關鍵字： 根本原因分析、大型語言模型、雲端系統。

出版與授權聲明： 允許免費製作本作品全部或部分的數位或紙本副本，供個人或課堂使用，前提是副本不得以營利或商業利益為目的製作或散布，且須在首頁保留本聲明與完整引用。對作品中由作者以外他人擁有的元件，必須尊重其著作權。允許在註明來源的情況下製作摘要。其他形式的複製、重新出版、張貼至伺服器或轉發至郵件清單，須事先取得特定許可及／或支付費用。許可申請請寄至 permissions@acm.org。© 2024 著作權由權利人／作者持有；出版權授予 ACM。ACM ISBN 979-8-4007-0437-6/24/04，售價 $15.00。

1 引言

雲端運算是人們日常仰賴的眾多應用與服務不可或缺的基礎設施。隨著雲端服務採用率持續成長，確保其可靠性、可用性與安全性變得愈來愈重要 [12, 17, 24, 32, 36, 43, 44, 47]。然而，雲端系統的複雜性使它們容易發生各種事件，對這些關鍵性質造成重大挑戰 [54]。典型的事件生命週期包含四個階段：（1）偵測 [37, 51, 52]：觀察到異常的系統行為時，由監控器或服務使用者（內部工程師或外部客戶）發出告警。（2）分流 [4, 8, 9]：偵測後，經過初步評估，事件會分派至適當的工程團隊。（3）診斷 [34]：受指派的值班工程師（On-Call Engineers，OCEs）檢查事件的不同面向，經過多輪來回溝通以找出根本原因。（4）緩解 [1, 20]：OCE 採取數項措施，緩解事件並恢復服務健康狀態。

根本原因分析（RCA）對於迅速且有效地處理這些事件至關重要。透過準確診斷底層問題並防止再次發生，RCA 不僅能快速恢復服務可用性，也能強化雲端服務的整體可靠性。然而，找出這些事件的根本原因，往往是一項困難且耗時的工作，需要大量人工專業知識與介入 [36]。

傳統雲端事件 RCA 通常涉及人工蒐集與分析各種資料，例如日誌 [18, 19, 27, 31, 56]、指標 [14, 38, 49]、追蹤 [53, 61] 及事件工單 [20, 42]。這個人工流程不僅費工、容易出錯，也會因可取得資訊的多寡而面臨挑戰；我們將這種情況稱為「資訊光譜」（information spectrum）。「資訊光譜」描述資訊可取得程度的連續範圍，從資訊太少，到被過量資訊淹沒。在光譜的任一端，RCA 都可能變得特別困難。與 RCA 有關的資訊可能埋藏在大量資料中，使 OCE 面臨資訊過載。OCE 可能很難在資料海中快速找出相關資訊，因而妨礙事件的有效解決。

反過來說，OCE 也會遇到缺乏必要資訊的情況，無法準確理解與處理事件根本原因。除了上述挑戰，蒐集到的資料本身也經常包含雜訊、不完整或不一致，進一步增加 RCA 流程的複雜度。

具體而言，工程團隊會將常見的疑難排解步驟記錄成疑難排解指南（Troubleshooting Guides，TSGs），以利處理未來事件。然而，TSG 的數量龐大，對 OCE 形成沉重負擔；尋找最相關指南成了耗時的工作，甚至可能造成系統停機。此外，TSG 難以跟上持續演變的雲端系統，因此在新事件類型出現時，往往不足以應對。即使找到了相關 TSG，它也不一定涵蓋特定事件的所有細節。原因可能是系統組態差異、多個互相作用的根本原因，或先前未知的問題。

RCA 的核心基本挑戰，是在有限時間內，有效率地蒐集與解讀全面且針對特定事件的資料。OCE 必須迅速辨別各類資料與當前事件的關聯，並正確解讀它們。然而，雲端系統所產生資料的複雜度與龐大數量，經常妨礙快速決策。此外，分析不同資料類型所需的專業知識，加上事件可能成因的多樣性，進一步提高這項工作的難度。因此，OCE 可能花費過多時間分析資料與提出假設，排擠原本更應用於解決事件及恢復系統功能的時間。

資料驅動與人工智慧（AI）技術已被用於事件管理自動化 [9, 10]。雖然已有技術可推薦相關 TSG [20]，或自動化 TSG 的工作流程 [42]，但其效用仍受限於 TSG 本身的固有挑戰。即使有這些自動化流程，OCE 仍必須投入大量人工，篩選海量資訊、解讀資料並辨識事件根本原因。

大型語言模型（LLMs）近來出現，並在複雜任務中取得成功 [21, 28, 46]，為改善 RCA 提供了一條有希望的途徑。具體而言，LLM 可用於解析大量資料、辨識相關資訊，並產生簡潔且具洞察力的輸出。這能大幅減輕 OCE 人工篩選龐大資料的負擔，協助他們專注於更快速、更有效地解決事件。此外，LLM 可適應新出現及持續演變的事件類型，從過去資料學習，以改善未來預測。

雖然 LLM 能有效率地處理及產生文字，但它們本身缺乏領域專屬知識，尤其是在雲端事件管理這類專業領域。對雲端事件等特定情境理解不足，可能限制它們預測事件根本原因及生成適當解釋的準確度。

最近，Ahmed 等人 [1] 提議使用領域專屬資料集微調 LLM，僅利用事件建立時可取得的標題及摘要資訊，來生成事件根本原因。雖然他們展示了 LLM 在事件根因分析上的潛力，微調仍有數項限制：（1）準確 RCA 需要來自各種來源的複雜非結構化或半結構化資料，例如日誌、遙測、追蹤及自然語言描述；僅使用一般性的標題與摘要，可能漏掉有助於得到確定診斷細節的訊號。（2）微調成本高，而且可能需要大量訓練樣本。（3）要隨事件性質與範圍持續演變而不斷更新微調後的 GPT 模型，具有挑戰性；因此，這類模型隨著時間推移，容易產生更多幻覺結果。

本文提出 RCACopilot，一套新穎的值班系統，提供自動化、端到端的雲端事件 RCA 方法。RCACopilot 作為值班系統，讓 OCE 能建立「事件處理器」（incident handlers）：針對各告警類型設計的自動化工作流程，由反映 OCE 專業知識的可重用動作組成。這些預先定義的處理器會自動簡化從多個來源蒐集事件專屬診斷資訊的流程，讓資料累積更聚焦、更相關，避免資訊光譜兩端的問題。接著，RCACopilot 的 LLM 元件處理診斷資料，預測事件根本原因的類別標籤，並提供對應解釋。結合事件處理器與 LLM，使 RCACopilot 能大幅提升事件回應的適應性與擴充能力。因此，RCACopilot 能有效處理多種事件，同時減少大量人工介入的需求。

RCACopilot 的診斷資訊蒐集元件已在 Microsoft 使用超過四年。在近期開發中，根本原因預測元件已完成原型；經過成功的初步階段後，Microsoft 某事件管理團隊已實際部署並使用數個月。

貢獻。 本文提出三項主要貢獻：

• 我們提出 RCACopilot，一套自動化、端到端的雲端事件根本原因分析方案，讓值班工程師能建立事件專屬的自動工作流程，以有效率地從多個來源蒐集資料。
• 我們在 RCACopilot 中整合大型語言模型，讓它自主分析蒐集到的診斷資料，預測事件根本原因類別並生成解釋，展示大型語言模型在根本原因分析上的潛力。
• 我們展示 RCACopilot 在 Microsoft 成功採用的成果，說明其真實世界適用性。這顯示它在提升根本原因分析效率上的實際成效，也證明我們的方法在真實雲端情境中的可行性與效益。

2 背景與動機

本節首先介紹事件根本原因分析的概念與重要性。接著，我們提供真實的疑難排解指南範例，說明其固有限制。最後，討論將大型語言模型整合至 RCA 流程的潛在優勢，這也構成我們的研究動機。

2.1 事件根本原因分析

在雲端服務領域，事件指任何中斷正常服務運作，或導致服務品質降低的事情。發生此類事件時，會進行根本原因分析，以找出造成中斷的底層問題。

雲端服務中的 RCA 是一個多面向流程：

• 資料蒐集： 從日誌、指標、追蹤或告警等多種來源蒐集與事件有關的資料，是 RCA 的第一步。
• 資料分析： 接著分析蒐集到的資料，以辨識模式、異常或相關性，這些可能提供事件根本原因的線索。
• 假設驗證： 根據資料分析，對可能的根本原因提出假設，再由 OCE 驗證。

雲端系統既複雜又具有動態性，加上涉及大量資料，使 RCA 成為需要大量專業知識與時間的艱鉅工作。以 Microsoft 電子郵件服務的規模為例，它每天傳遞超過 1,500 億則訊息。要確保這種大規模服務順暢運作，就必須採用高效率且有效的 RCA 方法。對維持可靠、高效能的通訊基礎設施而言，這至關重要，尤其是高度依賴 Microsoft 郵件伺服器的組織。

2.2 事件管理中多來源資料的機會與挑戰

在雲端服務複雜的生態系統中管理事件，需要全面理解系統狀態。這種理解通常來自多來源資料的整合，包括追蹤、日誌及指標。追蹤是樹狀結構資料，詳細描述使用者請求的流向；日誌是記錄硬體與軟體事件的半結構化文字；指標則監控服務狀態或使用者感知的量測值，形成時間序列資料。雖然各個資料來源能提供有價值的洞察，但要充分發揮其潛力仍有挑戰。TSG 等傳統方法雖然有用，卻可能因其固有限制，無法充分利用豐富的多來源資料。

圖 1：有問題訊息事件的 TSG。

Poisoned Messages（有問題訊息）的疑難排解指南

1. 前往 Poisoned Message Dashboard。此頁提供 Poison Message 功能的即時、高層次概況。圖表應能顯示問題已自行消失或仍在持續，以及問題大致發生的位置……
2. 儀表板新加入 Exception Table，可顯示某個時間範圍內的有問題訊息。在大多數情況下，造成告警的例外會升至表格頂端……
3. 也可以檢查 Poison Message Logs……

……

2.2.1 多來源資料的機會

不同資料來源提供系統狀態的不同觀點。例如，日誌能提供詳細的事件序列；指標能反映系統效能隨時間的變化；追蹤能揭示請求在服務間的傳播。整合這些來源可提供更全面的系統視野，讓事件診斷與解決更準確、更有效率。此外，多來源資料能促進相關性與因果關係分析，這對根本原因分析至關重要。分析不同來源間的關係，能辨識出可能指向事件根本原因的模式與異常。

2.2.2 多來源資料的挑戰

儘管潛力可觀，要在事件管理中有效利用多來源資料仍有挑戰。各種來源資料的龐大數量與複雜性可能令人難以負荷，使有意義的洞察難以萃取。更糟的是，不同來源可能提供不一致或互相衝突的資訊。此外，真實資料常含有雜訊，可能增加分析難度，導致錯誤結論。

2.2.3 TSG 的限制

傳統 TSG 是早期利用多來源資料進行事件管理的嘗試。它引導 OCE 從各種來源蒐集與分析資料，以診斷並解決事件。然而，TSG 面臨數項固有限制：

• 人工資料整合： TSG 通常要求 OCE 人工從不同來源蒐集資料。這個流程耗時且容易出錯。儘管已有各式疑難排解指南及 TSG 推薦技術 [20]，人工流程本身的限制仍使依賴 TSG 成為 OCE 重大壓力與職業倦怠的來源。
• 資訊過時： TSG 是靜態文件，往往難以隨系統變更及對事件根因的新理解保持更新。這種落後可能讓 OCE 遵循過時或非最佳的排解步驟。例如，圖 1 第二步提到用於檢查 Poison Message 例外的新功能「Exception Table」，在發布後並未立即納入 TSG，可能使事件解決效率降低。
• 細節及涵蓋範圍不足： TSG 常出現高層次指示，缺乏細節與具體引導，迫使 OCE 進行額外研究，延長事件緩解時間。在圖 1 的例子中，第三步要求檢查 Poison Message Logs，卻省略重要細節，讓不熟悉此事件類型的 OCE 感到困惑。此外，TSG 可能忽略磁碟空間等常見檢查，導致事件僅獲部分或不足的解決。

2.3 大型語言模型對事件管理的潛力

自然語言處理與機器學習的快速進展，促成了強大 LLM 的發展。研究指出，它們透過零樣本與少樣本學習，在各種下游任務中都有效 [5, 11, 28]。這些模型在翻譯、摘要及問答方面展現出色表現。在雲端運算系統的事件管理中運用其潛力，可能徹底改變 OCE 辨識與解決事件的方式。透過自動化事件管理中的解讀工作，LLM 可減輕 OCE 執行複雜值班任務時的壓力及認知負荷，使他們更能專注於較高層次的工作與決策。

2.4 我們的動機

我們的研究動機源於使用人工 TSG 診斷事件及辨識底層根本原因時面臨的挑戰。我們希望建立自動診斷流程，利用 LLM 的能力，更有效地處理各種雲端事件。先前工作 [42] 利用 AI 技術，從現有 TSG 生成自動化工作流程；我們的目標則是讓有經驗的 OCE 建立事件診斷的自動化管線。這個方法能直接協助 OCE 辨識根本原因，而不必調查中間診斷資訊；不過，他們仍可選擇這麼做。

我們設想的未來，是根本原因分析主要由自動化完成，僅在必要時進行最少量人工驗證。我們的方法旨在針對特定事件，及時向 OCE 提供相關且準確的資訊，使 RCA 更有效率。透過 LLM 預測根本原因類別，我們希望降低事件管理帶來的壓力與認知負荷，最終提升處理事件的效率與成效。

3 從事件中得到的洞察

我們以嚴謹的質性分析方法，全面研究 Microsoft 某電子郵件服務一整年的事件。具體而言，有經驗的 OCE 逐一仔細審查事件，根據問題特徵、問題來源及對系統的影響分類。我們特別關注事件根本原因、回應的有效性，以及類似問題再次發生的情況。雖然這些洞察確實由直覺推導而來，卻牢固建立在實證資料與分析之上。我們的研究不僅對事件模式與挑戰產生有價值的洞察，也協助我們開發及改進方法。

洞察 1：僅依賴單一資料來源判斷根本原因，可能相當困難。 以表 1 的事件 2 為例：某前端入口（front door）機器的 UDP hub 連接埠耗盡，使單一伺服器無法對傳入封包執行 DNS 解析。這個例子說明，僅依賴單一來源（監控告警）診斷複雜問題的困難。

信箱伺服器向外部收件者傳送郵件時，會使用特定前端入口伺服器（代理）。然而，每個前端入口伺服器可用的 SMTP 輸出代理連線數都有限。如果信箱伺服器的代理連線請求失敗，就無法向外部收件者傳送訊息。在這個事件中，監控器首先發出告警，表示偵測到連至前端入口伺服器的失敗。然而，告警只指出郵件伺服器與前端入口伺服器之間有連線問題，甚至沒有暗示 DNS 解析問題。因此，根本原因仍不明確。

圖 2：重複事件比例與時間間隔的關係。 橫軸為時間間隔（天），標示 0、20、40、60、80、100、120；縱軸為機率，標示 0.00、0.02、0.04、0.06。原圖曲線保留如下。

圖片遺失：圖 2 原始數值曲線

表 1：不同根本原因類別的雲端事件範例。 Sev. 為嚴重程度，Scope 為影響範圍，Occur. 為發生次數；Forest 指樹系範圍，Machine 指單一機器。

洞察 2：源自相似或相同根本原因的事件，常在短時間內再次發生。 如圖 2 所示，我們發現大多數重複事件（93.80%）傾向在短短 20 天內再次出現。例如，考慮表 1 中事件 9 的類別。這類事件由無效的客戶組態觸發，使未處理訊息在佇列中累積，因而嚴重降低其可用性。有趣的是，這類事件在短短 15 天內重複發生 11 次。同樣地，DispatcherTaskCancelled 事件（表 1 編號 10）在一週內再次出現 22 次，DeliveryHang 事件（編號 3）在一個月內再次出現 6 次。這些情況可歸因於數項因素。初次回應未解決的根本原因可能使相同問題再次發生，尤其是問題複雜或尚未完全理解時。其次，系統性弱點若未處理，可能遭到反覆利用，造成類似事件。第三，外部相依性，例如仰賴經常中斷的服務，也可能導致事件反覆出現。這些模式表示，利用先前事件的洞察，我們能迅速辨識新發生、但具有相同根本原因的事件。

圖 3：事件類別頻率分布。 橫軸為類別發生次數（1、2、3、4、5、6、7、8、9、≥10）；縱軸為數量（0、30、60、90、120、150）。原始柱狀圖如下。

圖片遺失：圖 3 事件類別頻率分布

洞察 3：具有新根本原因的事件經常發生，而且更難分析。 TSG 可以提供明確的調查指引，協助 OCE 診斷問題。然而，當事件源自先前未曾遇過的新根本原因時，OCE 會面臨一系列挑戰。這類事件沒有現成 TSG，OCE 可能很難找出底層問題。例如，事件 1 是嚴重程度 1 的高度嚴重事件，由組態設定錯誤引發，阻止驗證 token 產生，造成嚴重服務中斷。同樣地，事件 6 是攻擊者以惡意 blob 發動漏洞利用所造成的惡意攻擊。這種攻擊先前從未出現，因此 OCE 沒有可參考的既有 TSG。較低嚴重程度（嚴重程度 2）的事件，例如事件 5，也會在垃圾郵件發送者首次濫用系統時面臨相同挑戰。如圖 3 所示，具有新根本原因類別的事件，占全部事件的 24.96%（653 件中的 163 件）。如果 OCE 把時間花在尋找不存在的 TSG，事件影響可能進一步擴大。為因應這項挑戰，有必要提出新方法，能有效推論、分類及解釋這些未見事件的根本原因，從而減少 OCE 辨識與處理這些特殊事件所需的時間。

4 RCACopilot

如圖 4 所示，RCACopilot 分為兩個階段：診斷資訊蒐集階段，以及根本原因預測階段。

診斷資訊蒐集階段： 這是起始階段，會解析事件，並將其配對至預先定義的事件處理器。每個處理器都針對特定告警類型設計。將事件配對至適當處理器後，RCACopilot 便從多種來源蒐集相關診斷資料。

根本原因預測階段： 診斷資訊蒐集完成後，RCACopilot 進入根本原因預測階段。在此階段，RCACopilot 利用預測模組判斷事件可能的根本原因類別。這項預測不只是分類，也會附上解釋，詳述 RCACopilot 如何得到該預測。接著，預測類別標籤交由有經驗的 OCE 審查。

4.1 診斷資訊蒐集階段

依據第 3 節洞察 1，RCACopilot 旨在蒐集多來源資料以進行 RCA。具體而言，每種告警類型都會建立一個事件處理器，包含一系列蒐集診斷資訊的動作。告警類型用於根據特定監控器對告警分類。具有相同告警類型的事件，會呈現相似症狀，卻可能源自不同根本原因。

RCACopilot 事件處理器是一個由一系列動作組成的工作流程。每個動作都是一個可執行函式，用來從目標資料來源蒐集特定診斷資訊。OCE 可依據專業知識建立及修改處理器。處理器包含三種不同動作：範圍切換、查詢及緩解，將在第 4.1.2 節解釋。每個動作都會產生輸出，引導處理器的控制流程。我們以診斷表 1 事件 7 的 RCACopilot 處理器為例，說明其使用方式。

4.1.1 事件處理器

OCE 處理事件時採用的決策流程，類似決策樹的控制流程。事件處理器的根節點是從系統監控器取得的事件告警類型。建立處理器時，我們將 OCE 的操作歸納為三類動作。由於 OCE 面對不同事件類型時，操作可能相似，例如執行常見磁碟檢查或資料庫查詢，因此我們將 RCACopilot 的處理器動作設計成可跨所有處理器重用。我們也在資料庫中保存處理器的版本，用於追蹤歷史變更。

RCACopilot 的事件處理器首先由人工建立，之後可由 OCE 動態更新及修改，讓它們跟上最新系統變更及新發現的根本原因。例如，系統引入新指標時，OCE 只需建立蒐集相關資料的新動作，再將其加入對應處理器，就能及時調整。

4.1.2 處理器動作

RCACopilot 利用多來源資料的協同作用。系統使用事件處理器中預先定義、可重用的動作，自動從不同來源蒐集相關診斷資訊。自動整合資料不僅節省時間，也降低人為錯誤的可能性。它提供更全面的系統狀態視野，促進有效率且準確的事件解決。這能大幅減輕 OCE 的工作負荷，降低壓力及職業倦怠，提升事件解決流程的成效。

處理器中的動作可能是下列其中一種：

範圍切換動作： 此動作可根據每個事件的特定需求，調整資料蒐集範圍，提高 RCA 的精確度。例如，如圖 5 所示，若告警源自「forest」層級，表示某個特定樹系內發生問題，而問題類型被判定為「Busy Hub」，範圍切換動作便可將範圍調整至「machine」層級。這使調查更細緻，專門評估是否有某一部 hub 伺服器負荷過高。

此動作的實作可確保我們有效處理資訊光譜。當調查需要更聚焦的方式時，此動作可縮小資料蒐集範圍。反之，若需要更全面的視野，它也能擴大範圍，例如從單一機器擴展至整個樹系。這種彈性讓診斷資料蒐集更平衡、更有效。

圖 4：RCACopilot 架構。

圖片遺失：圖 4 RCACopilot 原始架構

圖中文字與流程對照：新事件（Incoming Incident，包含 ID、Title／標題、OwingTenant／所屬租戶、OwningTeam／所屬團隊、ACTIVE／啟用中及 Severity 2／嚴重程度 2）→ 蒐集階段（Collection Stage）：事件解析（Incident Parsing）→ 處理器配對（Handler Matching）→ 資訊蒐集（Info. Collection）。資料庫（DB）提供載入處理器（Load handlers）及儲存診斷資訊（Store diagnostic info.）。接著進入預測階段（Prediction Stage）：事件摘要（Incident Summarization）將診斷資訊（Diagnostic information）送至 LLM，產出摘要後診斷資訊（Summarized diagnostic info.）；鄰近事件搜尋（Neighbor Search）透過嵌入（Embedding）、嵌入向量資料庫（Embedding vector DB）找出 K 個最近鄰（Find K Nearest）；根本原因預測（Root cause prediction）將 Incident 1、Incident 2、…、Incident K 送至 LLM，輸出根本原因類別及解釋（Root cause category and explanation），交給 OCE。

查詢動作： 查詢動作可向不同來源查詢資料，並以鍵值對表格輸出查詢結果。這類動作也可接至執行使用預先定義參數的特定腳本。這些腳本通常是某個服務的內部自動調查工具，只有該服務團隊能存取。

例如，圖 5 的「Known issue?」動作節點，會根據告警訊息查詢資料庫，確認當前事件是否為已知問題。如果是，執行流程會進入「True」分支，直接提供緩解動作。否則，會執行能將相同堆疊追蹤的執行緒彙整在一起的查詢腳本。它會取得目標程序中所有受管理執行緒當下的堆疊清單，再將相同堆疊分組，以辨識程序中的潛在死結或阻塞程式碼路徑。

查詢動作也可輸出列舉值，以決定接下來執行哪個動作節點。例如，透過「Get top error msg」節點取得例外堆疊追蹤最上方的錯誤訊息後，下一個要執行的動作會依例外類型決定。如圖 5 所示，系統根據錯誤訊息回報給特定團隊，並請其介入。

緩解動作： 此動作指用於緩解事件的建議策略步驟，例如圖 5 的「重新啟動服務」或「請其他團隊介入」。處理器並不一定能對每個事件提供精確的緩解策略，因為它們是預先定義的，可能無法涵蓋所有情況。例如，表 1 事件 4 屬於程式碼回歸類別，辨識與修正這類程式碼問題可能很困難。若事件處理器無法確定，它會提供中間診斷資訊給 OCE，而不提供緩解措施。

4.1.3 多來源診斷資訊

RCACopilot 的診斷資訊蒐集階段，透過彙整眾多來源的資料，為 OCE 提供有價值的工具。OCE 只需自訂處理器中的動作，即可從目標來源取得診斷資訊。例如，如圖 6 所示，RCACopilot 可整合與特定事件相關的錯誤日誌、例外堆疊追蹤及 socket 指標等多種資料。單靠錯誤日誌及例外堆疊追蹤，無法提供足夠洞察來辨識事件根因。然而，補上 socket 指標後，便能呈現更全面的情況。在這個範例中，可以清楚看出 UDP socket 已耗盡，這就是根本原因。

對於新事件，RCACopilot 可執行一系列常見檢查，例如評估資源佈建狀態或分析執行緒堆疊，協助 OCE 全面理解狀況。所蒐集的資訊由 RCACopilot 處理器動作預先定義，確保只取得相關資料，避免被不必要的過量資訊淹沒。藉由提供完整診斷資訊，RCACopilot 使 OCE 團隊能有效率地排解問題。他們可利用蒐集到的資訊作為引導，更有效地處理事件。

4.2 以 LLM 解釋事件

經過完整調查後，我們服務中的每個事件，都會由經驗豐富的 OCE 人工指派根本原因類別。OCE 用這些類別對歷史事件分類，並引導新事件的 RCA。然而，對時間緊迫的 OCE 而言，推理事件並推論其類別，既耗時也可能造成沉重負擔。因此，我們將事件根本原因分類，選定為主要下游任務。

近來，LLM 在理解下游任務情境及從示例生成相關資訊上展現出色能力，使其成為事件 RCA 的可能選項。然而，推理事件根本原因並不簡單；若沒有任何指引，LLM 在長尾或領域專屬任務中，可能無法達到最佳結果 [6, 22]。思維鏈（Chain-of-Thoughts，CoT）提示是一種無須梯度的技術，可引導 LLM 生成通往最終答案的中間推理步驟。在少樣本 CoT 提示中，會提供幾個人工示例，每個示例包含一個問題，以及導向答案的推理鏈。受到這些想法啟發，RCACopilot 處理器提供的診斷資訊，可作為事件推理流程的材料。

圖 5：針對過多訊息卡在投遞佇列告警的 RCACopilot 處理器。

圖片遺失：圖 5 原始處理器流程

節點與分支中文對照：

• Determine Issue Type：判定問題類型。Busy Hub（hub 忙碌）→ Switch Scope to Single Server（將範圍切換至單一伺服器）→ Default（預設）→ Analyze Single Busy Server（分析單一忙碌伺服器）。
• Others（其他）→ Get top Error Msg（取得最上方錯誤訊息）。*Deliver.Exception:MailboxOfflineException.* → Report to a Specific Team（回報給特定團隊）；*recipient mailbox location information is not available*（收件者信箱位置資訊不可取得）→ Engage other Teams（請其他團隊介入）。
• Busy Delivery/Recipient（投遞／收件者忙碌）→ Known Issue?（是否為已知問題？）。True（是）→ Mitigation Actions（緩解動作）；Default（預設）→ Get-ThreadStackGrouping.ps1 → Check Delivery Health（檢查投遞健康狀態）→ Delivery is Restarted Recently?（最近是否已重新啟動投遞？）。
• False（否）→ Restart Service（重新啟動服務）→ Default（預設）→ Collect Diagnose Logs（蒐集診斷日誌）；True（是）→ 直接蒐集診斷日誌。

圖 6：hub 連接埠耗盡的診斷資訊。 以下完整保留原範例數值、時間與技術識別字，文字欄位譯為中文。

來自 [MachineID] 的 DatacenterHubOutboundProxyProbe 探測日誌結果。
總探測次數：2，失敗探測次數：2

Id  層級   建立時間                     描述
2   Error  11/21/2022 2:04:20 AM        探測結果
2   Error  11/21/2022 1:49:20 AM        探測結果

失敗探測錯誤：
名稱：找不到這樣的主機。
連線至主機 [HOST NAME] 時遇到 WinSock 錯誤：11001
次數：2
……

例外：
InformativeSocketException：找不到這樣的主機。
連線至主機 [HOST NAME] 時遇到 WinSock 錯誤：11001
  at TcpClientFactory.Create(...)
  at SimpleSmtpClient.Connect(...)
……

UDP socket 總數：15276
依程序及 processId 統計的 UDP socket 總數（僅列前 5 名）：
14923: Transport.exe, 203736
15: w3wp.exe, 102296
8: svchost.exe, 4748
7: Microsoft.Transport.Store.Worker.exe, 74060
7: Microsoft.Transport.Store.Worker.exe, 87724

4.2.1 嵌入模型

我們觀察到，事件的語意可從描述診斷資訊的情境中揭示。萃取這種情境語意的一個常見方式，是使用嵌入模型。目標是將診斷資訊映射至嵌入空間，也就是數值向量空間，讓向量間距離表示事件的語意相似度。選擇計算效率高的嵌入模型，讓我們在處理大量事件時，仍可維持準確度。

我們採用 FastText 作為嵌入模型，因為它有效率、不易受文字輸入長度影響，且能生成稠密矩陣，便於計算相似向量間的歐幾里得距離。此外，我們的下游任務專屬於事件根本原因推理，而事件相關資訊是公司內部資料，因此選擇以歷史事件訓練 FastText 模型，不採用成本高且效率低的預訓練大型語言模型作為嵌入模型。我們也提供彈性，讓使用者依需要自訂嵌入模型。

4.2.2 最近鄰搜尋

事件具有異質性。即使已做摘要，prompt 的長度限制仍使整合所有過去事件資訊作為取樣來源不切實際。為了選擇性地挑出過去案例，作為 prompt 中的樣本，我們設計了新的相似度公式：

這些公式用於計算兩個事件之間的相似度。首先，計算每一對事件向量的歐幾里得距離。它也納入事件間的時間距離，呼應第 3 節的洞察 2。其中，$T(x)$ 代表事件 $x$ 的日期。考慮時間距離相當重要，因為它影響過去事件與當前事件的相關程度。計算相似度後，我們選出來自不同類別、排名最前面的 $K$ 個事件，作為 LLM 的示例。這個方法確保示例多樣且具有代表性，以便有效推理。透過第 5.4 節將呈現的實證評估，$\alpha$ 及 $K$ 分別確定為 0.3 及 5。

4.2.3 診斷資訊摘要

LLM 已展現自動摘要的潛力 [40]。然而，RCACopilot 處理器蒐集的診斷資訊常常過長。如圖 6 所示，一個事件的診斷資訊可能超過 2,000 tokens，而日誌訊息的可讀性很低。事件描述含有大量 tokens，可能使 LLM 難以有效處理，也可能引入雜訊。因此，直接將事件診斷資訊送入 LLM 進行預測，可能並不理想，更不用說使用多來源資訊。為此，我們增加一層處理，在進行診斷推理之前，先利用 LLM 的摘要能力彙整診斷資訊。我們依圖 7 的方式建立 prompt，要求 LLM 將診斷資訊摘要為 120–140 個單字，且不得輸出無關資訊。這個摘要流程讓診斷資訊更精簡、更具資訊量，成為後續 CoT 提示的基礎。圖 8 顯示 RCACopilot 生成更易讀且簡潔的文字，是圖 6 診斷資訊範例的摘要（113 tokens），凸顯 UDP 連接埠使用數量及使用最多的程序等關鍵細節。具體而言，我們採用 tiktoken [41] tokenizer 計算文字 tokens。

圖 7：用於彙整診斷資訊的 prompt。

請摘要上述輸入。請注意，上述輸入是事件診斷資訊。摘要結果應約為 120 個單字，不超過 140 個單字，並盡可能涵蓋重要資訊。只回傳摘要，不要有任何額外輸出。

圖 8：摘要後的診斷資訊。

DatacenterHubOutboundProxyProbe 在後端機器上失敗兩次，兩次失敗都是由 WinSock 錯誤 11001 引起，表示主機未知。這個錯誤是在嘗試連線至主機時遇到的。此錯誤與 EOP 服務有關，且尚未通知。失敗情境也指向相同問題。UDP socket 總數為 15276，其中多數由 Transport.exe 程序使用。此問題似乎與 SMTP 連線有關，需要進一步調查。

4.2.4 預測 prompt 的建立

CoT 提示是一種無須梯度的技術，引導 LLM 產生通往最終答案的中間推理步驟。在少樣本 CoT 提示中，數個示例包含問題與引導答案的推理鏈。受到自動建立 prompt 以形成推理鏈的方法 [60] 啟發，我們可將摘要後的診斷資訊及已標記的根本原因類別，分別視為問題與推理。因此，尋找最近鄰事件就相當於自動建立推理鏈，與 CoT 提示的情境相當契合。注意，我們使用原始事件資訊進行嵌入與最近鄰搜尋，再將對應摘要資訊納入 prompt 的示例。我們依圖 9 建立 prompt，要求 LLM 選出最可能與當前事件具有相同根本原因的事件；此外，透過 prompt 中「給出你的解釋」的指示，明確促使 LLM 進行推理。

圖 9：預測事件類別的 prompt。

情境： 以下描述顯示某事件的錯誤日誌資訊。請選出最可能具有相同根本原因的事件資訊，並給出你的解釋（只給一個答案）。如果沒有，請選擇第一項「未見過的事件」。

輸入： 來自 [BackEndMachine] 的 DatacenterHubOutboundProxyProbe 探測結果為失敗……

選項：

A：未見過的事件。

B：DatacenterHubOutboundProxyProbe 失敗兩次……類別：HubPortExhaustion。

C：TransportDelivery 程序中有 62 個受管理執行緒……類別：AuthCertIssue。

4.3 實作

我們使用總計 58,286 行程式碼開發並部署 RCACopilot，其中包含 56,129 行 C# 及 2,157 行 Python。

為了方便建立 RCACopilot 事件處理器，我們將處理器建構實作為網頁應用程式，如圖 10 所示。要讓 RCACopilot 支援新的告警類型，OCE 只需依其專業知識，在處理器建構 GUI 中新增一個處理器。新處理器建立後，會存入資料庫；OCE 可透過建立新的動作節點或刪除舊節點來修改它。

圖 10：RCACopilot 用於建構處理器的網頁使用者介面。

圖片遺失：圖 10 處理器建構 GUI

介面欄位對照：Node Information＝節點資訊；Overview＝概覽；GUID＝全域唯一識別碼；Name＝名稱；Description＝描述；Scope switcher ID＝範圍切換器 ID；Scope type＝範圍類型；Node type＝節點類型；Target ID＝目標 ID。範例名稱為 Get-ThreadStackGrouping.ps1；描述為「執行 Get-ThreadStackGrouping.ps1」；範圍類型 Machine＝機器；節點類型 Default＝預設。其他技術識別碼保留原圖。

5 評估

我們的評估旨在回答下列問題：

1. RCACopilot 作為值班系統，在預測根本原因類別與協助 OCE 時，其成效與效率如何？ RCACopilot 預測雲端事件根本原因類別時，Micro-F1 與 Macro-F1 分別達到 0.766 及 0.533，優於所有基準方法，且執行成本低（4.205 秒）。RCACopilot 也能為未見事件產生新的根本原因類別標籤及解釋。
2. RCACopilot 的不同元件如何促進診斷與預測？ RCACopilot 證明，診斷資訊蒐集元件、GPT 摘要，以及思維鏈提示，都有助於預測成效。
3. RCACopilot 適合部署至真實生產服務嗎？其結果可信嗎？ RCACopilot 的診斷資訊蒐集模組，已在 Microsoft 30 個團隊部署超過四年。為評估可信度，每項實驗都執行三輪；RCACopilot 能持續達到超過 0.70 的高 Micro-F1 分數，以及超過 0.50 的 Macro-F1 分數。

所有實驗都在配備 Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz、32.0 GB 實體記憶體及 Intel UHD Graphics 630 的伺服器上執行。作業系統為 Windows 11 Enterprise。

5.1 目標系統與資料集

我們在 Microsoft 內名為 Transport 的全球電子郵件服務系統上評估 RCACopilot。Transport 團隊專注於開發及維護負責郵件流、路由與投遞的元件。系統會與其他多種服務互動，以確保與包括 serviceA、serviceB 及 serviceC 在內的眾多產品和服務無縫整合。因此，它能代表與多個元件互動的複雜真實系統。Transport 每天傳遞約 1,500 億則訊息，規模極大，服務全球客戶，增加了另一層多樣性及複雜性。系統利用 SMTP、IMAP 及 POP3 等協定，確保電子郵件在使用者之間安全且有效地傳送。考量其在通訊基礎設施中的關鍵角色，有效且高效率的事件管理能力不可或缺。

我們從 Microsoft Transport 服務蒐集一整年、共 653 件事件的資料集，以研究 RCACopilot 的實際成效。每件事件都代表大型、全球分散式系統中的複雜問題，因此各自提供有價值的洞察。資料集由有經驗的 OCE 人工標記根本原因類別，作為標準答案（ground truth）。我們將事件分成訓練集（75%）及測試集（25%）。

我們在 RCACopilot 中對兩種大型語言模型進行實驗，即 GPT-3.5-turbo 與 GPT-4（8K tokens），它們是 OpenAI 當時最新的模型。由於 GPT-4 表現最佳，我們將其選為 RCACopilot 的預設模型。

5.2 比較方法

我們選擇 XGBoost、FastText 及微調後的 LLM 作為基準，與 RCACopilot 比較。使用訓練資料集完成訓練或微調後，直接將這些方法套用至測試集執行分類任務。我們也建立 GPT-4 Prompt 及 Embed. 兩個變體，評估 RCACopilot 的設計。

• XGBoost 提供平行樹提升（parallel tree boosting），常用於網路系統診斷。
• FastText 是常見的輕量文字嵌入方法，已在透過故障注入進行根本原因診斷的測試平台研究中採用。我們直接將 FastText 套用至資料集進行分類。
• Fine-tune GPT 使用訓練資料集微調預訓練 GPT-3.5 模型，再於測試資料集評估，temperature 參數設為 0。它不採用 RCACopilot 的 prompt 設計（例如 CoT 提示），而是根據原始診斷資訊直接預測類別。GPT-4 當時尚不支援微調。
• GPT-4 Prompt 是 RCACopilot 的變體，直接利用 RCACopilot 診斷資訊摘要預測類別。其 prompt 只包含待預測事件，沒有歷史事件作為示例。
• GPT-4 Embed. 是將嵌入模型由 FastText 改成 GPT embedding 的 RCACopilot 變體。

表 2：不同方法的成效。 時間單位為秒；Train. 為訓練時間，Infer. 為推論時間。

5.3 成效與效率

我們根據摘要後的診斷資訊預測事件根本原因類別，並使用 micro 與 macro F1-score 評估 RCACopilot 的成效。這些指標計算精確率與召回率的調和平均數。Micro F1-score 彙總所有類別的表現，考慮各樣本的貢獻；Macro F1-score 則著重各個類別的表現。RCACopilot 在測試資料集上達到 0.766 的 micro F1-score，以及 0.533 的 macro F1-score。

如表 2 所示，RCACopilot 優於其他方法，而其較高的執行成本仍在可接受範圍。基準方法表現不佳，是因為多個根本原因類別呈現長尾（不平衡）分布，如圖 3 所示；傳統機器學習模型（FastText 與 XGBoost）以及微調 GPT，需要大量訓練資料才能準確預測。不採用我們的設計，直接使用 GPT-4 prompt 或 GPT-4 embedding，則缺乏讓 GPT-4 作決策的領域專屬知識。相較之下，RCACopilot 利用強大的 LLM，從少量案例學習領域專屬知識，因此能達到最佳表現。結果顯示，RCACopilot 不僅提供較高準確度，也維持合理效率，使其適合用於事件根本原因分析。

面對先前從未見過的事件時，RCACopilot 能生成新類別關鍵字，描述新的事件案例。例如，表 1 的事件 8 是 RCACopilot 從未遇過的新事件。預測元件能將其預測為新的「I/O Bottleneck」（I/O 瓶頸）類別。雖然 OCE 在事後調查中將其歸類為「DiskFull」，RCACopilot 所辨識的問題基本面，仍與人工標籤高度一致。圖 11 提供對應解釋，說明 RCACopilot 如何得到「I/O Bottleneck」分類。

圖 11：RCACopilot 對一個事件的解釋。

預測為「I/O 瓶頸」，是因為處理輸入／輸出操作的重要函式中出現 System.IO.IOExceptions，暗示資料處理有問題。DiagnosticsLog 模組中的巢狀例外進一步支持這個判斷。這些錯誤，加上不同後端機器上的當機，指出系統在處理資料流時遭遇困難。

譯註：表 1 使用的類別名稱為 FullDisk，本段原文則寫作 DiskFull，此處依各處原文保留。

5.4 比較分析

為理解 RCACopilot 各元件如何促進根本原因分析，我們對不同元件進行消融研究。

診斷資訊評估。 首先，評估診斷資訊對成效的影響。具體而言，將蒐集階段取得的診斷資訊，與其他事件相關資訊比較，即事件告警資訊及 RCACopilot 處理器動作輸出。AlertInfo 包含告警類型及告警範圍。告警類型是監控器預先定義的異常描述，只反映事件症狀而非根因，例如外部監控器提供的例外類型。告警範圍則是事件的範圍，例如單一機器。ActionOutput 是一系列已執行 RCACopilot 動作的輸出，會以雜湊方式組織成鍵值對。如表 3 所示，只使用診斷資訊，在 Micro-F1（0.689）及 Macro-F1（0.510）上即可優於其他組合。有趣的是，將診斷資訊與其他資訊混合，並不會提升 RCACopilot 的預測能力。這表示資訊過量可能對 LLM 的預測表現造成負面影響。

圖 12：不同 K 及 alpha 的使用成效。 （a）Micro-F1；（b）Macro-F1。兩圖橫軸均為 alpha（$\alpha$），標示 0.0、0.2、0.4、0.6、0.8；曲線分別為 K=3、5、9、12、15。（a）縱軸標示 0.60、0.64、0.68、0.72、0.76；（b）縱軸標示 0.30、0.36、0.42、0.48、0.54。原始曲線保留如下，不將圖中未標出的點估算為精確數字。

圖片遺失：圖 12 不同 K 與 alpha 的 Micro-F1／Macro-F1

表 3：RCACopilot 不同 prompt 情境的成效。 ✓sum. 表示摘要後的診斷資訊。勾選位置依原 PDF 表格視覺核對。

GPT 摘要評估。 我們評估 GPT 摘要在提升 RCACopilot 成效上的作用。如表 3 所示，使用摘要後的診斷資訊，得到最高的 Micro-F1 與 Macro-F1；相較於未經摘要的診斷資訊，分別提升 0.077 及 0.023。結果顯示，摘要步驟能有效濃縮資訊，讓事件資料的處理更有效率且更準確。

少樣本 CoT 推理評估。 我們評估少樣本 CoT 推理如何改善成效。表 2 中的 GPT-4 Prompt 方法，不提供任何樣本就直接預測類別，Micro-F1 與 Macro-F1 分別僅達到 0.026 及 0.004。如圖 12a 及 12b 所示，我們比較思維鏈推理使用不同樣本數時的 RCACopilot 表現。分析顯示，樣本數及 alpha 的最佳組合分別為 5 及 0.3，得到最高 F1 分數。注意，CoT 推理中增加樣本，不一定能改善 RCACopilot；alpha 的值在決定成效上具有重要作用。alpha 適當時，RCACopilot 能更好地捕捉不同事件的時間關係，產生更準確的預測。

5.5 部署狀態與規模

我們已成功將 RCACopilot 診斷資訊蒐集模組部署至 Microsoft 超過 30 個團隊，持續實際使用超過四年。系統依各團隊特定需求調整，針對每個獨特環境建立自訂處理器。並非所有處理器目前都已在生產環境啟用，因為部分仍在開發及嚴格測試。我們選出使用 RCACopilot 事件處理器最多的前 10 個團隊，如表 4 所示。我們觀察到，每件事件的平均執行時間從 15 秒到 841 秒不等。最高執行時間歸因於該團隊規模龐大且複雜的系統基礎設施。根本原因預測模組也已在 Transport 服務推出。

為了持續改善並提供良好的使用者體驗，我們在事件通知電子郵件中加入回饋機制，以取得 OCE 的使用觀點。根據蒐集到的回饋，大多數 OCE 對 RCACopilot 表示滿意。雖然建立新事件處理器仍需人工投入，但重用及修改資料庫中的處理器動作時，OCE 認為流程很方便。RCACopilot 能大幅節省 OCE 蒐集診斷資訊、事件分流、執行緩解措施及事後分析的時間。

表 4：Microsoft 使用 RCACopilot 自動蒐集診斷資訊的團隊。

譯註：本段原文時間範圍寫為 15–841 秒，而表 4 所列十個團隊的最低值為 22 秒；兩處依原文保留。

5.6 可信度

雖然 GPT 在各種任務中展現巨大潛力與令人印象深刻的成果，但 Tan 等人 [45] 指出，它在問答等特定複雜任務中，已知會出現一些不穩定性。這些不穩定性可能導致結果變動。為確保 RCACopilot 中 GPT 預測能力的可信度及穩定性，每項實驗均執行三輪。每一輪 RCACopilot 都能維持高水準表現，Micro-F1 持續高於 0.70，Macro-F1 也維持在 0.50 以上。

6 討論

RCACopilot 的成效取決於 LLM 的能力。目前，RCACopilot 僅整合 OpenAI 的 GPT 模型，尚未探索其他可用 LLM 的潛在成效。因此，表現可能隨採用模型的優點與弱點而變化。

我們使用 Transport 的事件資料集評估 RCACopilot 預測模組。Transport 團隊專家具備豐富經驗，並已建立事件標記實務，因此協助準備資料集。RCACopilot 的成效也受人工根本原因類別標籤品質影響。目前，所有根本原因類別皆由經驗豐富的 OCE 人工標記。RCACopilot 診斷資訊蒐集已部署至超過 30 個團隊。因此，有價值的未來工作，是在不同服務中評估 RCACopilot，更全面理解其泛化及適應能力。

RCACopilot 的處理器設計為依據監控器／watchdog 的告警啟動回應。這可確保某個特定告警類型有指定事件處理器時，能以 100% 準確率啟動它。然而，若監控器未偵測到事件，或某事件沒有對應處理器，RCACopilot 的能力便會受限。這也限制了 RCACopilot 的適用性。

我們執行三輪實驗評估 RCACopilot 的成效。然而，LLM 偶爾不穩定，可能影響成效，使不同輪次出現變動。另一項內部效度威脅，是我們的方法及比較方法的實作。為降低風險，兩名作者仔細檢查程式碼；特別是，我們的實作建立在成熟框架上。

7 相關工作

根本原因分析。 大型雲端服務的根本原因分析，已成為系統及軟體工程研究社群的熱門主題 [2, 7, 15, 16, 23, 30, 33, 36, 50, 59]。它根據指標、日誌及追蹤等不同資料來源，辨識故障及效能問題的根本原因。先前研究提出使用其中某一種來源進行根本原因分析的不同方法。例如，有些方法仰賴指標萃取故障模式 [36, 58]，或建立服務相依圖 [25, 35]；其他方法使用日誌分析部分日誌訊息 [1, 57]，或檢查每則訊息中的細節 [27, 56]；另有技術利用追蹤定位故障服務 [26, 29, 48, 54]。與先前工作不同，我們建立的系統能自動整合指標、日誌及追蹤，搭配先進大型語言模型進行根本原因分析。

大型語言模型。 近年 LLM 的興起，透過支援程式碼生成、摘要、修復、測試及根本原因分析等任務，為軟體系統領域帶來新機會 [1, 13, 39, 40]。例如，Mastropaolo 等人 [40] 研究微調 T5 在下列任務中的能力：自動修復 bug、產生 assert 陳述式、程式碼摘要及注入程式碼變異體。LANCE [39] 使用微調 T5，自動為 Java 方法生成日誌陳述式。VulRepair [13] 也在漏洞修復資料集上微調 T5，自動提出漏洞修補。Zhang 等人 [55] 提議透過 LLM 提示，改善程式碼版本控制。Ahmed 等人 [1] 微調 GPT-x 模型，推薦根本原因與緩解步驟，以促進雲端事件管理。相較於先前研究，RCACopilot 使用先進 LLM 摘要診斷資料，並運用思維鏈能力預測與解釋根本原因。

8 結論

RCACopilot 是雲端事件管理領域的先驅工具，可協助 OCE 有效率地進行根本原因分析。它透過診斷資訊蒐集階段，引入獨特的多來源資料蒐集方法，使用預先定義的事件處理器。這些由 OCE 建立的處理器，會系統性地蒐集多來源診斷資訊，為後續分析奠定基礎。此外，RCACopilot 在根本原因預測階段整合大型語言模型。模型自主處理蒐集到的診斷資料，預測並解釋根本原因類別。將 AI 技術整合至雲端事件管理，展現 RCACopilot 提升根本原因分析效率及準確度的潛力。

致謝

我們感謝論文 shepherd Ang Chen 及匿名審查者提出富有洞察力的意見。感謝 Ning Ding、Xupei Wang 及 Zhaoying Li 參與、支持 RCACopilot 專案並作出貢獻。感謝 Microsoft 內所有與我們合作的值班工程師。

參考文獻

以下書目資料保留原文，共 61 筆，出自原 PDF 第 13–15 頁。原文未包含另列附錄。

[1] Ahmed, T., Ghosh, S., Bansal, C., Zimmermann, T., Zhang, X., and Rajmohan, S. Recommending root-cause and mitigation steps for cloud incidents using large language models. In Proceedings of the 45th International Conference on Software Engineering (ICSE’23) (2023).

[2] Alqraan, A., Takruri, H., Alfatafta, M., and Al-Kiswany, S. An analysis of network-partitioning failures in cloud systems. In Proceedings of the 13th USENIX Conference on Operating Systems Design and Implementation (OSDI’18) (2018).

[3] Arzani, B., Ciraci, S., Loo, B. T., Schuster, A., and Outhred, G. Taking the blame game out of data centers operations with netpoirot. In Proceedings of the 2016 ACM SIGCOMM Conference (SIGCOMM’16) (2016).

[4] Bansal, C., Renganathan, S., Asudani, A., Midy, O., and Janakiraman, M. Decaf: Diagnosing and triaging performance issues in large-scale cloud services. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Software Engineering in Practice (2020).

[5] Brown, T., Mann, B., Ryder, N., Subbiah, M., Kaplan, J. D., Dhariwal, P., Neelakantan, A., Shyam, P., Sastry, G., Askell, A., et al. Language models are few-shot learners. Advances in neural information processing systems (2020).

[6] Chalkidis, I. Chatgpt may pass the bar exam soon, but has a long way to go for the lexglue benchmark. arXiv preprint arXiv:2304.12202 (2023).

[7] Chen, H., Dou, W., Jiang, Y., and Qin, F. Understanding exception-related bugs in large-scale cloud systems. In 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE’19) (2019).

[8] Chen, J., He, X., Lin, Q., Xu, Y., Zhang, H., Hao, D., Gao, F., Xu, Z., Dang, Y., and Zhang, D. An empirical investigation of incident triage for online service systems. In 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP’19) (2019).

[9] Chen, J., He, X., Lin, Q., Zhang, H., Hao, D., Gao, F., Xu, Z., Dang, Y., and Zhang, D. Continuous incident triage for large-scale online service systems. In 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE’19) (2019).

[10] Chen, J., Zhang, S., He, X., Lin, Q., Zhang, H., Hao, D., Kang, Y., Gao, F., Xu, Z., Dang, Y., et al. How incidental are the incidents? characterizing and prioritizing incidents for large-scale online service systems. In Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering (ASE’20) (2020).

[11] Chen, M., Tworek, J., Jun, H., Yuan, Q., Pinto, H. P. d. O., Kaplan, J., Edwards, H., Burda, Y., Joseph, N., Brockman, G., et al. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374 (2021).

[12] Chen, Y., Sun, X., Nath, S., Yang, Z., and Xu, T. Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker. In Proceedings of the 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI’23) (2023).

[13] Fu, M., Tantithamthavorn, C., Le, T., Nguyen, V., and Phung, D. Vulrepair: a t5-based automated software vulnerability repair. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE’22) (2022).

[14] Ganatra, V., Parayil, A., Ghosh, S., Kang, Y., Ma, M., Bansal, C., Nath, S., and Mace, J. Detection is better than cure: A cloud incidents perspective. In Proceedings of the 31st Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE) (2023).

[15] Gao, Y., Dou, W., Qin, F., Gao, C., Wang, D., Wei, J., Huang, R., Zhou, L., and Wu, Y. An empirical study on crash recovery bugs in large-scale distributed systems. In Proceedings of the 26th ACM joint meeting on european software engineering conference and symposium on the foundations of software engineering (ESEC/FSE’18) (2018).

[16] Ghosh, S., Shetty, M., Bansal, C., and Nath, S. How to fight production incidents? an empirical study on a large-scale cloud service. In Proceedings of the 13th Symposium on Cloud Computing (2022).

[17] Gu, J. T., Sun, X., Zhang, W., Jiang, Y., Wang, C., Vaziri, M., Legunsen, O., and Xu, T. Acto: Automatic End-to-End Testing for Operation Correctness of Cloud System Management. In Proceedings of the 29th ACM Symposium on Operating Systems Principles (SOSP’23) (2023).

[18] He, S., Zhang, X., He, P., Xu, Y., Li, L., Kang, Y., Ma, M., Wei, Y., Dang, Y., Rajmohan, S., et al. An empirical study of log analysis at microsoft. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE) (2022).

[19] Inam, M. A., Chen, Y., Goyal, A., Liu, J., Mink, J., Michael, N., Gaur, S., Bates, A., and Hassan, W. U. Sok: History is a vast early warning system: Auditing the provenance of system intrusions. In 2023 IEEE Symposium on Security and Privacy (S&P’22) (2022).

[20] Jiang, J., Lu, W., Chen, J., Lin, Q., Zhao, P., Kang, Y., Zhang, H., Xiong, Y., Gao, F., Xu, Z., et al. How to mitigate the incident? an effective troubleshooting guide recommendation technique for online service systems. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE’20) (2020).

[21] Jin, P., Zhang, S., Ma, M., Li, H., Kang, Y., Li, L., Liu, Y., Qiao, B., Zhang, C., Zhao, P., et al. Assess and summarize: Improve outage understanding with large language models. In Proceedings of the Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE) (2023).

[22] Kasai, J., Kasai, Y., Sakaguchi, K., Yamada, Y., and Radev, D. Evaluating gpt-4 and chatgpt on japanese medical licensing examinations. arXiv preprint arXiv:2303.18027 (2023).

[23] Leesatapornwongsa, T., Stuardo, C. A., Suminto, R. O., Ke, H., Lukman, J. F., and Gunawi, H. S. Scalability bugs: When 100-node testing is not enough. In Proceedings of the 16th Workshop on Hot Topics in Operating Systems (HotOS’17) (2017).

[24] Li, H., Ma, M., Liu, Y., Qin, S., Qiao, B., Yao, R., Chaturvedi, H., Tran, T., Chintalapati, M., Rajmohan, S., Lin, Q., and Zhang, D. Codec: Cost-effective duration prediction system for deadline scheduling in the cloud. In Proceedings of the 34th IEEE International Symposium on Software Reliability Engineering (2023).

[25] Li, M., Ma, M., Nie, X., Yin, K., Cao, L., Wen, X., Yuan, Z., Wu, D., Li, G., Liu, W., et al. Mining fluctuation propagation graph among time series with active learning. In Database and Expert Systems Applications: 33rd International Conference (2022).

[26] Li, Z., Chen, J., Jiao, R., Zhao, N., Wang, Z., Zhang, S., Wu, Y., Jiang, L., Yan, L., Wang, Z., et al. Practical root cause localization for microservice systems via trace analysis. In 2021 IEEE/ACM 29th International Symposium on Quality of Service (2021).

[27] Li, Z., Luo, C., Chen, T.-H., Shang, W., He, S., Lin, Q., and Zhang, D. Did we miss something important? studying and exploring variable-aware log abstraction. arXiv preprint arXiv:2304.11391 (2023).

[28] Lian, X., Chen, Y., Cheng, R., Huang, J., Thakkar, P., and Xu, T. Configuration validation with large language models. arXiv preprint arXiv:2310.09690 (2023).

[29] Liu, D., He, C., Peng, X., Lin, F., Zhang, C., Gong, S., Li, Z., Ou, J., and Wu, Z. Microhecl: High-efficient root cause localization in large-scale microservice systems. In 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP’21) (2021).

[30] Liu, H., Lu, S., Musuvathi, M., and Nath, S. What bugs cause production cloud incidents? In Proceedings of the Workshop on Hot Topics in Operating Systems (HotOS’19) (2019).

[31] Liu, Y., Zhang, X., He, S., Zhang, H., Li, L., Kang, Y., Xu, Y., Ma, M., Lin, Q., Dang, Y., et al. Uniparser: A unified log parser for heterogeneous log data. In Proceedings of the ACM Web Conference 2022 (2022).

[32] Lou, C., Chen, C., Huang, P., Dang, Y., Qin, S., Yang, X., Li, X., Lin, Q., and Chintalapati, M. RESIN: A holistic service for dealing with memory leaks in production cloud infrastructure. In Proceedings of the 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI’22) (2022).

[33] Lou, C., Huang, P., and Smith, S. Understanding, detecting and localizing partial failures in large system software. In Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI’20) (2020).

[34] Luo, C., Lou, J.-G., Lin, Q., Fu, Q., Ding, R., Zhang, D., and Wang, Z. Correlating events with time series for incident diagnosis. In Proceedings of the 20th ACM SIGKDD international conference on Knowledge discovery and data mining (2014).

[35] Ma, M., Xu, J., Wang, Y., Chen, P., Zhang, Z., and Wang, P. Automap: Diagnose your microservice-based web applications automatically. In Proceedings of The Web Conference 2020 (2020).

[36] Ma, M., Yin, Z., Zhang, S., Wang, S., Zheng, C., Jiang, X., Hu, H., Luo, C., Li, Y., Qiu, N., et al. Diagnosing root causes of intermittent slow queries in cloud databases. Proceedings of the VLDB Endowment (VLDB’20) (2020).

[37] Ma, M., Zhang, S., Chen, J., Xu, J., Li, H., Lin, Y., Nie, X., Zhou, B., Wang, Y., and Pei, D. Jump-starting multivariate time series anomaly detection for online service systems. In 2021 USENIX Annual Technical Conference (ATC’21) (2021).

[38] Ma, M., Zhang, S., Pei, D., Huang, X., and Dai, H. Robust and rapid adaption for concept drift in software system anomaly detection. In 2018 IEEE 29th International Symposium on Software Reliability Engineering (ISSRE’18) (2018).

[39] Mastropaolo, A., Pascarella, L., and Bavota, G. Using deep learning to generate complete log statements. In Proceedings of the 44th International Conference on Software Engineering (ICSE’22) (2022).

[40] Mastropaolo, A., Scalabrino, S., Cooper, N., Palacio, D. N., Poshyvanyk, D., Oliveto, R., and Bavota, G. Studying the usage of text-to-text transfer transformer to support code-related tasks. In Proceedings of the 43rd International Conference on Software Engineering (ICSE’21) (2021).

[41] OpenAI. Tiktoken: A python library for tokenizing text. https://github.com/openai/tiktoken, 2023.

[42] Shetty, M., Bansal, C., Upadhyayula, S. P., Radhakrishna, A., and Gupta, A. Autotsg: learning and synthesis for incident troubleshooting. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE’22) (2022).

[43] Sun, X., Cheng, R., Chen, J., Ang, E., Legunsen, O., and Xu, T. Testing Configuration Changes in Context to Prevent Production Failures. In Proceedings of the 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI’20) (2020).

[44] Sun, X., Luo, W., Gu, J. T., Ganesan, A., Alagappan, R., Gasch, M., Suresh, L., and Xu, T. Automatic Reliability Testing for Cluster Management Controllers. In Proceedings of the 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI’22) (2022).

[45] Tan, Y., Min, D., Li, Y., Li, W., Hu, N., Chen, Y., and Qi, G. Evaluation of chatgpt as a question answering system for answering complex questions. arXiv preprint arXiv:2303.07992 (2023).

[46] Wei, J., Wang, X., Schuurmans, D., Bosma, M., Chi, E., Le, Q., and Zhou, D. Chain of thought prompting elicits reasoning in large language models. arXiv preprint arXiv:2201.11903 (2022).

[47] Wu, Y., Chen, A., Haeberlen, A., Zhou, W., and Loo, B. T. Automated bug removal for software-defined networks. In Proceedings of the 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI’17) (2017).

[48] Xie, Z., Xu, H., Chen, W., Li, W., Jiang, H., Su, L., Wang, H., and Pei, D. Unsupervised anomaly detection on microservice traces through graph vae. In Proceedings of the ACM Web Conference 2023 (2023).

[49] Yan, X., Hsieh, K., Liyanage, Y., Ma, M., Chintalapati, M., Lin, Q., Dang, Y., and Zhang, D. Aegis: Attribution of control plane change impact across layers and components for cloud systems. In 2023 IEEE/ACM 45th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP’23) (2023).

[50] Yuan, D., Luo, Y., Zhuang, X., Rodrigues, G. R., Zhao, X., Zhang, Y., Jain, P., and Stumm, M. Simple testing can prevent most critical failures: An analysis of production failures in distributed data-intensive systems. In Proceedings of the 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI’14) (2014).

[51] Zeng, J., Chua, Z. L., Chen, Y., Ji, K., Liang, Z., and Mao, J. Watson: Abstracting behaviors from audit logs via aggregation of contextual semantics. In Network and Distributed System Security Symposium (NDSS’21) (2021).

[52] Zeng, J., Wang, X., Liu, J., Chen, Y., Liang, Z., Chua, T.-S., and Chua, Z. L. Shadewatcher: Recommendation-guided cyber threat analysis using system audit records. In 2022 IEEE Symposium on Security and Privacy (S&P’22) (2022).

[53] Zeng, Z., Zhang, Y., Xu, Y., Ma, M., Qiao, B., Zou, W., Chen, Q., Zhang, M., Zhang, X., Zhang, H., et al. Traceark: Towards actionable performance anomaly alerting for online service systems. In 2023 IEEE/ACM 45th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP’23) (2023).

[54] Zeng, Z., Zhang, Y., Xu, Y., Ma, M., Qiao, B., Zou, W., Chen, Q., Zhang, M., Zhang, X., Zhang, H., Gao, X., Fan, H., Rajmohan, S., Lin, Q., and Zhang, D. Traceark: Towards actionable performance anomaly alerting for online service systems. In To appear in Proc. of ICSE (2023).

[55] Zhang, J., Mytkowicz, T., Kaufman, M., Piskac, R., and Lahiri, S. K. Using pre-trained language models to resolve textual and semantic merge conflicts (experience paper). In Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis (2022).

[56] Zhang, T., Qiu, H., Castellano, G., Rifai, M., Chen, C. S., and Pianese, F. System log parsing: A survey. IEEE Transactions on Knowledge and Data Engineering (2023).

[57] Zhang, X., Xu, Y., Qin, S., He, S., Qiao, B., Li, Z., Zhang, H., Li, X., Dang, Y., Lin, Q., et al. Onion: identifying incident-indicating logs for cloud systems. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (2021).

[58] Zhang, Y., Guan, Z., Qian, H., Xu, L., Liu, H., Wen, Q., Sun, L., Jiang, J., Fan, L., and Ke, M. Cloudrca: a root cause analysis framework for cloud computing platforms. In Proceedings of the 30th ACM International Conference on Information & Knowledge Management (2021).

[59] Zhang, Y., Yang, J., Jin, Z., Sethi, U., Rodrigues, K., Lu, S., and Yuan, D. Understanding and detecting software upgrade failures in distributed systems. In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles (SOSP’21) (2021).

[60] Zhang, Z., Zhang, A., Li, M., and Smola, A. Automatic chain of thought prompting in large language models. In The Eleventh International Conference on Learning Representations (ICLR’23) (2023).

[61] Zhao, C., Ma, M., Zhong, Z., Zhang, S., Tan, Z., Xiong, X., Yu, L., Feng, J., Sun, Y., Zhang, Y., et al. Robust multimodal failure detection for microservice systems. In Proceedings of the 29th ACM SIGKDD Conference on Knowledge Discovery and Data Mining (2023).