演講實錄｜吳亞昆：雲時代智慧運維與可觀測性探索

前情提要

8 月 19 - 20 日，GOPS 全球運維大會 2022 · 深圳站正式開幕。

觀測雲首席佈道師吳亞昆

受邀參加大會，並帶來「雲時代智慧運維與可觀測性探索」精彩主題演講。

演講目錄

傳統運維問題顯著

雲時代的智慧運維新思路

可觀測性的探索方向

演講實錄

大家好，我是來自

觀測雲的吳亞昆

，今天分享主題是「

雲時代智慧運維與可觀測性探索

」。

傳統運維問題顯著

首先，我們看一看傳統運維存在的問題有哪些？

首先，我們看一看傳統運維存在的問題有哪些，回頭看 20 多年整個運維階段的發展，我還沒有畢業的時候用的基本上是 IBM 的一套東西，那套東西非常繁重，比如大機、小機。

但是在整個業務發展過程中，包括 X86、虛擬化、雲計算甚至到現在微服務整個過程，它其實有非常明確的演進方向。最開始架構非常簡單，就是從前端 Web 端到中間處理端，最後到後端資料庫的三層，它整個層次架構非常清晰。

原來我們怎麼去處理這個問題呢？原來很簡單，就是運維「三板斧」，「重啟、重灌、換電腦」，先是重啟，重啟不行就重灌，重灌不行就換一臺裝置，換一臺裝置之後絕大部分問題就解決了。

但是到虛擬化和雲計算時代，我們會發現這樣的處理方式其實已經沒有那麼容易去解決這些問題了，重啟虛機並不一定能夠恢復業務，尤其是到現在微服務化比較普及了，服務的呼叫鏈非常長，很難快速定位到問題根因。

回過頭來看一下當年怎麼做，我自己就是從最早從蹲機房的運維開始做起，我們原來做主機監控很簡單，機房裡面會有一個小推車，大家應該很熟悉，它背後其實是有一個顯示器、鍵盤、滑鼠，直接接到伺服器背後，就可以檢視這臺伺服器的狀態了。

後來量多了，大家比較懶，我們就坐在機房旁邊的操作室，用 SSH 方式遠端登入，再往上是網路監控，交換機數量不是特別多的情況，我們透過 Console 線管理裝置、用 Telnet 遠端登入，因為我們資訊化發展在往上走，當我們整體裝置數量開始變多之後，我們需要有一些監控系統，比如說我們會用 Cacti，它可以監控所有的網路裝置，這個年代到這一層基本定型了，裝置有問題換裝置就好了，真正的業務跑的狀態怎麼樣其實沒有太多人知道。

所以隨著資訊化繼續發展，大家也都開始逐漸關注一些更細顆粒度的東西，比如說我們開始用虛擬化平臺，我們會想看平臺本身的問題；我們也會有公有云、私有云平臺，可以在平臺上做一些基礎監控，看整體 CPU 利用率、磁碟剩餘空間、賬單明細等等。但對於我們單臺起的裝置它的指標我們依然是用傳統方式去做監控，比如說 Zabbix，以及商業化做的還不錯的 Solarwinds 等等，這一層我們也只是看到它本身的靜態或者固定的指標，它的模板其實非常少。

再往上我們開始做一些使用者體驗相關的東西，會去做指標上的自定義，比如說使用者行為、業務埋點等等，但是這些資料也沒辦法展示系統本身的異常情況。

上述的各部分的監控都沒有辦法單獨解決系統問題，造成這樣情況的原因在於，每一套監控系統資料都是獨立儲存，彼此之間是完全割裂的。

為什麼造成這樣的原因，這個和康威定律有關。造成這樣的結果是因為整個組織架構設定就是這樣的，很多傳統公司現在組織架構把平臺運維、網路運維、系統運維、應用運維等等都拆成了不同崗位，彼此之間職責邊界明確，因此各個系統之間的職責邊界也很明確，導致相互之間沒有辦法做關聯。

雲時代的智慧運維新思路

到了雲原生時代，我們整個系統產生的資料是海量的，在海量資料情況下我們面臨一個明顯且巨大的挑戰，怎麼基於非常複雜的呼叫關係、非常複雜的訪問關係做到每一層監控，並把每一層監控做好之後做到快速定位到問題？

可以聊一聊在這個時代下我們新的思路，在講新的思路之前，我們先來一個靈魂拷問，監控那麼多資料的目的是什麼？

CPU、記憶體、靜態指標等資料的監控，這些是資料量極其龐大，但是密度非常低的資料，比如說昨天的 CPU 對於我們已經沒有任何意義了，但是它的量是實時不斷產生的，所以它是低密度的資料。

