云棲實錄：重構可觀測 - 打造大模型驅動的云監控 2.0 與 AIOps 新范式

云監控 2.0 歷經一年半的演進，已經完成了 ARMS、容器監控（Prometheus）、企業云監控的大部分系統整合、存儲遷移等工作，剩余的 SLS CloudLens、基礎云監控等也在下半年逐步遷移規劃中。

作者：司徒放（姬風）

縱觀技術發展，每一次技術范式的遷移，都會重塑一個領域。正如云原生時代，將“監控”演進為“可觀測”；如今，大模型時代的到來，也正驅動著可觀測走向下一輪顛覆式變革。我們看到，AI 正在重塑軟件開發，催生了全新的 AI Coding 的編程模式。那么，用 AI 簡化運維復雜度的智能運維，所謂 AI Operation（AIOps）也必然是時代的趨勢。

其實，AIOps 不是新概念。早在 2017 年，Gartner 就提出了這個愿景，希望實現運維領域的自動駕駛。然而，過去的 AIOps 普遍受限于三大瓶頸：僵化的規則引擎、嚴重的數據孤島以及高昂的定制化成本，導致其長期難以大規模落地。但如今大模型的出現，為我們突破這些瓶頸帶來了曙光，讓 AIOps 真正走到了即將突破的臨界點。

為什么我們會認為 AIOps 即將迎來臨界點呢？這取決于三個關鍵因素的成熟，它們共同構成了這一次 AIOps 突破的基礎：

首先，是高質量數據。這是 AIOps 的第一性原理。數據不僅要準確，而且要多維，有統一語義，互相關聯，這樣才能被 AI 有效理解和推理，否則就是“Garbage in, garbage out”。

其次，是彈性算力。無論是應對海量數據的實時處理，還是在定位問題時進行深度分析，都需要一個能按需伸縮的強大計算存儲平臺作為支撐，而這正是云時代帶來的核心優勢，也是目前我們解決得比較好的問題。

最后，也是最關鍵的，是大模型。大模型在通用知識與推理能力上的涌現，讓它不再是過去那種需要大量標注和訓練的“小模型”，而是真正具備了理解運維場景的通識能力。

在大模型時代，要真正滿足這三個關鍵因素，我們必須首先解決兩個棘手問題：

• 數據的駕馭問題：當可觀測數據從 TB 邁向 PB 甚至 EB 級別時，我們該如何駕馭這片異構、實時的數據海洋，讓數據能夠為我們所用？
• 認知的對齊問題：我們該如何彌合大模型的通用智能與運維領域的專業知識之間的鴻溝，讓 AI 真正“看懂”我們的系統？

數據的駕馭問題

當我們將 AIOps 應用于海量可觀測數據時，海量、異構、實時的可觀測數據會產生三個挑戰：

• 異構系統的孤島困境：企業內部往往有著各種監控系統，這些系統接口與權限各異，大模型很難進行有效的跨域分析，在分析排查時，就無法獲得必需的完整上下文，就有如盲人摸象，局限在局部信息，根因定位很難成功。
• 數據洪流的承載瓶頸：可觀測數據正經歷爆炸性增長，給平臺帶來了巨大壓力。這個壓力，即包含數據接收的承載壓力，也包含數據存儲的成本壓力，還包含計算時的資源壓力。要么犧牲數據完整性（如采樣丟棄），要么承擔高昂成本。這個存不下、算不起的瓶頸，在問題分析時，就會極大地限制 AIOps 的使用。
• 海量數據的算力黑洞：我認為這是一個典型的技術路徑錯配問題。看到業界一些嘗試是讓大模型直接處理海量、價值密度不均的原始數據（例如：直接讓模型去分析系統日志，這得多有錢），這不僅會瘋狂消耗昂貴的 GPU 算力，而且分析效率極低，最終導致投入產出比完全失衡。

要解決數據難題，必須有一個強大的平臺，一個能支撐好 AIOps 場景的統一可觀測數據平臺。這個平臺，我們圍繞日志服務 SLS 為核心引擎去構建，能夠統一支持日志、指標、鏈路、事件、性能剖析等可觀測數據。它徹底解決了數據難題：

