在正式進入AIOps實踐之前，先簡單普及下相關(guān)的理論知識，我們會從以下幾個方面進行介紹：

• 從精益、敏捷、DevOps到AIOps
• 什么是AIOps
• 大模型和AIOps
• AIOps算法和應(yīng)用案例

從精益、敏捷、DevOps到AIOps

不論是產(chǎn)品設(shè)計、開發(fā)甚至是運維，其都是圍繞應(yīng)用的生命周期做管理，那就存在設(shè)計、開發(fā)、測試、運維等階段。在這些階段中就會涉及到一些精益思想、敏捷開發(fā)、DevOps等相關(guān)指導(dǎo)思想，我們下面對其一一做簡要介紹。

什么是精益

精益思想起源于制造行業(yè)，最早是由豐田公司實踐并發(fā)展起來，旨在消除浪費、優(yōu)化流程以最大化價值交付。在整個精益的發(fā)展歷程中，戴明博士起到了非常重的作用，他提出的組織管理的14條基本原則在眾多的精益實踐中都有戴明博士的影子，比如在豐田公司，在打造豐田精益體系的時候，就是借鑒戴明博士關(guān)于質(zhì)量控制、流程優(yōu)化等多方面理念。

簡單來說，精益管理是一種旨在提高效率和優(yōu)化流程的管理方法，其主要要素可總結(jié)為以下幾個方面：

• 價值（Value）： 將焦點放在滿足顧客需求和提供對顧客有價值的產(chǎn)品或服務(wù)上。精益管理強調(diào)明確價值的定義，即顧客愿意為之付費的特定產(chǎn)品或服務(wù)特征。
• 價值流（Value Stream）： 價值流是指從原材料采購到最終交付給顧客所涉及的全部過程。精益管理要求組織全面了解價值流，識別其中的瓶頸和浪費，以便進行優(yōu)化。
• 流程優(yōu)化（Flow）： 通過消除浪費和改進流程，使產(chǎn)品或服務(wù)的生產(chǎn)與交付過程更加高效順暢。其目標(biāo)是實現(xiàn)無阻滯的價值流動，從而縮短生產(chǎn)周期、減少庫存，提高交付速度。
• 拉動（Pull）： 拉動是指根據(jù)顧客需求來進行生產(chǎn)與供應(yīng)，而非根據(jù)內(nèi)部預(yù)測或批量生產(chǎn)。精益管理倡導(dǎo)「按需生產(chǎn)」，通過拉動機制確保只有在真正需要時才進行生產(chǎn)，以避免產(chǎn)生過剩庫存和不必要的浪費。
• 消除浪費（Eliminate Waste）： 浪費是精益管理中的敵人。其中七大浪費包括：過度生產(chǎn)、庫存、運輸、過程中的等待、過度加工、不必要的動作和修正、未充分利用員工的潛力。通過消除這些浪費，組織能夠更有效地利用資源。
• 人才與培訓(xùn)（Respect for People）： 精益管理強調(diào)尊重員工，認識到員工是組織最重要的資產(chǎn)之一，并鼓勵員工參與流程優(yōu)化和問題解決，提供培訓(xùn)和發(fā)展機會，以建設(shè)學(xué)習(xí)型組織。

圖片

什么是敏捷開發(fā)

瀑布開發(fā)

在敏捷開發(fā)大范圍普及之前，瀑布開發(fā)在早期被廣泛的采用，它要求有明確的需求，大家按照需求一步步做好規(guī)劃，每一階段工作的完成是下一階段工作開始的前提，每一階段都要進行嚴(yán)格的評審，保證各階段的工作做得足夠好時才允許進入下一階段，它適用于需求明確的項目。

在瀑布開發(fā)模式下是存在一些局限性，主要有：