其實我們監控目的只有一個，就是為了保障業務穩定性。透過快速定位業務故障，快速恢復業務狀態，實現整個業務的質量目標，這是運維監控這件事情唯一的目的，如果大家瞭解我們企業架構，就能理解技術永遠是支撐業務的，技術很難獨立業務存在，除非自己技術本身就是業務。

回到這個話題，我們監控這麼多資料，就是為了手裡面有東西可以去做分析，可以快速定位故障。但是如何實現？

這裡有一些前提條件。當我們要去做分析這些海量資料的時候，需要統一的存放、關聯和分析，在這裡，1+1 的價值是遠遠大於 2 的。如果統一的存放、關聯和分析的能力缺失的話，比如按照傳統方式，不同系統獨立儲存這些資料，它發揮不了太大價值。

各位運維的同學可以回想一下自己的經歷，大半夜接到一個電話說業務掛了，網路運維上線撥 VPN 到系統裡面去看半天，說網路正常，也沒有丟包，頻寬也 OK，系統運維可能登上來看一下，整體利用率正常，也沒有什麼異常日誌，最後大家都把自己的系統查了一遍，都會說我這邊沒問題，但是業務還沒有恢復，問題依然存在。

我們有很多監控系統，這些監控系統展示給客戶和運維同學看的時候，都是非常直觀的圖形，可以看到整個訪問情況都是綠的，狀態都挺好的。

當某一個時候出現了問題，使用者開啟頁面非常慢，或者報錯，作為管理員來說，我需要再聯絡這些系統對應的責任人。

每一個責任人登到系統之後，他們需要去做故障排查，在傳統協作方面會浪費很多時間，大家會不停去找故障。單個節點的故障率其實不是特別高，但是所有系統組合到一起之後，你會發現整體系統的故障率就變得非常非常高了。

因此，可能原來資料庫的一年掛兩次，這頻率已經很高了，但是當整體系統故障率變得非常高的時候，整個系統所有資料庫加一起一年可能掛 20 次，其實大家的工作量就提升了 10 倍，這個效率就變成非常低了。

我們認為在這件事情下，有一個比較好的設想，當出現了一個問題之後，所有資料做了關聯，我就知道這個問題所經過的鏈路到底是哪一個，當我發現使用者那邊訪問有問題的時候，就知道故障根因在哪裡，可以快速定位到故障點甚至快速定位到故障原因以及關聯責任人，可能一年處理 20 次故障的 DBA，可以快速定位到是應用寫的有 bug，跟資料庫和網路都沒有關係，應用自己修復就好了。

綠色的點就是我們認為在整條鏈路上透過海量資料展示出來，這些節點正常的現象，這些正常現象的人就不需要去關注自己的問題了。

還有一個比較好的方面，當我們把這套模式做下來之後，不同部門、不同團隊對於自己的 SLO，對於整個部門會有明確 KPI 界限劃分，比如說你的系統出問題了，每次說系統問題最後甩鍋到網路運維，網路運維說我整個網路一直都是好的，一直都沒什麼問題，結果到年底在老闆面前發現，你的網路好像每天都在出問題，但是當我們把整個模式跑通之後，網路那邊一直都可能會是正常狀態，因此「出鏡率」不是特別高。

從中，我們可以看到，按照不同層次去做劃分，從基礎設施到網路，到應用，再到使用者體驗相關的東西，不同層次資料監控起來之後我們需要做到對應的關聯，做到統一存放，並且在一個地方去做分析。

再來思考一個問題，怎麼才能實現統一存放、全面關聯、資料分析？

我們可以按資料層次進行劃分，並按顆粒度更細的角度去做展示，監控資料是非常多維的，也就是說我們可能從資料中心的動環開始，一直到最上面的應用和雲裡面的介面資料，所有資料在收上來之後，其實我們應該是對這些資料打上標記，

因

為

打標的時候我們可以非常明確知道，一個使用者的訪問行為，或者叫使用者旅程，到底經過了哪些系統元件。

我們中間開源了採集端，我們叫 DataKit 採集端，這個開源產品大家可以瞭解一下，我們整個做的還不錯，把我們所有資料打到 DataKit 之後，我們會做一個數據對映和格式化，做好對映和格式化之後就推到我們後端平臺，因為是開源的，我們也沒有強綁死說一定要推到觀測雲，其實我們也可以推到第三方平臺。

透過資料「前」治理的方式，我們可以把所有資料關聯的壓力從後端釋放出來，透過分散式方式直接把壓力分散到所有采集節點上，所有資料都採集完成並在我們平臺儲存之後，我們看到做了幾個挺有意思的場景。