• 采集側，統一數據接入，以打破孤島：我們提供了覆蓋從移動端到基礎設施，從傳統應用到最新的 AI 應用框架等 200 多種組件的全棧、實時、無侵入的數據接入能力。無論是日志、指標還是鏈路，每天上報數百 PB 數據，都能被匯入一個平臺，為后續 AI 分析提供了完整的全局上下文。
• 服務端，統一數據加工與存儲，以應對洪流：SLS 具備全球可用的高彈性高可靠架構，能承載每日 EB 級的存儲規模，秒級千億行查詢，數百億行分析，百萬時間線計算能力。通過豐富、靈活、強大的數據加工能力和存儲冷熱分層技術，在保障數據完整性的同時，將綜合成本較自建方案降低 50% 以上。

而且，我們堅持秉承數據開源開放原則，所有數據都符合標準開源協議規范（指標符合 Prometheus 標準，鏈路符合 OpenTelemetry 標準，事件符合 CloudEvents 標準，使用表格模型均支持 SQL 查詢），存儲在客戶租戶下的 SLS Project 內，客戶可以自行進行自定義分析或導出。另外，默認會采用三副本存儲，在符合條件的地域，免費啟用 3AZ 同城冗余，這是業界獨一份的存儲高可靠性。基于一個數據平臺的持續建設，讓我們的數據能夠“存得下、存得好、存得起”。

有了統一的平臺，我們如何解決“算力黑洞”的問題？

我們的核心理念是：計算下推。不要把海量原始數據喂給大模型，而是將模型的分析意圖下推到底層數據引擎去執行。為此，我們沉淀了大量高效的通用算子+可觀測數據算子。可觀測算子就像一把把鋒利的手術刀，專門用于處理特定數據場景。例如指標數據，有豐富的異常檢測、預測、聚類、維度下探算法；鏈路數據，有專門針對鏈路的異常分析、維度下鉆，也有對多調用鏈構成的拓撲進行構造和對比分析的算子。由此一來，在實際工作中，大模型只需要扮演智能調度的中樞角色。它接到任務后，會調用這些強大的算子在數據源頭進行預處理和關鍵特征提取。只有高價值信息才會被提交給大模型進行最終的推理和決策。

這種方式，將大模型的推理能力和平臺強大的數據處理能力完美結合，將 Token 消耗降低 90% 以上，讓 AIOps 真正變得高效且經濟可行。

認知的對齊問題

解決了數據問題，我們再來看 AIOps 面臨的第二個、也是更深層次的難題 - 認知。從本質上是如何彌合大模型的通用智能與運維領域的專業知識之間的鴻溝。具體來說，我們會面臨三大挑戰：

• 運維領域的語義鴻溝：當用戶提問“服務有抖動沒？數據庫還健康嗎？CPU 有沒有毛刺？”，大模型聽不懂什么是“抖動”，怎樣算“健康”，多高算“毛刺”。這些運維“黑話”和指標之間的語義鴻溝，導致 AI 難以準確理解用戶意圖，結果自然差強人意。
• 系統拓撲的認知迷宮：現代 IT 系統依賴關系錯綜復雜。大模型缺乏對拓撲關系的認知，看到的一個個數據，都是孤立的，就沒辦法有效找到關聯的其他數據和節點。
• 根因分析的邏輯斷鏈：有效的根因分析依賴完整因果邏輯關系。而大模型面對離散數據容易產生推理幻覺，難以形成可靠的診斷結論。

如何解決這些認知挑戰？我們的答案，不是無休止地訓練運維大模型，而是為它構建一個更易于理解的“數字孿生”世界。UModel 統一模型，就是這個數字孿生的核心。它提供了一套觀測實體、以及實體關系的定義，幫助我們構建 IT 系統的數字孿生世界，覆蓋從用戶體驗、應用服務、容器到底層基礎設施的每一層。有了這張動態拓撲，排查效率將發生質變。比如，當一個應用報錯，我們就可以直接從應用下鉆到引發問題的慢 SQL，再到具體的數據庫實例；或者，我們可以跨域到它所在的 K8s Pod 和 Node 節點上。過去需要在多個系統間的手動跳轉、關聯的繁瑣操作，現在都可以在一個統一的視圖內輕松完成。

