一、AIOps 與 RCA 技術演進趨勢

二、基于多智能體的運維體系搭建

三、大模型落地多場景根因定位系統

四、DeepSeek等大模型優化與實踐

一、AIOps與RCA技術演進趨勢

1、運維技術演進：從 DevOps 到 AIOps

運維技術演進呈現從DevOps到AIOps的發展脈絡。

圖片

DevOps階段（自動化運維范式）：

以自動化流程為核心，打通開發與運維壁壘，通過持續集成/交付（CI/CD）實現部署、交付周期的優化，提升迭代式效率。

AIOps階段（智能運維新范式）：

基于大數據分析與機器學習，實現異常檢測、根因定位和故障自愈，將運維從被動響應轉向主動預測，顯著降低平均修復時間（MTTR）與業務中斷風險。

2、運維技術演進：RCA 技術難點

圖片

RCA技術難點主要體現在多模態數據融合、因果推斷、數據質量及落地工程化等方面：

1）多模態數據融合難

需整合告警日志等非結構化數據與 APM、CMDB 等圖結構數據，實現多源異構數據對系統狀態的統一刻畫；

2）因果推斷復雜度高

組件間依賴關系交織，易受虛假相關干擾，精準推導根因難度大；

3）數據質量要求嚴苛

噪聲、缺失值會直接影響分析準確性，需從源頭保障數據質量；

4）工程化落地門檻高

需結合領域知識，缺乏通用框架，模型訓練優化成本高且對性能、可解釋性要求極嚴。

解決RCA技術難點的關鍵：

1）運維數據整合

針對多模態數據融合難題，整合海量多源異構數據（含非結構化、圖結構數據），構建統一數據平臺，精準刻畫系統狀態，為根因分析提供堅實數據基礎；

2）多智能體協同

面對復雜因果推斷，引入多智能體協同機制，通過各智能體分工協作，有效應對組件間復雜依賴關系，減少虛假相關對根因推斷的干擾；

3）大模型推理與知識沉淀

優化大模型訓練與推理流程，結合私部署大模型及私域運維經驗構建專屬知識庫，同時關注大模型安全性問題，最終提升整個RCA流程的效率與準確性。

3、運維技術演進：未來趨勢

圖片

總結來說，未來AIOps和RCA的趨勢是：

1）多模態數據融合

2）大模型驅動決策

3）自動化修復閉環

4）端到端因果鏈追蹤

5）人機協同演進

6）動態閾值自優化

二、基于多智能體的運維體系搭建

1、順豐多智能體平臺

當前，順豐多智能體平臺的GPU集群規模已有1000+卡，通過自研GPU池化技術，可支持最新滿血版Deepseek在私有化環境中部署，內部大模型用戶達7000余人，模型服務日調用量超2億次。

2、順豐多智能體應用場景

圖片

順豐多智能體系統在運維場景中聚焦三大核心應用方向，各有明確價值：

1）根因定位

各智能體協同運用因果圖分析等方法，在業務指標異常時快速精準定位系統故障的根本原因，助力運維人員及時修復，保障系統穩定運行。

2）策略推薦

各智能體依據系統狀態、歷史數據及業務需求，為運維決策提供多樣化策略建議，使運維決策更科學高效，提升運維效率。

3）動態閾值

智能體根據系統實時數據和歷史趨勢，自動調整監控指標閾值范圍，適應業務波動和系統變化，減少誤報漏報，實現精準告警。

3、多智能體根因分析整體架構

整個項目落地將拆分成不同維度的專項，從底層往上發揮支撐作用。

圖片

專項一：多源數據融合的系統橫擬拓撲圖構建

構建整合CMDB、APM的統一運維數據中臺，由運維平臺研發部門提供核心支撐。

專項二：多智能體協同診斷能力建設

針對不同單告警類型進行智能體分析，確保單告警的分析效果?，F實情況下，可能會出現一個故障有告警風暴或者單個節點多告警的場景，因此要做好異常節點多告警收斂和分析。

專項三：運維知識庫和能力建設

聚焦運維知識庫搭建，整合順豐內部運維經驗與自動化告警分析系統資源。系統積累了不同基礎組件的實戰專家經驗及分析腳本，腳本融合順豐特色與外部經驗，有效提升根因定位效果。

