本文介紹如何通過智能會話，使用自然語言與數字員工（Agent）進行多輪對話，完成從警示發現到根因定位的完整故障診斷流程。文中包含CloudMonitor（CMS）入口和Log Service（SLS）入口兩種情境的對話樣本，以及 AI 回答不理想時的追問技巧。
業務情境
收到警示通知或發現系統異常時，需要快速定位問題根因。傳統方式需要手動查詢多個監控系統、日誌平台和拓撲圖，效率低且容易遺漏關聯資訊。STAROps 智能會話支援用自然語言描述問題，數字員工會自動關聯多來源資料進行分析，將故障診斷的時間從數十分鐘縮短至幾輪對話。
方案架構
故障診斷流程涉及以下核心環節：
問題輸入：通過CloudMonitor（CMS）智能助手或Log Service（SLS）智能助手發起對話，描述警示內容或異常現象。
資料關聯：數字員工根據問題描述，自動查詢 Prometheus 指標、SLS 日誌、拓撲關係等多來源資料。如果使用了 @實體引用，數字員工會以該實體為起點展開分析。
多輪推理：基於首輪分析結果，數字員工可能提出進一步的檢查方向。通過追問可以引導分析向特定維度深入。
根因輸出：輸出包含異常指標、日誌證據和拓撲關聯的根因分析報告，並給出修複建議。
實施步驟
環境確認
在開始故障診斷前，確認以下環境已就緒：
檢查項 | 確認方式 |
數字員工已建立 | 在STAROps 控制台側邊欄單擊數字員工管理，確認目標數字員工狀態正常。 |
工作空間已接入可觀測資料 | 在工作空間詳情頁確認已接入指標（Prometheus）、日誌（SLS）等資料來源。 |
可觀測模型（UModel）已配置 | 在對話方塊中輸入 |
數字員工已配置預設規則（推薦） | 配置預設規則可顯著提升診斷品質。具體操作參見打造專屬營運智能體。 |
情境一：通過CloudMonitor（CMS）入口進行故障診斷
CloudMonitor智能助手支援 @實體引用，適合從警示出發、沿拓撲關係逐步排查的情境。
使用 @實體引用
在對話方塊中輸入 @，系統會彈出工作空間中的實體列表。實體類型包括叢集（Cluster）、節點（Node）、服務（Service）、Pod 等，具體取決於可觀測模型（UModel）的配置。
選擇目標實體後，數字員工會以該實體為分析起點，自動關聯其上下遊拓撲和關聯指標。
對話樣本：Pod 異常重啟排查
以下是一個完整的多輪對話樣本，展示如何從一條 Pod 重啟警示出發，逐步定位根因。
第 1 輪：描述問題
@Service:order-service 最近 1 小時內有 Pod 頻繁重啟，幫我分析一下原因。數字員工將自動執行以下操作：
查詢 order-service 關聯的 Pod 列表和重啟次數。
檢查重啟 Pod 的容器退出碼和最近日誌。
分析 Pod 的資源使用趨勢（CPU、記憶體）。
第 2 輪：深入追問
如果首輪分析顯示 OOMKilled，可以繼續追問：
幫我看看這個 Pod 的 JVM 堆記憶體使用量趨勢，以及最近是否有大查詢請求。數字員工會進一步查詢 JVM 指標和請求日誌，定位記憶體流失或大查詢導致的 OOM。
情境二：通過Log Service（SLS）入口進行故障診斷
Log Service智能助手擅長從日誌維度切入分析，適合錯誤記錄檔激增、請求延遲異常等情境。
對話樣本：錯誤記錄檔激增排查
第 1 輪：描述問題
payment-service 從 14:00 開始出現大量 500 錯誤，幫我排查原因。數字員工將自動執行以下操作：
查詢 payment-service 在 14:00 前後的錯誤記錄檔分布。
按錯誤類型分類統計，提取高頻異常堆棧。
關聯上遊調用鏈，檢查是否存在級聯故障。
第 2 輪：驗證修複
我已經重啟了資料庫連接池，幫我確認 payment-service 的錯誤率是否恢複正常。數字員工會對比修複前後的錯誤率趨勢，確認問題是否解決。
追問技巧：提升 AI 診斷效果
當 AI 首輪迴答不夠深入或方向偏差時，可以通過以下追問策略引導分析方向：
情境 | 追問樣本 | 預期效果 |
分析不夠深入 | "請從 JVM、串連池和下遊依賴三個維度分別分析。" | 引導 AI 從多維度展開分析，避免單一視角。 |
方向偏差 | "問題不在網路層，重點看應用程式層的錯誤記錄檔。" | 糾正分析方向，避免在無關維度上浪費時間。 |
缺少上下文 | "這個服務在今天 14:00 剛做過一次發布，鏡像版本從 v2.3.1 升級到 v2.4.0。請結合這個變更重新分析" | 主動補充 AI 無法自動擷取的業務上下文（如發布記錄、配置變更等）。 |
需要時間對比 | "對比一下昨天同時段和今天的指標差異。" | 通過基準對比發現異常位移。 |
需要拓撲分析 | "檢查 order-service 的上下遊服務是否也有異常。" | 沿拓撲關係追蹤級聯故障源頭。 |
驗證修複效果 | "我已經擴容了 Pod 副本數，幫我確認延遲是否下降。" | 即時驗證修複措施是否生效。 |
診斷結論的輸出格式
診斷完成後，您可以要求 AI 輸出結構化的診斷結論。推薦使用以下 prompt：
請匯總剛才的分析，輸出一份結構化的診斷報告，包含根因、影響範圍、級聯關係和建議操作。
AI 通常會輸出如下格式的結論：
故障診斷報告
根因
pod-storage-02 因記憶體 Limit 配置過低（2GiB）觸發 OOM Killed。
影響範圍
- 直接影響：service-storage 可用 Pod 從 3 個降至 2 個。
- 間接影響：上遊 pod-data-processor 觸發重試風暴，node-03 CPU 飆升至 92%。
級聯故障鏈
pod-storage-02 OOM → service-storage 延遲上升 → pod-data-processor 重試風暴 → node-03 CPU 飆升
建議操作
1. [立即] 調整 pod-storage-02 記憶體 Limit 至 4GiB。
2. [立即] 確認 pod-storage-02 是否已恢複。
3. [短期] 為 service-storage 配置 PDB（minAvailable=2）。
4. [長期] 為 pod-data-processor 配置指數退避重試策略。
從診斷到持續跟蹤
如果診斷髮現的問題需要持續關注，您可以通過建立長期任務（Mission）進行自動化監控：
幫我建立一個長期任務，每天巡檢 service-storage 的記憶體使用量情況和 Pod 健康狀態，如果發現 OOM 風險立即通知我。
AI 會引導您完成 Mission 的建立和藍圖規劃。詳細操作請參見建立與規劃長期任務。