我們現在基于 UModel，已經覆蓋了 6 大核心領域、創建了 1800 多個模型，并且這是完全開放可擴展的。我認為它真正的革命性在于，它重構了可觀測世界的范式，將數據、知識、行動這三個核心要素綁定在了一起：

• 數據：它定義了“是什么”（實體）和“如何連接”（關系）。
• 知識：我們將運維領域的專業知識，如黃金指標、健康度、水位、運維手冊等，都附著在實體上。這就填平了語義鴻溝，讓 AI 能聽懂“服務抖動”的真正含義。
• 行動：我們將可執行的操作，如回滾、重啟、擴容等動作，也都附著在實體上。這就像賦予了 AI 一個工具箱，讓它知道面對問題時能對這個實體做些什么。

通過這種方式，UModel 不再僅僅是一張簡單的拓撲圖，它可以為大模型提供完整的上下文，讓大模型進化成一個能理解、會推理、可行動的“數字 SRE”，從而真正開啟了 AIOps 的新范式。我認為這是重構可觀測的重要一步。

Demo：UModel 探索與全局實體拓撲

在 Demo 之前先補充一個核心概念：實體（Entity）。如果把 UModel 理解為面向對象編程中的 Class（類），那么實體就是被實例化后的 Instance（對象）——比如一臺具體的 ECS、一個 RDS 數據庫實例、一個運行中的應用。它是我們可觀測世界里真實存在的基本單元。

點擊鏈接，查看 Demo 演示：https://mp.weixin.qq.com/s/FwtxESarMVPPhRzet7TYBA

接下來，看上面這個 Demo，它展示了基于 UModel 和 Entity 構建的三大核心拓撲視圖：

• UModel 探索：這里是整個可觀測世界的設計藍圖。它定義了“應用”、“K8s 集群”、“ECS 實例”是什么、它們和誰關聯，以及它有哪些字段，會掛載哪些指標、日志和鏈路數據。這是 2.0 實現統一可觀測的基石。
• 全局實體拓撲：它是一張全局視角的 IT 資產地圖，將所有實體按類型聚合。當技術負責人需要快速盤點全局資源，掌控整個 IT 架構的可觀測接入情況時，這就是最佳的視圖。
• 應用實體拓撲：這是為業務架構師和應用 SRE 準備的“流量拓撲圖”。它平鋪每個應用實體，清晰展現所有應用的依賴關系和流量走向，讓使用者在分析應用間影響、排查故障時，能夠鳥瞰全局。

Demo：基于實體拓撲的問題排查

點擊鏈接，查看 Demo 演示：https://mp.weixin.qq.com/s/FwtxESarMVPPhRzet7TYBA

上面這個 Demo 是一次非常典型的線上故障排查過程，全程都在云監控 2.0 的控制臺上完成，我們來快速回顧一下整個破案過程：

一切始于一個告警——網關應用的接口耗時突然飆升。我們沒有在海量日志或指標中排查問題，而是沿著云監控 2.0 自動構建的實體拓撲，開啟了上帝視角的排查。排查路徑非常清晰：從“網關應用”出發，順著拓撲的調用關系追到“訂單應用”，再到“數據庫客戶端”，最終跨越應用域的邊界，來到“數據庫服務端”。在這里，我們通過慢 SQL 日志，精準鎖定了根本原因：一次應用發布引入了未經優化的 SQL 語句，導致索引失效，引發了數據庫性能瓶頸（CPU 接近 100%）。在這里可以關注一個細節，數據庫列出幾百條慢 SQL 語句，我們通過日志聚類算法識別到事實只有三類慢 SQL，進一步簡化了問題判斷的難度。我們還需要回答“這個問題是什么時候、由哪個版本引入的”。再次回到拓撲圖，利用強大的關聯能力，從應用下鉆到其運行的 K8s 環境，沿著“Deployment -> Namespace -> K8s 集群”的路徑，順利找到了對應的發布審計日志，定位到了引入問題的鏡像版本。這是一個非常經典的業務故障案例。去年云棲大會我也錄制了一個 Demo，演示過類似的場景，當時我的核心排查武器是調用鏈。調用鏈無疑是問題排查的首選工具，對于追蹤由請求調用串聯起來的問題，它非常有效。但它的局限也很明顯——它主要工作在“流量”的世界里。當問題涉及到應用與底層基礎設施（比如 K8s 發布）的關聯時，就稍顯力不從心了。