專項四：多應用場景的AIOps運維工具落地

算法實現后與告警平臺集成，在告警處理和分析環節中通過RCA系統及AIOps平臺觸發根因定位。該算法可作為AI客服或數字化AI工程師，待內部運維知識、定位工具及核心能力完善后，其協助排查故障的效果可媲美專業運維工程師。

4、多告警根因定位流程

圖片

根因定位系統較為復雜，真實生產故障通常伴隨多個告警，需通過系統按時間維度收集告警并完成收斂。

告警收斂可采用多種算法，基礎邏輯為過濾重復和不相關的告警后開展分析，核心是識別告警關聯的依賴節點以及判斷是否存在共同依賴關系，再基于這些關系構建拓撲圖。

例如，當發生網絡設備故障時，告警風暴會影響多個節點。若這些節點均依賴同一網絡設備，則該網絡設備可能為根因節點，識別后將通過多智能體算法校驗。

但有時候告警節點未必是根因節點，需借助大模型算法溯源。結合現狀、收集的數據以及運維經驗判斷非根因節點時，架構師與運維人員會參與決策，例如溯源上游或下游節點校驗，持續溯源直至定位根因節點。

5、多智能體協同機制

在多智能體系統的協同機制中，采用“架構師Agent為核心+多領域專屬Agent分工協作”的模式：

• 架構師Agent：承擔核心協調者與決策者角色，負責系統級架構研判和整體策略制定，對各領域Agent的分析結果進行整合判斷，決策下一個分析節點。
• 領域專屬Agent：圍繞架構師Agent，細分出告警分析、云日志、APM鏈路、基礎組件、基礎監控、數據庫分析等6類專屬Agent，每類Agent均具備獨立大模型能力、專屬知識庫及數據獲取接口。例如，告警分析Agent可提取“磁盤滿”等告警根因信息并通過大模型分析現象與原因；基礎監控、數據庫、云日志等領域的專屬Agent，能針對各自技術組件（如Redis、MySQL、ES等）開展精細化功能分析。

通過這種機制，各Agent分工明確且協同高效，共同完成故障根因定位等復雜運維任務。

三、大模型落地多場景根因定位系統

1、復雜場景RCA系統架構設計

圖片

復雜場景RCA系統按照“四個專項”的路徑分步實現：

1）中臺數據準備

先推進運維數據中臺建設，完成APM、CMDB、告警及上下游查詢接口的搭建，夯實多源數據融合的基礎；

2）運維知識整合

同步整合運維知識，為智能體提供知識支撐；

3）多智能體實現

基于數據和知識，開發多個領域專屬智能體，實現多智能體協同診斷；

4）產品工具集成

將智能體與運維工具集成，例如針對順豐內部UIOC系統或線上生產故障場景，自動觸發工具完成定位排查，實現工具鏈的智能化落地。

2、AIOps 的關鍵指標

圖片

AIOps的關鍵指標從四個維度展開：

1）數據處理能力

AIOps平臺高效收集、整合和預處理多源異構數據，為分析決策提供全面準確的數據基礎，實現對IT運維狀態的精準把控。

2）定位有效性

借助智能算法快速精準定位故障根因，提升運維效率，減少系統故障時間，保障業務連續性和穩定性。

3）自動化響應

基于分析結果自動觸發響應措施，如自動調整資源配置、重啟服務等，減少人工干預，提升運維效率和系統可用性。

4）可解釋性

直觀展示運維數據和分析結果，確保智能分析和決策過程的可解釋性，增強運維人員對系統的信任和使用效果。

3、告警收斂和異常節點篩選

圖片

該根因定位系統以覆蓋真實生產故障場景為目標 —— 當生產故障發生時，會同步涌現大量告警與異常節點，需通過告警收斂和異常節點篩選，依據依賴關系定位可疑根因節點后開展溯源。其算法流程如下：

先收集告警，再通過告警類型、節點篩選等多種方法完成收斂。以CPU利用率告警為例，70%、80%、90% 閾值可能觸發含義相同的告警，因此需要重新分析這類告警，保留最早出現的記錄，只針對CPU高負載的首次告警時間開展分析。

告警映射至多個節點，采用傳統多維分析算法對各告警節點打分排序。打分需結合告警數量、節點圖中重要性、告警異常鏈路最短路徑等權重因素，經指標加權計算后選取Top-n節點。

