10月20日，由嘉為科技攜手騰訊藍鯨智云聯(lián)合主辦的智慧生長·研運未來暨2021年研運治理實踐大會在北京成功召開。
在20日下午進行的智能化運維分論壇上，來自中山大學(xué)陳鵬飛副教授同與會嘉賓探討了云原生大勢下，智能運維的發(fā)展背景、技術(shù)以及未來展望，共同探尋云原生時代的AIOps前沿體系，并帶來了《面向云原生系統(tǒng)的智能運維》的專題演講。
云原生與智能運維的背景
云原生技術(shù)近年來愈加受到IT界的廣泛關(guān)注，在權(quán)威機構(gòu)Gartner發(fā)布的報告中，云原生已經(jīng)位在未來十項趨勢性技術(shù)之中。云原生來自于早期的云計算平臺，而云原生與智能運維相結(jié)合也是近幾年提出的一個新理念，目前發(fā)展正處在化繭成蝶的過程。但當(dāng)前云原生系統(tǒng)智能運維領(lǐng)域的實踐，還遠遠沒有達到我們所期望的狀態(tài)。
云原生技術(shù)發(fā)展
回顧云原生技術(shù)的發(fā)展軌跡，云計算從Dev+Ops時代開始，就一直朝著粒度更小的方向在發(fā)展，從裸機Bare metal、到虛擬機Virtual Machines、到容器Containers、到人工智能AI，到函數(shù)功能Function、再到未來更加細粒度的計算，云計算也在經(jīng)歷著DevOps-AIOps-NoOps的時代演進。溯其根源，新技術(shù)新能力的誕生，都是為了實現(xiàn)開發(fā)速度越來越快，交付速度越來越快，業(yè)務(wù)響應(yīng)越來越快的目標，真正提升運營的敏捷性。
但與此同時，云計算發(fā)展帶來了一些問題：開發(fā)與運維的壓力不平衡。
運維在云原生快速發(fā)展下壓力越來越大，如何平衡運維與開發(fā)?如何在運維端加強云相關(guān)能力?如何保證二者共同發(fā)展?這是智能運維亟需解決的問題。
云原生面臨的挑戰(zhàn)
現(xiàn)階段的云原生面臨著什么挑戰(zhàn)呢?在此之前，我們首先了解一下云原生有什么樣的特征。在云原生系統(tǒng)中，存在著幾個比較關(guān)鍵的技術(shù)：
DevOps
開發(fā)運維一體化。
連續(xù)交付
主要是為了從軟件、代碼，到產(chǎn)品、軟件服務(wù)市場等的速度實現(xiàn)顯著的提升。
容器技術(shù)
加速開發(fā)和部署軟件系統(tǒng)的速度。
微服務(wù)
使得軟件易于開發(fā)、交互和維護。
簡言之，云原生的特征核心在于：唯快不破，唯快不贏!對效率的極致優(yōu)化和追求，使得云原生系統(tǒng)在基于以上技術(shù)進行構(gòu)建的過程中，呈現(xiàn)出以下顯著的應(yīng)用特點：
在多種應(yīng)用特點下，云原生所面臨的難點：
1、系統(tǒng)復(fù)雜度高
舉一個例子，在某軟件中可能有3000多個微服務(wù)，但是實例的數(shù)量遠遠不止這些，如果每個微服務(wù)對應(yīng)5個實例，那么將大約有15000個實例，在如此海量的實例中，如何去理清其中的相互依賴關(guān)系、精確地捕捉微服務(wù)、查看某系統(tǒng)運維狀態(tài)，管理各個微服務(wù)之間的關(guān)系等等，都將面臨著巨大的挑戰(zhàn)。同時對于一些巨型企業(yè)，微服務(wù)成千上萬，帶來的系統(tǒng)復(fù)雜度和運維難度也遠超想象。
2、軟件系統(tǒng)的動態(tài)性
在DevOps提出以后，軟件交付的周期越來越短，與此同時，軟件逐步采用容器微服務(wù)架構(gòu)，這兩種技術(shù)的結(jié)合使得系統(tǒng)難以找到一個穩(wěn)態(tài)，這對于傳統(tǒng)的運維方案是一個巨大的挑戰(zhàn)。我們無法通過訓(xùn)練一個常規(guī)的靜態(tài)模型來進行異常檢測、根因定位等工作。另外，容器本身生命周期從創(chuàng)建申請、擴展、銷毀等都是一個動態(tài)的過程，頻繁的動態(tài)變化使得智能運維難度急劇加大。
3、軟件多樣的增加
如上圖，在云原生知名社區(qū)CNCF上，開源軟件的數(shù)量是十分龐大的，面對如此海量多類型的軟件，運維又該如何統(tǒng)籌管理，如何精確捕捉其性能和狀態(tài)呢?軟件多樣性增加環(huán)境下，運維模式和方式的復(fù)雜度呈指數(shù)級增加，難以形成統(tǒng)一解決方案。
4、軟件故障的增加
系統(tǒng)規(guī)模小的時候，可能只有幾十臺服務(wù)器，由此帶來的故障依舊人為可控，但隨著系統(tǒng)規(guī)模的不斷擴大，故障發(fā)生的概率也在并不斷的增加，造成的影響也逐漸難以控制。在此之前，我們也能在各種場景中見到各種類型的宕機、各種類型的故障，某社交巨頭企業(yè)曾經(jīng)發(fā)生過罕見的長達6小時的故障的宕機時間，這對于業(yè)務(wù)系統(tǒng)的影響幾乎是毀滅性的。因為這6小時的故障宕機，該企業(yè)可能丟失了幾十億美金。
5、運維數(shù)據(jù)復(fù)雜
與軟件規(guī)模擴大同步帶來的問題，就是數(shù)據(jù)的復(fù)雜度，實際上運維數(shù)據(jù)的種類恰好符合大數(shù)據(jù)的定義標準：種類多、體量大、速度快。如何從多種類的運維數(shù)據(jù)中發(fā)現(xiàn)問題，快速的解決問題，讓運維工作變得更加棘手。
解決思路
新技術(shù)必然帶來新的困難，為了克服這些難題，又會衍生出相應(yīng)的技術(shù)手段。早期在面臨故障時，我們考慮的是如何減少平均失效時間MTTF，再降低MTBF、MTMF平均失效間隔時間，這也是智能運維的基礎(chǔ)解決思路。在應(yīng)對云原生系統(tǒng)時，AIOps作為算法驅(qū)動的運維，就成為了解決這類問題的高級手段。
AIOps可以從算法、數(shù)據(jù)、場景三個維度去分析處理，通過數(shù)據(jù)驅(qū)動運維，最終實現(xiàn)從數(shù)據(jù)中發(fā)現(xiàn)信息，從信息中挖掘知識，形成解決問題的知識庫，最終實現(xiàn)數(shù)據(jù)融合分析，也即是AIOps的發(fā)展路徑。
面向云原生系統(tǒng)的智能運維技術(shù)
1、可觀測性
可觀測性通常在企業(yè)運維中也叫做監(jiān)控。也是智能運維的首要目標，對現(xiàn)有的資源，實現(xiàn)統(tǒng)一的監(jiān)管、控制，并且能夠根據(jù)實時變更進行動態(tài)響應(yīng)。但傳統(tǒng)的運維缺少了廣度、寬度上的監(jiān)控，我們希望能夠更深層次的觀測，包括系統(tǒng)真實狀態(tài)活動，數(shù)據(jù)源之間的關(guān)聯(lián)，多數(shù)據(jù)的統(tǒng)一接入等等。
在此方面，基于eBPF的性能監(jiān)控以及全鏈路的上下文監(jiān)控通過多種新技術(shù)手段的融合，能夠匯聚更細粒度的監(jiān)控數(shù)據(jù)，同時形成指標，便于其他運維工作的快速開展。
2、異常檢測
在異常檢測方面，目前很多場景都有各種各樣的方法，可能有成千上萬種方法，本文僅根據(jù)個人總結(jié)，對異常檢測方法進行分類，如：通過數(shù)據(jù)是否具有數(shù)據(jù)標簽，選擇有監(jiān)督、無監(jiān)督或半監(jiān)督的方式進行處理。同樣的，在數(shù)據(jù)類型、數(shù)據(jù)維度、數(shù)據(jù)模式上，也可以進行相應(yīng)的處理，從而選擇更為合適的方法進行處理。
3、根因定位
作為AIOps的核心工作難點，根因定位在運維工作中是最為常見的場景，但也是最耗時，最復(fù)雜的一個階段，如何追蹤微服務(wù)的請求信息，如何合理利用trace提供有價值的信息，如何根據(jù)分析數(shù)據(jù)、圖譜找到故障真正的源頭，這也是我們正在努力研究的一個方向。目前我們已經(jīng)在基于調(diào)用鏈、因果關(guān)系、云原生知識圖譜的根因定位中獲得了顯著的成效。
未來技術(shù)展望
以上的各類研究方法或處理手段，依然還有很大的優(yōu)化和進步空間。關(guān)于可觀測性，基于eBPF的細粒度行為監(jiān)控，我們可以減少一些可以直接觀測到的過程，例如文件的讀寫、網(wǎng)絡(luò)狀態(tài)等，不需要基于算法去處理，對監(jiān)控進行更進一步的優(yōu)化。
在全鏈路上下文關(guān)聯(lián)方面，已經(jīng)有一些走在前列企業(yè)實在實踐了，但并不夠完善，例如Metric這類指標并沒有做細粒度的關(guān)聯(lián)，數(shù)據(jù)分析上，僅僅提供了可視化么能力，缺少關(guān)聯(lián)數(shù)據(jù)的分析。
最后是基于交互式、主動式的智能運維，學(xué)術(shù)界與企業(yè)界都在進行不斷地探索著智能運維算法未來的發(fā)展。許多團隊都在這方面進行著大量的投入，同時我們也能看到智能運維也在隨著底層架構(gòu)的調(diào)整而不斷的發(fā)展和調(diào)整。谷歌最早提出的SRE的理念如今也在不斷的被各類“后起之秀”實踐并改進著。
面向云原生系統(tǒng)的智能運維過程，我們可以總結(jié)為：在運維的數(shù)據(jù)中找到知識，在這一過程中，如何獲取數(shù)據(jù)，如何分析處理數(shù)據(jù)，如何總結(jié)出可用的知識經(jīng)驗，例如故障種類，發(fā)生時間，規(guī)律，修復(fù)方式，解決過程等，如何沉淀統(tǒng)一知識庫、形成解決方案等等，實際上就是我們通常在寫的Postmortem，也是智能運維發(fā)展中正在不斷探索內(nèi)容，如何推進Postmortem的文化，在未來也將會有一席之地!