而現在 Demo 演示的核心能力，是由 UModel 生成的統一實體拓撲。它最大的價值是打破了不同技術領域之間的壁壘，將應用、中間件、數據庫，打通到云 RDS 實例，甚至打通到底層 K8s 資源和 ECS 節點，這些都全部關聯在了一張圖上。我們的排查不再局限調用鏈，而是在一個全局的、立體的視角下進行自由穿梭和下鉆。

Demo 背后的思考

最后，也想揭示出我們在這個 Demo 背后更深層的思考：Demo 上看到的控制臺每一步點擊、每一次下鉆，其實都在模擬我們 AIOps 進行根因定位的推理過程。

我們對 AIOps 能做什么分析、排查什么問題，目標非常明確而且堅定：如果一個問題能夠被工程師在我們的控制臺上清晰地排查出來，那么在 UModel 和大模型的驅動下，它就 應當 能被大模型自動化、智能化地解決。這是我們堅守的目標。換句話說，云監控 2.0 的設計理念是什么？是讓大模型能夠看見我們所看見，能夠操作我們所操作；重構產品，是要讓用戶和大模型能夠在一個產品界面或者層次上，共同協作、互相理解。就像自動駕駛要經過漫長發展，人機共駕必不可少，AIOps 也肯定不能一步到位，還要打磨很長時間，輔助運維是必經形態。現在大模型的智能水平和對用戶看到和操作的能力覆蓋度，也遠還沒達到我說的這個階段。但相信在這個理念的牽引下，復雜問題的思考過程能夠變得簡單、直觀，大模型的能力能夠一點點逼近到我們想要的位置。

智能運維助手

如果說 UModel 為可觀測世界構建了骨架，那么我們全新升級的 AIOps Agent，就是驅動這一切的智能大腦。它的交互方式被徹底重塑。用戶可以在云監控 2.0 的任意界面，通過自然語言隨時召喚它。因為它具備全場景上下文感知，因此用戶可以直接選中一個集群（“添加到上下文”）然后提問：“這個集群最近是否穩定？列出上面業務的錯誤率排名”，Agent 能立刻理解意圖并展開分析，讓交互精準而高效。更重要的是，它的內核與眾不同。我們徹底拋棄了傳統的、基于僵化規則或流程驅動的 AIOps。AIOps Agent 采用 Agentic 架構，它能夠基于大模型進行自主規劃、調用工具、執行、反思，從而能夠解決更多開放和未知的運維難題。

這標志著，我們正從“人適應工具”的時代，邁向“工具適應人”的 AIOps 新范式。

AIOps Agent 的價值，不僅在于它的智能，更在于它重構了我們熟悉的 AIOps 核心場景。這里的關鍵詞是“重構”——這是因為我們用大模型驅動和自然語言交互的全新形態，整合和升級了最核心的四大場景：

• 智能分析：Agent 變成可觀測的數據分析伴侶，無論是復雜的調用鏈還是火焰圖，無論是應用域的問題還是云產品域的問題，都可以直接向它提問，讓它為解讀數據，并給出優化建議。
• 智能告警：Agent 可以幫助配置告警、治理告警，通過調用算法對告警進行收斂降噪（即將升級到 Agent 模式）。
• 根因洞察：當故障發生時，Agent 能幫助進行根因分析，評估影響，并生成故障總結。
• 智能巡檢：還可以讓 Agent 定時對核心業務或集群進行巡檢，從“被動救火”轉向“主動預防” （即將發布）。