針對Top-n節點，可基于海量告警篩選可疑根因節點開展分析。單個節點存在多告警時，先完成同類聚合，再由對應不同告警類型的智能體分別分析，統一通過大模型輸出報告。

4、告警分析應用效果

圖片

統一告警面板：

告警觸發后，系統按類型調用對應智能體（如Deepseek）或其他知識庫獲取數據，再由大模型生成總結。

5、根因定位應用效果

圖片

根因定位系統：

系統會按時間維度收集告警并完成收斂，將告警節點映射至圖表，借助CMDB圖數據庫開展多維分析，篩選出權重較高的Top 3節點分別生成分析報告。

此過程主要依托Deepseek與Agent能力，分析節點的異常特征、API信息是否有調用鏈等問題，以及錯誤日志能否提取有效信息。

錯誤日志往往數量龐大且存在重復告警，需進行聚類分析。多數告警與數據庫連接相關，據此可定位當前節點連接的數據庫或外部依賴存在問題，所以該節點可能為根因節點。針對根因節點，系統會生成策略推薦，如重啟或回滾操作。

6、多模態大模型集成與人機協同

圖片

人工定位分析時，專業運維可直接識別圖表拐點及異常信息，大模型雖具備此能力，但受限于推理成本與效率尚未廣泛應用。技術上，通過圖像大模型提取基礎監控異常信息具備可行性，這一方向已納入探索范圍。

人機交互方面，人工臺賬包含大量交流信息，無需手動輸入模型讓其生成回答。基于ASR或TTS模型，可實時獲取作戰實驗與作戰會議室中的信息，這些信息既可作為模型的輸入，也能通過TTS轉化為語音輸出，輔助根因定位。

7、MCP 市場與運維工具集成

圖片

順豐搭建了自己的MCP市場，其中AIOps運維工具會集成MCP開發能力，同時開發運維工具MAC Server。技術組件或運維平臺開發者可封裝大量運維接口，封裝后所有算法和智能體通過MCP統一協議進行對照對接。

8、落地價值與技術難點

圖片

1）落地價值

①提升運維效率：快速定位故障根因，減少排查時間，加快故障恢復速度。

②保障業務連續性：及時發現并解決故障，避免業務中斷，保障企業運營與收益。

③優化資源配置：通過根因分析發現資源問題，為資源分配和優化提供依據。

④積累經驗知識：將故障處理經驗轉化為可復用知識，構建知識庫，提升團隊運維能力。

2）技術難點

①數據采集與關聯：需采集多源異構數據，確保數據準確、完整，建立數據關聯以形成服務閉環和調用鏈路。

②算法與模型：故障場景復雜，需平衡算法準確率與性能，避免系統資源過度消耗。

③實時性要求：故障根因定位需在短時間內完成，對系統實時性要求極高。

④系統復雜性與動態性：系統結構復雜且動態變化，故障傳播路徑和影響范圍難以預測。

四、Deep Seek 等大模型優化與實踐

1、運維體系搭建和大模型集成

運維體系包含四大核心模塊：

1）運維中臺：整合資源，提供運維數據中臺查詢接口等基礎能力

2）自動化工具：DevOps平臺支持自動化執行，提升運維效率

3）智能體平臺：多智能體為核心支撐，承載大模型與智能體協作

4）根因定位：在智能體平臺實現算法，精準定位系統故障根因

2、私有化大模型部署與優化

圖片

1）私有化部署

出于內部運維數據與知識庫的安全性考量，私人采購GPU的性能難以跟上行業快速發展的節奏。因此可通過混合云技術部署Deepseek等大模型，將所有數據均存儲于本地。這樣既保障長期使用，又降低成本。

2）推理優化

目前順豐與多家云廠商合作，通過PD分離等方案提升KV緩存與優化推理框架。此外，Deepseek的MTP技術也將用于此，來提高大模型的響應速度。

3、DeepSeek 與 RCA 結合場景

1）多告警收斂

大模型通過語義理解關聯多類告警，壓縮冗余噪音，提升告警有效性。

2）日志分析優化

大模型在日志分析中表現優異，因此會將智能體與功能模塊進行拆分。對于無法通過規則匹配的日志，將基于大模型進行信息提取與判斷。