• 缺乏靈活性：按照固定的順序線性開發(fā)，每個階段都有明確的開始和結(jié)束時間，這種開發(fā)流程無法適應(yīng)快速的需求變化和靈活性要求。
• 長時間的交付周期：要求進入下一個階段之前完成上一階段的所有工作，導(dǎo)致項目的交付周期長。如果需求發(fā)生變化或者出現(xiàn)問題，則可能需要回到前面的階段。
• 高風(fēng)險：測試和部署通常在開發(fā)的最后階段執(zhí)行，這意味著問題只能在開發(fā)結(jié)束后才會被發(fā)現(xiàn)，這導(dǎo)致修復(fù)問題的時間成本會很高，增加項目失敗的風(fēng)險。
• 缺乏協(xié)作和溝通：不同團隊的成員在不同階段工作，他們之前的溝通和協(xié)作較少，導(dǎo)致信息傳遞不常、問題未能及時發(fā)現(xiàn)和解決。
• 無法快速響應(yīng)市場的需求：需要等整個項目完成才能交付產(chǎn)品，無法及時響應(yīng)市場的需求變化，在快節(jié)奏的的市場環(huán)境中，容易出現(xiàn)無法滿足需求的情況。

敏捷開發(fā)

在瀑布開發(fā)模式越來越滿足不了快速的市場變化的情況下，在精益思想的指導(dǎo)下，敏捷開發(fā)模式應(yīng)運而生。敏捷開發(fā)是一種小步快跑的開發(fā)模式，它是一種以用戶需求進化為核心、倡導(dǎo)擁抱變化、循環(huán)迭代、循環(huán)漸進的開發(fā)方法。 首先把用戶最關(guān)心的軟件原型做出來并交付給用戶，用戶在實際場景中發(fā)現(xiàn)問題并給予反饋，研發(fā)人員快速修改彌補需求中的不足。上述過程不斷迭代，直到用戶滿意。

敏捷追求“更早地交付價值，更靈活地應(yīng)對變化”，適用于需求不明確、創(chuàng)新性或者需要搶占市場的項目，特別適合互聯(lián)網(wǎng)項目。

圖片

相較瀑布開發(fā)模式，敏捷開發(fā)有以下不同：

• 敏捷開發(fā)模式是一個循環(huán)的過程，將交付周期拆分成多個小的迭代，以持續(xù)且連續(xù)的方式進行。
• 敏捷開發(fā)在每個周期完成后立即進行部署，隨后可以快速響應(yīng)用戶的反饋，再進行分析評估以進入下一個階段的設(shè)計、開發(fā)以及測試。
• 敏捷開發(fā)強調(diào)的是快速響應(yīng)變化，持續(xù)交付可用的軟件以及項目進程中不斷獲取應(yīng)用和用戶的反饋，以優(yōu)化產(chǎn)品。

圖片

但是，隨著敏捷的不斷踐行，在應(yīng)用的整個生命周期中還是會有環(huán)節(jié)不堪重負，那就是運維環(huán)節(jié)，主要表現(xiàn)以下幾點：

1. 運維團隊不堪重負：面對開發(fā)團隊日益增長的發(fā)布次數(shù)需求，運維團隊因人力和精力限制感到壓力巨大。
2. 工作時間盲目增加：為了滿足開發(fā)團隊的高頻發(fā)布要求，運維團隊開始在周末加班和通宵工作，過度依賴延長工作時間來提高發(fā)布頻率。
3. 穩(wěn)定性下降：運維團隊過度關(guān)注發(fā)布次數(shù)而非效率，導(dǎo)致線上穩(wěn)定性受團隊文化和工作環(huán)境影響而下降，質(zhì)量問題和穩(wěn)定性問題開始顯現(xiàn)。
4. 建立部門墻：為維護自身利益和保證發(fā)布質(zhì)量，運維團隊開始限制發(fā)布速度，比如一周僅限發(fā)布一次，試圖通過建立部門墻來避免背鍋和責(zé)任。

其中，建立部門墻是整個敏捷實行過程中最大的問題了。