那么，AIOps Agent 是怎么實現這一切的呢？智能并非空中樓閣，也無法一蹴而就，需要逐級構建在一個堅實的能力分層金字塔之上：

• 基礎查詢：這是 Agent 的“語言能力”。對 LogStore 和 MetricStore 的自然語言翻譯、智能取數。
• 拓撲感知：這是 Agent 的“認知能力”。基于 UModel，它不僅能查詢數據，更能理解數據與實體之間的關聯關系，實現關聯分析和資源盤點。
• 深度洞察：這是 Agent 的“分析能力”。它能調用各種可觀測算子，進行異常檢測、趨勢預測和模式分類，從海量數據中提煉關鍵信息。
• 輔助決策：這是 Agent 的“智慧能力”。它綜合所有底層能力，進行復雜的根因定位和變更分析，并最終給出決策建議。

正是這個層層遞進的能力棧，讓 Agent 從一個簡單的問答機器人，進化成能夠進行復雜診斷的 AIOps 分析引擎。

這個能力分層在實際工作中是如何體現的。比如，你可以問：“這個 K8s 集群上部署的 APM 應用的錯誤率排名？”，也可以選中應用 xx，讓 Agent 分析：“分析這個應用上周調用量并做后續三天趨勢預測”。當然，最重要的是進行頂層的輔助決策，你可以直接下達任務：“對 K8s 集群的進行巡檢，關注組件與資源水位”，或者在故障時直接求助：“這個應用這個小時有請求超時情況，幫我定位原因”。如你所見，這不再是固定死板的命令，而是與你的助手的真實對話。而且更多更復雜的對話能力，隨著接入 UModel 的數據、知識和行動的增加，會逐步解鎖。

點擊鏈接，查看視頻演示：https://mp.weixin.qq.com/s/FwtxESarMVPPhRzet7TYBA

為了讓大家更有體驗感，Demo 展示的內容是 K8s 集群巡檢，巡檢如果發現異常，就順帶做根因定位，找到引入異常的變更事件。Demo 過程可以看到 Agent 的思考過程，一般簡單任務會直接處理，復雜任務會先規劃（Plan），再處理、再總結反思。這個 Demo 最后，發現了我們注入 OOM 故障和高 CPU 負載的 sidecar，并在追問下，對上層業務進行了影響面評估。

智能運維的能力開放

在和客戶共同成長的道路上，我們深知，任何黑盒方案都無法長久。因此，我們將 AIOps 的核心能力，通過一個分層的可觀測 MCP 工具集全面開放了出來。

我們之所以設計成三層，是為了管理 AI 的復雜性。因為當工具過多時，AI Agent 很容易在選擇和調用時產生混亂。這種分層結構，提供了不同層面的對接方式，可以按需選擇。

有沒有看出這三層和前面的四層金字塔有一些對應關系？實際如此。讓我們仔細對比看一下：

• 基礎查詢層：為數據專家提供了直接訪問原始數據的 API，支持自然語言轉 SQL/PromQL。
• UModel 工具層：對應拓撲感知和智能洞察，為具備自主規劃、工具調用能力的大模型或 Agent 使用，也可以用于 Workflow 編排的 AI 應用場景。提供了基于拓撲和實體的結構化查詢能力。此外，支持在將信息喂給大模型前進行預處理，大幅提升分析準確性并降低 Token 消耗。
• Agent 層：為所有用戶提供了最易用的自然語言可觀測接口，專注解決可觀測數據分析和問題定位問題，可以與其他管控 MCP 一起集成實現完整的 AIOps 閉環。
• 我們相信客戶需要的，不是一切推倒重來都搬到我們的平臺上，而是在現有基礎上進行漸進式能力增強。這套開放的 MCP 工具，允許企業將我們的可觀測智能無縫集成到已有的平臺和流程中，構建屬于自己的智能運維大腦。

Demo：可觀測 MCP 的 DevOps 場景集成

最后讓我們來看一個激動人心的例子，看看基于云監控 2.0 的開放體系能創造怎樣的可能性。在這個 Demo 中，我們做了兩件關鍵的事：

