當 AI 能比資深工程師更快定位故障根源，運維領(lǐng)域?qū)⒂瓉碓鯓拥姆妒礁锩?/p>

快貓星云 CTO 華明認為，隨著大模型時代的到來，所有產(chǎn)品都值得用大模型重做一遍，運維相關(guān)的工具和產(chǎn)品也一樣，智能閉環(huán)或高度自治的運維階段是一個或近或遠的未來。

Flashcat 目前在努力推進運維和可觀測性進入智能輔助階段，并且取得了相當明顯的進步。整體而言，F(xiàn)lashcat 在可觀測性方向上，致力于為人和 AI 解決兩個問題：

• 如何讓人和 AI 更好的理解你的系統(tǒng)？

• 如何讓人和 AI 無障礙的讀取你的觀測數(shù)據(jù)？

6 月 21 日，快貓星云 CTO 華明將出席 OSC 源創(chuàng)會?北京站線下沙龍，發(fā)表《可觀測性智能化愿景：Flashcat 的方法、實踐和效果》主題演講。在演講正式開始前，先來簡單聊聊智能運維與可觀測技術(shù)的發(fā)展變化。

AI 運維「開掛」指南 OSC 源創(chuàng)會?北京?114 期 時間：2025-06-21 14:00 至 17:30 地點：北京 海淀 海淀大街甲 36 號 439 號中關(guān)村創(chuàng)業(yè)大街 12 號樓 5 層 報名地址： https://www.oschina.net/event/8596707

OSCHINA：當前運維領(lǐng)域與大模型結(jié)合的核心難點是什么？預(yù)計能帶來什么樣的價值？

華明：

大模型與各個行業(yè)結(jié)合的難點都是如何與現(xiàn)有的軟件和生產(chǎn)系統(tǒng)實現(xiàn)平滑的連接。具體到運維領(lǐng)域，就是如何讓大模型理解復雜的生產(chǎn)系統(tǒng)，以及如何讓大模型從海量的運維數(shù)據(jù)中獲得有限、有效的信息進行分析，最終高效輸出真正有價值的洞見。

如果大模型解決了與現(xiàn)有軟件系統(tǒng)的對接以及理解復雜生產(chǎn)系統(tǒng)的難點，將會在故障定位、運維提效等運維領(lǐng)域的關(guān)鍵難題上取得突破，給未來的運維模式帶來顛覆性的影響。

OSCHINA：信通院將運維發(fā)展分為 “自動化→小模型→大模型” 三階段，F(xiàn)lashcat 如何定義自身的智能化演進路徑？是否已接近 L4（部分自治運維）或 L5（高度自治運維）層級？

華明：

我們偏向認為運維的發(fā)展與小模型、大模型的劃分關(guān)系不大，可能的路徑是：自動化 -> 智能輔助 -> 智能閉環(huán)。

其實自動化時代也只能實現(xiàn)部分自動化，完全的自動化依賴智能化。隨著容器化、云計算技術(shù)的發(fā)展和成熟，當前常規(guī)的自動化基本已經(jīng)到頭，運維行業(yè)處于探索進入智能輔助的階段，即探索如何利用大模型來加速解決運維領(lǐng)域的關(guān)鍵難題。

而智能閉環(huán)或高度自治的運維階段是一個或近或遠的未來，我傾向于認為還有不少時間，這個時間點到來的標志將是：線上系統(tǒng)的代碼完全由 AI 自主完成編寫和發(fā)布，人已經(jīng)不需要編寫其中的任何一行代碼。AI 能夠自主完成系統(tǒng)代碼的編寫，那配套的運維將會被 AI 自動考慮其中，形成一個完成自治的閉環(huán)。

Flashcat 目前在努力推進運維和可觀測性進入智能輔助階段，我們已經(jīng)取得了相當明顯的進步，而且我們相信我們正走在正確的路上，相信不久智能化將會是 Flashcat 的一大亮點。

OSCHINA：傳統(tǒng)監(jiān)控被比喻為 “蒼蠅復眼”，而現(xiàn)代可觀測性系統(tǒng)如同 “人類雙眼”。Flashcat 如何通過智能化實現(xiàn)從 “低效告警” 到 “主動洞察” 的跨越？

華明：

我們認為下一階段 AI 能夠明顯發(fā)揮價值的方式是：加速原本人可以完成的復雜分析工作。如果一個分析工作人是能夠完成的，只是分析效率低，那 AI 就很有可能可以極大的加速這個分析過程?！爸鲃佣床臁?的價值可能還在這之后。

比如，針對一個故障的診斷，人可能要花費很多的時間，查詢好幾個平臺的數(shù)據(jù)才能分析出根因。如果把生產(chǎn)環(huán)境的描述、異常信息的描述、多個平臺數(shù)據(jù)的查詢能力提供給 AI，那 AI 大概率可以從這些有限、有效的信息集合中快速分析出有效的結(jié)論。