1. 敏捷模式的局限性導(dǎo)致開發(fā)團隊和運維團隊的目標(biāo)與訴求不一致，開發(fā)團隊追求變化，而運維團隊追求穩(wěn)定，盡量減少發(fā)布。
2. 環(huán)境差異使得開發(fā)團隊在本地測試正常的情況下，線上發(fā)布時出現(xiàn)問題，導(dǎo)致兩個部門間的溝通障礙和部門墻加劇，協(xié)作效率降低。
3. 開發(fā)團隊在采用敏捷工具后變得敏捷，但運維團隊仍依賴手工操作進行變更，這種不敏捷的狀態(tài)導(dǎo)致故障處理時間延長。
4. 運維團隊對業(yè)務(wù)邏輯不熟悉，當(dāng)生產(chǎn)環(huán)境出現(xiàn)故障時，查找問題和恢復(fù)時間較長，尤其是在更新依賴時可能引發(fā)業(yè)務(wù)問題。

圖片

所以，這就引入另一種文化：DevOps。

DevOps

DevOps代表的是將開發(fā)（Development）和運維（Operations）結(jié)合在一起的工作流程，目的是讓兩者共同負責(zé)產(chǎn)品質(zhì)量。

圖片

DevOps是一種方法論，它希望將人、流程、技術(shù)結(jié)合起來，通過借助自動化工具來優(yōu)化開發(fā)者服務(wù)，提升軟件研發(fā)的效率和質(zhì)量。

另外，精益、敏捷和DevOps三者之間是存在聯(lián)系的：

• 敏捷和精益在文化層面提供指導(dǎo)，IT管理在工具層面提供解決方案，它們共同構(gòu)成DevOps。
• 敏捷、精益和DevOps三者之間的主要聯(lián)系在于它們都致力于提升效率與質(zhì)量。
• DevOps通過集成自動化工具和流程，實現(xiàn)了對敏捷和精益原則的擴展和深化，以適應(yīng)現(xiàn)代IT管理的需求。

圖片

AIOps

DevOps 的出現(xiàn)是為了解決軟件開發(fā)與運維之間的協(xié)作障礙，致力于實現(xiàn)從開發(fā)到運維全流程的自動化、高效化，強調(diào)通過持續(xù)集成、持續(xù)交付等實踐讓軟件能夠快速、穩(wěn)定地交付和運行。而 AIOps 則是在 DevOps 基礎(chǔ)上，隨著企業(yè)數(shù)字化轉(zhuǎn)型中數(shù)據(jù)量不斷增長以及人工智能等技術(shù)逐漸成熟的背景下應(yīng)運而生的。AIOps 繼承了 DevOps 打破部門壁壘、追求高效運維的理念，并進一步借助人工智能和機器學(xué)習(xí)等技術(shù)手段，拓展了運維的深度和廣度，提升了運維的智能化水平。

圖片

AIOps有以下優(yōu)勢：

• 持續(xù)觀測監(jiān)控數(shù)據(jù)流：AIOps對數(shù)據(jù)處理的吞吐量和敏感度遠遠超過人工。
• 解決運維團隊孤島問題：AIOps能夠通過業(yè)務(wù)指標(biāo)、日志、追蹤數(shù)據(jù)關(guān)聯(lián)性隨時發(fā)現(xiàn)問題。
• 預(yù)測問題并提前解決：借助機器學(xué)習(xí)預(yù)測問題，而不是被動解決問題。
• 根因分析：借助機器學(xué)習(xí)技術(shù)快速處理大數(shù)據(jù)，并確定問題的根本原因。

圖片

要實現(xiàn) AIOps ，需要將底層的數(shù)據(jù)抽象化，便于 AIOps 能夠更高效的管理和自動化運維：

• 要將不同類型的應(yīng)用以及日志進行收集存儲
• 然后通過深度學(xué)習(xí)以及大模型的分析能力對數(shù)據(jù)進行建模分析
• 最后借助聲明式將運維能力進行接口抽象化，便于維護管理