• 擴展了 UModel：通過 UModel 的開放性，自定義了一系列 DevOps UModel，將“研發人員”、“代碼倉庫”、“代碼發布”等實體也納入了可觀測世界。
• 集成了 AI Coding IDE：我們將可觀測 MCP 工具集無縫集成到了阿里的 Qoder 中。由于 Qoder 已經是 Agentic IDE，背后有強大的大模型驅動，所以這個 MCP 集成只依賴了 UModel 工具層這一層，沒有用 Agent 層。這個集成會形成非常有趣的化學反應。

設想一下開發者在用上述 Qoder IDE 編碼時，發生的如下場景：

開發者：“剛才線上的問題是因為我剛才提交發布的代碼引起的嗎？”
Qoder：“是的，錯誤率上升跟你提交的 xxx 代碼變更有關。”
開發者：“幫我立刻回滾回來，同時進行對應的代碼優化，并提交新的 PR。”
Qoder：立即回滾變更，同時根據線上的可觀測數據和錯誤定位情況，進行代碼優化并提交修改。

點擊鏈接，查看 Demo 演示：https://mp.weixin.qq.com/s/FwtxESarMVPPhRzet7TYBA

Demo 第一部分：問題排查，還是之前那個根因定位的場景。Qoder 根據引起異常的應用找到了對應的鏡像版本，確定了根因由發布引起。根據 UModel 定位到了代碼發布記錄。

點擊鏈接，查看 Demo 演示：https://mp.weixin.qq.com/s/FwtxESarMVPPhRzet7TYBA

Demo 第二部分：將前面問題排查的結論復制并作為這輪輸入，讓 Qoder 找到引起問題的具體代碼并進行修復，提交 PR 到云效平臺（通過云效 MCP）。

這個 Demo，展示了 AIOps 的完整閉環：它將 Ops 的能力無縫融入 Dev 的工作流，讓開發者成為保障穩定的第一道防線。同時，這也揭示了 AIOps 往另一種形態發展的可能：既然有 Vibe Coding，為什么不能“Vibe Operation”（或者“VibeOps”）呢？既然用戶能夠通過 Vibe Coding 基于想法和意圖來創造軟件，那么他們同樣不希望也大概率不具備能力去處理復雜的部署、監控、故障排查和性能優化等運維工作。

結語

文章的最后，放出云監控 2.0 全景這張圖，就是我們對“重構可觀測”這個命題，所交出的完整答卷。

云監控 2.0 歷經一年半的演進，已經完成了 ARMS、容器監控（Prometheus）、企業云監控的大部分系統整合、存儲遷移等工作，剩余的 SLS CloudLens、基礎云監控等也在下半年逐步遷移規劃中。統一接入、統一數據處理、統一算法引擎、統一告警、統一儀表盤，這些都不是一句空話，也都離不開可觀測團隊一直在持續進行的升級和遷移。阿里云大部分可觀測客戶已經可以無縫升級到云監控 2.0 體系。體驗 UModel 拓撲、AIOps Agent 的升級，不需要額外多花錢。回顧我們的 2.0 旅程，借助云整體 All in AI 的浪潮，并沒有在傳統的技術體系上縫縫補補。而是從根本上重構了三個核心層：

• 最底層，我們做了統一接入、計算、存儲的決定，解決了“數據”的承載與性能難題。
• 中間層，通過創新的 UModel 和算法引擎，我們為數據賦予了拓撲關聯和領域知識，解決了“認知”的鴻溝問題。
• 最頂層，誕生了全新的 AIOps Agent 形態，以及豐富的智能探索場景，將運維帶入了自然語言對話的新形態。

這就是我們所定義的大模型驅動的 AIOps 新范式。它不是一個個孤立的工具集合，而是一個從數據、到認知、再到決策的全鏈路整合。我們相信，這不僅是技術的變革，更是智能運維理念的進化。讓我們共同期待基于大模型，可以重新探索和定義的智能運維的未來。

點擊此處，了解更多產品詳情。