3）根因節點溯源

根因節點溯源采用Deepseek大模型，用于判斷節點是否具備足夠的數據支撐其為根因節點。若該節點不是根因節點，則排查其上下游依賴，結合節點健康度及自身信息進一步判斷。例如，報告提示MySQL連接存在問題時，如果其下游存在MySQL節點，大模型可快速定位需溯源的下游節點。

4）時序數據分析

涵蓋異常檢測與持續數據分析場景。

5）多智能體協同

通過多Agent規劃和協作，利用全局信息優化每個智能體的輸出報告。

4、RCA 與策略推薦效果提升

1）提示詞工程

目前使用私有化部署Deepseek-V3 685B大模型，優化提示詞后根因定位有效性提升36% 以上，推薦準確率提升50% 以上。

2）知識庫集成

知識庫與運維經驗的引入同樣關鍵。此前基于圖的算法缺乏運維經驗支撐，只是依據圖的配置端口與告警數量開展權重分析。實際場景中，部分告警治理不完善，存在節點重復告警、告警量冗余且重要性不均的問題。

對告警重要程度的判斷基于自身的運維經驗。借助健康度相關的運維經驗與判斷邏輯，通過接口接入，可將根因定位準確率提升29% 以上。

3）多智能體協同

在AIOps平臺中，智能體協同方案的效果顯著優于單智能體方案，且大幅超越基于復雜規則的算法方案，其核心目標是將根因定位準確率提升至90%。

Q&A

Q1：哪些數據適合微調，哪些數據適合RAG，包括決策樹、專家經驗或分析CoT等，如何進行分類？多Agent協同時，應選擇集中式執行，還是采用動態調度？

A1：微調與知識庫并不沖突。特定業務場景下，為保證業務效果會開展微調；而當知識庫體量較大，無法全部嵌入提示詞時，我們會從知識庫構建、提示詞優化等維度進行調優。

根因定位場景中，我們目前未進行微調。順豐內部微調實踐多用于意圖識別及物流垂類模型，解決意圖識別問答任務，該場景對響應延遲要求高。由于7B參數規模的模型微調效果有限，因此微調更適用于對性能敏感、且需沉淀內部知識的場景。

目前順豐RCA場景未開展微調且短期無計劃，當前微調成本非常高，72b及更小參數模型微調效果未必優于通用大模型。

我們了解并探索過了多種相關算法，曾嘗試使用Swarm或OpenAI等公司提供的標準Agent SDK，借助大模型能力調度Agent。這個過程需明確了各Agent能力定位，給出具體場景供其選擇工具或進行Agent間的協同，但實際效果較差。

當前大模型無法將任務場景拆解為多個步驟，無法自動選擇不同Agent完成任務，因此整個多智能體協同架構中仍依賴人工邏輯設計。在具體場景中，例如遇到APM類報警或節點API異常時，會通過硬編碼調用APM智能體分析，統一收集各智能體結果后，再由架構師Agent判斷是否找到根因，目前相關工作流協作機制都是通過硬編碼或工作流實現。

Q2：大模型通常為觸發式調用，如何與日志分析、時序數據異常檢測這類需要實時監控的場景相匹配？其背后的工作機制是怎樣的？

A2：我們并非對所有告警都調用大模型。多數告警可自動處理或運維人員直接識別，大模型分析采用后置觸發模式。收到告警并初步獲取一些自動化圖表信息后，由運維手動觸發AI根因分析。

動態閾值采用圖像識別算法，因需提前計算各指標次日每分鐘上下邊界閾值，指標量極大，所以主要采用了傳統時序象限圖、三周同比等方法計算基礎閾值，而不使用大模型進行大規模計算。當閾值觸發后，也會對該異常點進行二次分析，再通過CV等大模型微調或訓練后的二分類模型來判斷其合理性。

作者介紹

陳迪豪，順豐科技AI技術平臺負責人。目前負責順豐科技AI和大模型基礎設施建設，曾任第四范式平臺架構師和OpenMLDB項目PMC、小米云深度學習平臺架構師以及優思德云計算公司（UnitedStack）存儲和容器團隊負責人。活躍于分布式系統、機器學習相關的開源社區，也是HBase、OpenStack、TensorFlow等開源項目貢獻者。