圖片

大模型和AIOps

隨著 GPT 這類大模型的不斷發(fā)展，使得數(shù)據(jù)分析和建模變得更加容易，降低了技術(shù)門檻，促進了AI技術(shù)在運維領(lǐng)域的普及和應(yīng)用，它能夠輕松編寫如時序預(yù)測、分類等AI算法，簡化了數(shù)據(jù)建模的過程，加速了AIOps的落地實踐。

就拿根因分析來說，在傳統(tǒng)的方式中，需要根據(jù)時間軸去查看所有的指標(biāo)數(shù)據(jù)、日志內(nèi)容，然后通過不斷下鉆的方式去分析原因，這種方式需要大量的專家經(jīng)驗，并且準(zhǔn)確率還不是很高。

圖片

在大模型的加持下，我們可以借助大模型的agent技術(shù)對指標(biāo)、日志、鏈路等多模態(tài)運維數(shù)據(jù)進行混合分析，然后輸出分析結(jié)果。再結(jié)合運維專家的內(nèi)部知識庫，還可以找到對應(yīng)的解決辦法，提升問題解決的效率和準(zhǔn)確性。

圖片

隨著大模型和AIOps的結(jié)合，誕生了一種新的交互方式——以自然語言為核心的人機交互。這種交互方式避免了傳統(tǒng)上的UI界面、鼠標(biāo)操作、命令行或者API方式的局限。在這種模式下，用戶只需要用自然語言描述需求，大模型將對應(yīng)的語義轉(zhuǎn)換為函數(shù)調(diào)用的參數(shù)，比如用戶希望查詢app=grafana的CPU使用情況指標(biāo)數(shù)據(jù)，大模型可以將其轉(zhuǎn)化為getMetrics({ app: "grafana", metric: "cpu_usage" })。

在大模型中，Agent可以理解為某種能自主理解、規(guī)劃決策、執(zhí)行復(fù)雜任務(wù)的智能體，它能夠感知其環(huán)境，通過自己的決策和行動來改變環(huán)境，并通過學(xué)習(xí)和適應(yīng)來提高其性能。

要利用好大模型，就需要打牢五層基石：

• 第一層就是模型，我們常見的就是各種大模型，然后通過API去調(diào)用，發(fā)出一個指令，然后大模型根據(jù)你的指令返回一些結(jié)果。
• 第二層是 prompt模板，我們在prompt中可以引入一些變量，動態(tài)地為大模型提供額外上線文或參考知識。
• 第三層就是鏈?zhǔn)秸{(diào)用。我們通過chain 把多次大模型調(diào)用串聯(lián)起來。使用的主要場景是將上一次的模型輸出作為下一個模型的輸入。這樣就能很好對大模型的一些缺陷進行一個彌補，或者是能完成更加復(fù)雜的一些工作。
• 第四層就是Agent，能自主執(zhí)行鏈?zhǔn)秸{(diào)用，通過工具對外部環(huán)境產(chǎn)生作用。既能告訴你怎么做，還能幫你做。
• 第五層就是多Agent 協(xié)助，問題拆機，自動分工協(xié)作，幫人類完成更復(fù)雜的任務(wù)。

圖片

其中使用到的核心技術(shù)主要有：

• Prompt Enginnering：提示詞的質(zhì)量決定輸出的質(zhì)量
• JSON Model：大模型穩(wěn)定的輸出格式，以便于與程序之間的連接和編碼操作。
• Function Calling：函數(shù)調(diào)用，它通過將方法封裝成函數(shù)調(diào)用來實現(xiàn)鏈?zhǔn)秸{(diào)用和前置意圖識別等功能。
• RAG：檢索增強生成，通過構(gòu)建個人知識庫或運維專家智庫，解決大模型的業(yè)務(wù)理解和幻覺問題。
• Fine-tuning：微調(diào)

當(dāng)然，當(dāng)前情況下要將大模型應(yīng)用到 AIOps 還存在不小的挑戰(zhàn)，主要表現(xiàn)如下：

• 運維場景是非常嚴(yán)肅的場景，絕大多數(shù)情況下錯誤零容忍的，但是當(dāng)前大模型幻覺問題還無法完全解決
• 運維數(shù)據(jù)有非常高的私密、安全性。大多數(shù)的場景是不允許使用外部公開的模型，避免數(shù)據(jù)泄露，所以需要企業(yè)獨立部署大模型，不論是模型維護還是成本支出都有不小的挑戰(zhàn)。
• 多數(shù)企業(yè)都缺少高標(biāo)準(zhǔn)的企業(yè)數(shù)據(jù)、知識庫，這會降低大模型的訓(xùn)練質(zhì)量。
• 現(xiàn)在的大模型由于上下文Token以及成本原因?qū)е潞茈y處理大量的實時數(shù)據(jù)。