換言之，如果一個技術(shù)工程師能夠 “無障礙” 的獲取生產(chǎn)環(huán)境的信息、得到故障相關(guān)數(shù)據(jù)的關(guān)聯(lián)、掌握各個觀測平臺數(shù)據(jù)的查詢權(quán)限和方法，那問題根因的定位除了“智商”和“手速”的問題外，就沒有了“硬傷”。把相同的能力給到 AI，那 AI 就能比所有人都做的更快、更好。

Flashcat 其實一開始是奔著讓人 “無障礙” 的獲取故障分析定位的信息和能力去努力的，但后來發(fā)現(xiàn)，這個路徑其實也正是運維可觀測性通向智能化的道路。

總結(jié)起來 Flashcat 在可觀測性方向上，致力于為人和AI解決兩個問題：

• 如何讓人和AI更好的理解你的系統(tǒng)

• 如何讓人和AI無障礙的讀取你的觀測數(shù)據(jù)

OSCHINA：Flashcat 在實現(xiàn)可觀測性智能化時，如何處理海量時序數(shù)據(jù)（如日志、指標、鏈路）的實時分析與關(guān)聯(lián)？是否依賴統(tǒng)一數(shù)據(jù)引擎？

華明：

如何讓 AI 從海量的運維數(shù)據(jù)中獲得有限而有效的數(shù)據(jù)，以輸出有價值的洞見，確實是運維領(lǐng)域落地 AI 的一大難點。否則 AI 再強也是老虎吃天，無從下嘴。

解決這一問題，F(xiàn)lashcat 依賴內(nèi)部的 “滅火圖” 系統(tǒng)。滅火圖系統(tǒng)是 Flashcat 構(gòu)建服務(wù)元信息和全面觀測服務(wù)狀態(tài)的系統(tǒng)。滅火圖能夠幫助用戶將 IT 基礎(chǔ)設(shè)施分解為結(jié)構(gòu)化、立體的觀測對象，如底層網(wǎng)絡(luò) / DNS 等基礎(chǔ)設(shè)施、MySQL/Redis 等標準中間件、Kubernetes 微服務(wù)、功能接口等，并量化其中每個觀測對象的健康度，呈現(xiàn)出 “著火” 和健康的兩種紅 / 綠狀態(tài)。讓用戶一眼就看清整個 IT 系統(tǒng)的對象極其健康狀態(tài)。

同時，每個對象都可以下鉆遍歷其相關(guān)的觀測數(shù)據(jù)，如指標、日志、鏈路、事件、儀表盤等。而這些數(shù)據(jù) Flashcat 通過數(shù)據(jù)集成的方式為用戶自動調(diào)取，數(shù)據(jù)來源對用戶是透明的，相關(guān)數(shù)據(jù)可能來自用戶生產(chǎn)環(huán)境中已有的各個觀測平臺，如 Prometheus、Elasticsearch、SLS、Skywalking 等。

滅火圖已經(jīng)積累了大量的模板和規(guī)則為用戶快速創(chuàng)建滅火圖，將整個 IT 系統(tǒng)的所有元信息和關(guān)聯(lián)信息呈現(xiàn)到用戶面前。

滅火圖相對 AI 來說，就是這個統(tǒng)一的數(shù)據(jù)引擎，可以為 AI 提供服務(wù)的元信息和數(shù)據(jù)的關(guān)聯(lián)信息，讓 AI 理解你的系統(tǒng)。同時也為 AI 提供了查詢數(shù)據(jù)的通道和能力，讓 AI 能夠查詢你的數(shù)據(jù)。

OSCHINA：能否分享一個 Flashcat 通過智能化能力解決難題的典型案例？

華明：

我們搭建了一套典型的服務(wù)架構(gòu)：用戶流量 -> 網(wǎng)關(guān)接口 -> 后端 server->Redis->DB。在這個框架中我們將 Redis 進行重啟，這個動作會使得相應(yīng)的滅火圖出現(xiàn)多處 “著火”，比如網(wǎng)關(guān)上的某個接口、微服務(wù) server、Redis 集群。

這時候我們讓 AI 從兩個角度進行分析：

1、從網(wǎng)關(guān)的接口上開始分析：AI 會下鉆分析該異常接口的三個黃金指標：流量、成功率、響應(yīng)延遲，再下鉆分析相應(yīng)的日志、儀表盤、鏈路。最后 AI 準確的得出了結(jié)論，異常的根因是：Redis 實例 ip:port 出現(xiàn)異常導致。