這個場景叫做智慧推斷，一是做了記憶體洩露推斷，基於整個應用關於記憶體的使用率，並且我們做了未來時間的預測；二是磁碟利用率推斷，我們可以看到它接下來利用率可能會是多少，什麼時候會有異常；三是應用異常推斷，我們可以融合 APM 資料、使用者資料、其他各個維度資料做應用本身異常的定位；四是故障根因定位相關的推斷，這張圖和我剛才描述的抽象那張圖很像，可以非常快速看到，問題出現的時候可以快速找到異常點在哪裡。

可觀測性的探索方向

可觀測性，其實所有資料監控、資料採集、資料智慧推斷本質都是可觀測性的一個維度，有一個很有趣的說法，叫做「一切皆可觀測」，當然後面是我們的探索方向，有些我們已經落地了，有些我們在探索。

首先看一下整個技術的趨勢，這是 Gartner 今年釋出的一個技術趨勢報告，紅框標出來的地方就是可觀測性，處在熱度非常高的位置，所以現在基本上大家都在聊這個話題。

Gartner 的另外一個報告裡面給出了稍微抽象一些的圖，它把我們運維資料治理階段分成了 4 個部分，從最左邊的資料採集到中間的資料聚合，再到分析，到行動，分成這麼幾個步驟。

這張圖上方的曲線非常清晰地展示了監控、AIOps、可觀測性之間的關係，監控更多強調資料採集，比如說要採集 CPU、記憶體等等，AIOps 可能更多強調在資料聚合，把所有資料進行清洗聚合，但是對於可觀測性來說包含兩部分，但不僅僅侷限於這兩部分，因為還涵蓋了分析和行動。

對於整個可觀測性來說，剛才聊到我們觀測雲第一個產品是 DataKit，它已經開源了，可以相容非常多中介軟體。第二個是我們畫在左邊的採集平臺，它是我們的程式設計開放平臺 Dataflux Func，有點像是 python 沙箱，也開源了。

這個平臺特別有意思，很多探索的東西是在這裡面去做的，比如說我們透過開放程式設計平臺，我們在裡面去做了很多模板，它可以一鍵對接很多雲資源賬單，阿里雲、騰訊雲等等我們可以直接把賬單資料拉過來。它也可以對接很多感測器，比如電錶，我們北京一個同事，他把家裡所有電錶資料都拉出來，然後在儀表板上可以看到昨天用了多少電、對應電費是多少。第三個是我們在探索的東西，比如說對接特斯拉、新能源汽車，只要有開放介面就可以了。最後可以對接已經落地的流程時效資料，提交程式碼週期以及每一位研發同學程式碼提交的頻次等等。

我們把所有可觀測領域，從 DevOps 運維視角往 Dev 方面擴充套件了一下，因此我們覺得這是不錯的探索方向，我們非常希望在座有一些好的想法的同學可以和我們一起去做開放場景，因為我們開放程式設計平臺資源利用率很低，樹莓派也可以執行。我們指令碼市場裡面也放了很多現成的指令碼，大家有興趣可以去動手玩一下。

這是我們做的儀表板，這是根據 SRE 方法論做的落地，我們把所有監控指標包裝成 SLO，我們認為我們關注的某一些指標就應該是某一個服務模組，再包了一個總的 SLO，有可能我們對某一個 SLO 做了指標值設定，比如說 99。9%、99。99% 等等，我們在這裡面會發現，當它有問題之後會自動去扣預算，然後展示出來，這樣也會對我們運維團隊做 KPI 考核非常直觀。

我們可以透過左邊的 SLO 大的宏觀模板，直接下鑽到使用者體驗這個部分，繼續下鑽到可能產生的錯誤分析，一層一層下鑽的能力，其實我們做的非常成熟了，實現這個能力的基礎是我們剛才所說的

統一資料的關聯、統一資料的儲存、統一資料的分析

。

我們來看看整個運維故障定位的流程，當故障發生之後可以往下鑽，可以看到我們的錯誤是什麼，錯誤點開來之後可以看到訪問請求，我們點到其中一條訪問請求，就可以繼續往下鑽，可以跳轉到它的呼叫鏈。所有東西都是在一個平臺裡面完成的，不需要像傳統運維平臺，發現一個問題之後要同時開啟 3-4 套工具，不同工具交叉做對比，不僅僅是效率比較低，而且有可能有些資料丟掉了你看不到。

我們剛才聊到在探索的方向，左上角是北京同事他把他家裡電錶資料展現上來的儀表板，右邊是我們做的線上大學視覺化，左下角是運動手環運動資料，我們也可以接進去展示，只要它開放了介面。右下角這個場景是我們最近在探索的挺有意思的專案，我們我們把橋樑上面的感測器全部資料接到整個觀測雲平臺，用開放平臺 DataFlux Func 做的資料對接。