AIOps 算法和應(yīng)用案例

AIOps 常用的算法主要有：

• 統(tǒng)計分析算法：ANOVA、標(biāo)準(zhǔn)差、t檢驗、皮爾遜相關(guān)系數(shù)、箱型圖
• 時序分析和預(yù)測算法：SARIMA、LSTM、Prophet
• 機器學(xué)習(xí)分類和回歸算法：決策樹、SVM、K近鄰、梯度提升
• 異常檢測和變更點檢測算法：孤立森林、K均值聚類、DBSCAN

通過對這些算法的綜合利用，可以實現(xiàn)對復(fù)雜系統(tǒng)的全面監(jiān)控和智能分析，提升運維效率。比如在故障預(yù)警方面，通過采用LSTM算法可以學(xué)習(xí)歷史數(shù)據(jù)預(yù)測潛在的風(fēng)險，提前進行預(yù)警通知，減少故障發(fā)生。

再比如利用日志聚類算法對日志進行自動分類，通過機器學(xué)習(xí)識別相同模式的日志，可以快速掌握系統(tǒng)狀態(tài)并實現(xiàn)對海量日志的分類與分析。

圖片

基于 RAG 的根因分析

基于 RAG（Retrieval-Augmented Generation，檢索增強生成） 的 根因分析（Root Cause Analysis, RCA） 是當(dāng)前 AIOps（智能運維）、故障診斷、日志分析等領(lǐng)域的前沿應(yīng)用方向。它結(jié)合了信息檢索和大語言模型的推理能力，可以在復(fù)雜系統(tǒng)中快速定位問題的根本原因。

主要的應(yīng)用場景有：

RAG是什么

RAG 是一種結(jié)合“檢索”和“生成”的技術(shù)架構(gòu)：

1. 檢索（Retrieval） ：從知識庫中查找相關(guān)上下文信息。
2. 生成（Generation） ：使用大語言模型（LLM）基于檢索結(jié)果進行推理并輸出結(jié)論。

圖片

RAG的實現(xiàn)流程

RAG整體流程可以分為兩個階段：

• 數(shù)據(jù)準(zhǔn)備階段
• 數(shù)據(jù)查詢階段

1、數(shù)據(jù)準(zhǔn)備階段

a. 收集故障數(shù)據(jù)（知識庫構(gòu)建）

• 歷史故障記錄
• 日志樣本
• 告警信息
• 操作手冊
• 維護記錄
• SRE 或 DevOps 團隊的經(jīng)驗文檔

b. 對數(shù)據(jù)進行處理

• 清洗、標(biāo)準(zhǔn)化
• 分段成 chunk（如每條日志為一個 chunk）
• 使用 Embedding 模型將文本向量化（如 BERT、Sentence-BERT、SimCSE）

c. 存入向量數(shù)據(jù)庫

• FAISS
• Milvus
• Weaviate
• Elasticsearch (dense vector)