2、在滅火圖首頁上進行全局分析：AI 通過滅火圖的全局信息和分層結(jié)構(gòu)，掌握了全部的異常信息，以及異常信息之間的層次關(guān)系，分別分析異常點后，也綜合得出了 redis 實例宕機是根因的準確結(jié)論。

雖然實際的生產(chǎn)環(huán)境會比這個典型框架復雜很多，但只要提供的元信息、關(guān)聯(lián)信息足夠準確，相信 AI 同樣可以得出準確的結(jié)論，這個過程相比人來分析會快速的多，體現(xiàn)了智能化的價值。

我們下一步將在客戶的大型環(huán)境中進一步驗證打磨。同時還有很多故障定位的思路我們也正在通過 AI 輸出實現(xiàn)，目前看可行性非常之大，期待我們的研發(fā)進一步呈現(xiàn)相關(guān)的效果。

OSCHINA：智能化是否會導致運維人員 “躺平”？運維團隊需掌握哪些新技能以適應(yīng)新范式？有沒有給運維人的建議？

華明：

智能化的實現(xiàn)將會極大的解放人力，但如前所述，我們的下一個階段是智能輔助階段，這個階段人的參與仍然是不可或缺的。那在智能化的新范式下，運維人員應(yīng)該掌握哪些新技能呢？

我認為有幾點：

1、理解 AI 以及 AI 的能力邊界，參與到將企業(yè)系統(tǒng)連接 AI 的建設(shè)工作中來，為 AI 建設(shè)和提供準確、高質(zhì)量的元信息和觀測數(shù)據(jù)。

2、觀測數(shù)據(jù)的標準化和質(zhì)量建設(shè)，觀測數(shù)據(jù)極其標準化和數(shù)據(jù)質(zhì)量的建設(shè)將會變得愈發(fā)重要。因為對 AI 來說 Garbage in Garbage out，再好的 AI，如果吃的數(shù)據(jù)是垃圾，吐出來的也只能是垃圾。

3、針對很多具體的故障場景和分析場景，運維老司機最了解分析的要素和思路是什么，如何將這些經(jīng)驗轉(zhuǎn)化為 AI 的輸入，也將會是運維的核心競爭力之一。

OSCHINA：當前企業(yè)推進智能化運維的最大障礙是數(shù)據(jù)孤島、算力成本還是技術(shù)信任？Flashcat 的解決方案是什么？

華明：

如前所述，我們認為當前企業(yè)運維實現(xiàn)智能化最大的障礙是兩個：

① 如何讓人和 AI 更好的理解你的系統(tǒng)

② 如何讓人和 AI 無障礙的讀取你的觀測數(shù)據(jù)

這其中數(shù)據(jù)孤島問題就是問題②中最關(guān)鍵和最普遍的問題，F(xiàn)lashcat 通過持續(xù)集成市面上的開源和公有云上的觀測系統(tǒng)實現(xiàn)了對數(shù)據(jù)孤島的打通，并把這個能力提供給了 AI，在 Flashcat 中，數(shù)據(jù)不再是孤島，而是豐富的數(shù)據(jù)查詢通道。

算力成本問題，我認為不是當前的重點，目前使用 AI 的成本在持續(xù)下降，企業(yè)甚至只要開通一個公有云的大模型賬號就可以使用到 AI 的能力，而不必都自建大模型集群。就我們觀察，當前大部分企業(yè)在成本和探索價值的取舍上都傾向于愿意付出這部分成本。Flashcat 會內(nèi)置一個小模型，只要少量的資源即可完成部署，同時能夠便利的集成企業(yè)內(nèi)部的大模型集群接口，也可以方便的集成企業(yè)提供的公有云大模型接口，實現(xiàn)和企業(yè)已有模型基礎(chǔ)設(shè)施的對接，最大化降低推進的成本。

確實有很多企業(yè)還在觀望當前 AI 技術(shù)的實際價值，對 AI 效果的落地存在信任問題。但大家對 AI 將實現(xiàn)運維智能化這個預(yù)期是基本肯定的，只是所預(yù)期的時間長短問題。而當前如果試錯的成本足夠低，很多企業(yè)是愿意甚至是積極的想?yún)⑴c的。Flashcat 通過從海量數(shù)據(jù)中提取有限的信息，并打通已有觀測數(shù)據(jù)孤島，以及集成企業(yè)現(xiàn)成的大模型能力，整體上推進運維智能化的嘗試的成本已經(jīng)非常之低，結(jié)合已有的智能化效果，很多企業(yè)是愿意放下信任問題，選擇一起探索嘗試的。

AI 運維「開掛」指南 OSC 源創(chuàng)會?北京?114 期 時間：2025-06-21 14:00 至 17:30 地點：北京 海淀 海淀大街甲 36 號 439 號中關(guān)村創(chuàng)業(yè)大街 12 號樓 5 層