2、數(shù)據(jù)查詢階段

a. 用戶輸入

"服務(wù) user-service 出現(xiàn) 503 錯誤，QPS 下降 80%，日志顯示 connection timeout"

b. 檢索模塊

• 將用戶輸入嵌入為向量
• 查詢向量數(shù)據(jù)庫，找到最相似的歷史案例

示例返回：

【案例】user-service 出現(xiàn)連接超時，原因為數(shù)據(jù)庫主節(jié)點宕機，導(dǎo)致連接池耗盡。
【解決方案】切換數(shù)據(jù)庫到備節(jié)點，并重啟服務(wù)。

c. 生成模塊（LLM）

• 輸入：用戶原始問題 + 檢索到的上下文
• 輸出：結(jié)構(gòu)化根因分析報告，例如：

{
  "root_causes": [
    {
      "reason": "數(shù)據(jù)庫主節(jié)點宕機",
      "evidence": ["connection timeout", "db ping failed", "replica lag"],
      "probability": 0.92
    }
  ],
  "suggested_actions": [
    "檢查數(shù)據(jù)庫主節(jié)點狀態(tài)",
    "切換數(shù)據(jù)庫到備節(jié)點",
    "重啟 user-service"
  ]
}

圖片

這其中涉及的關(guān)鍵技術(shù)組件有：

總結(jié)

全文圍繞《AIOps》相關(guān)知識展開介紹，通過對理論知識的整理，可以初步建立一個 AIOPS 的概念：

1. 從精益、敏捷、DevOps 到 AIOps：

精益：源于制造行業(yè)，由豐田公司實踐發(fā)展，旨在消除浪費、優(yōu)化流程等，其要素涵蓋價值、價值流、流程優(yōu)化等多方面，是一種提高效率和優(yōu)化流程的管理方法。

敏捷開發(fā)：在瀑布開發(fā)難以滿足市場變化時，在精益思想指導(dǎo)下產(chǎn)生，以用戶需求進化為核心、倡導(dǎo)擁抱變化等，對比瀑布開發(fā)有諸多不同，但在應(yīng)用生命周期中運維環(huán)節(jié)存在一些問題，進而引出 DevOps。

DevOps：將開發(fā)和運維結(jié)合的工作流程，是一種方法論，借助自動化工具優(yōu)化開發(fā)者服務(wù)，提升軟件研發(fā)效率和質(zhì)量，與精益、敏捷存在緊密聯(lián)系。

2. AIOps：在 DevOps 基礎(chǔ)上，隨著企業(yè)數(shù)字化轉(zhuǎn)型及人工智能技術(shù)成熟應(yīng)運而生，繼承 DevOps 理念并借助相關(guān)技術(shù)提升運維智能化水平，具有持續(xù)觀測監(jiān)控數(shù)據(jù)流等優(yōu)勢，實現(xiàn)它需對底層數(shù)據(jù)進行相應(yīng)處理。
3. 大模型和 AIOps：大模型發(fā)展促進了 AIOps 的落地實踐，二者結(jié)合誕生新交互方式，利用大模型需打牢五層基石，涉及多種核心技術(shù)，不過當(dāng)前將大模型應(yīng)用到 AIOps 還面臨如大模型幻覺、數(shù)據(jù)安全等挑戰(zhàn)。
4. AIOps 算法和應(yīng)用案例：介紹了 AIOps 常用的幾類算法，如統(tǒng)計分析算法、時序分析和預(yù)測算法等，通過綜合利用這些算法可提升運維效率，并以故障預(yù)警、日志聚類算法為例說明應(yīng)用情況。還著重闡述了基于 RAG 的根因分析，包括其應(yīng)用場景、RAG 是什么、實現(xiàn)流程以及涉及的關(guān)鍵技術(shù)組件等內(nèi)容。

下面再分享一個常見的 AIOps 實現(xiàn)流程：

圖片