一直以來，企業(yè)運(yùn)維如臨場救火乃是常態(tài)，如今喝著茶水做好運(yùn)維倒有望成為“一件小事”，說到底還不是智能運(yùn)維趕來幫忙？
啥是智能運(yùn)維？如此神奇？
談及“智能運(yùn)維”的概念，洋氣一些可被稱為AIOps，正好是人工智能技術(shù)與基礎(chǔ)運(yùn)維能力的完美集合，一句話概括，運(yùn)用機(jī)器學(xué)習(xí)的方法來提升運(yùn)維效率。
稍微回顧下運(yùn)維發(fā)展我們就能發(fā)現(xiàn)，在歷經(jīng)千錘百煉達(dá)成的傳統(tǒng)自動(dòng)化運(yùn)維體系中，重復(fù)性、低效率的工作伴隨著人力成本的消耗已經(jīng)被得到有效解決，但復(fù)雜場景下的故障處理、容量管理等問題，依然需要人來參與；這種情況下AI的加盟無非讓完全意義上的自動(dòng)化果斷進(jìn)入快車道，加速?zèng)]商量！
但不少技術(shù)小伙伴可能抱著這樣的想法，AIOps不就是自動(dòng)化運(yùn)維與機(jī)器學(xué)習(xí)的強(qiáng)強(qiáng)聯(lián)合嗎？
話說哪有如此easy！
關(guān)于這兩者，我們通常會(huì)將智能運(yùn)維與通用人工智能拿來類比，“此智能”更傾向于事先預(yù)測，即了解錯(cuò)誤數(shù)據(jù)馬上會(huì)引發(fā)重要故障時(shí)采取有效措施避免或者減弱影響。
而針對這類預(yù)測性動(dòng)作所涉及的數(shù)據(jù)處理，也正好發(fā)揮了機(jī)器學(xué)習(xí)處理海量、高速以及多樣數(shù)據(jù)并帶來高價(jià)值的專長。
如果從全球范圍內(nèi)AIOps產(chǎn)品的技術(shù)側(cè)重點(diǎn)來分析的話，無外乎兩種，即側(cè)重AI方向與偏Ops一些。
很容易理解第一種。無非是將數(shù)據(jù)放入具體場景中測試判斷AI技術(shù)是否可以更好的解決實(shí)際問題，在算法實(shí)驗(yàn)的過程中挑選合適的采用即可。
相比第一種，第二種則需要在整體的運(yùn)維流程中預(yù)先判斷瓶頸障礙，進(jìn)而得出AI 技術(shù)是否可以將問題解決，可見這都不是兩者單純相加那么容易。
說完技術(shù)點(diǎn)再聊聊數(shù)據(jù)。
換個(gè)探討角度，從運(yùn)維數(shù)據(jù)出發(fā)，例如對于常規(guī)的硬件設(shè)備，包括開源基礎(chǔ)軟件在內(nèi)，日志數(shù)據(jù)應(yīng)該是最能展現(xiàn)當(dāng)時(shí)其運(yùn)行狀態(tài)。
常見的關(guān)鍵詞warning、 error、critical 等或多或少都可以反映出平常不太留意甚至少見的系統(tǒng)情況，進(jìn)而發(fā)現(xiàn)潛在問題。
但如今現(xiàn)實(shí)中很多用戶的運(yùn)維業(yè)務(wù)與系統(tǒng)中的代碼并不都是自己的研發(fā)人員寫成的，更多的外采設(shè)備如果出現(xiàn)問題并不能及時(shí)得到解決，造成了“日志到手絕非想用就用”的狀態(tài)，腫么辦？
一般在這種不知道具體源碼的情況下，通常利用無監(jiān)督聚類的方式完成反向推導(dǎo)，就可大致獲悉日志在實(shí)際中的代碼操作情況，盡管不能做到百分百還原，但也會(huì)最大限度預(yù)測出發(fā)展邏輯，只需目標(biāo)明確再加額外關(guān)注即可在故障預(yù)判中做到事半功倍。
目前無論是智能運(yùn)維中的監(jiān)控指標(biāo)還是在日志分析，運(yùn)用AI技術(shù)最簡單的方法就是使用一些非監(jiān)督學(xué)習(xí)的算法，例如聚類算法，即Cluster Analysis，也被稱為群集分析（將相似對象通過靜態(tài)分類的方法分成不同的組別或者更多的子集（subset），這樣讓在同一個(gè)子集中的成員對象都有相似的一些屬性。）
盡管在具體的運(yùn)維場景中，僅憑如今的機(jī)器學(xué)習(xí)水平暫不能將每條路徑都做到靈活使用，但異常檢測方向還是落地頻次較高的。只要具備足夠的運(yùn)維數(shù)據(jù)支持，在調(diào)用鏈基礎(chǔ)上的拓?fù)渑c圖譜推導(dǎo)都會(huì)被華麗麗的實(shí)現(xiàn)。
高屋建瓴一下，在神奇的AIOps場景中，數(shù)據(jù)已然成為中心資源，將運(yùn)維各種狀態(tài)信息轉(zhuǎn)換為大數(shù)據(jù)的過程中，機(jī)器學(xué)習(xí)在基礎(chǔ)上完成相應(yīng)的分析，全流程就ok啦！
在智能運(yùn)維的大盤中，機(jī)器學(xué)習(xí)技術(shù)與各類運(yùn)維數(shù)據(jù)，都不可缺。
深入分析運(yùn)維數(shù)據(jù)的那些事兒，我們發(fā)現(xiàn)其實(shí)在實(shí)際操作過程中，運(yùn)維數(shù)據(jù)主要分動(dòng)靜兩態(tài)，以運(yùn)維大數(shù)據(jù)平臺為例，通常部分靜態(tài)數(shù)據(jù)可直接加載在內(nèi)心數(shù)據(jù)庫中，并保存在結(jié)構(gòu)化數(shù)據(jù)庫或者Hive平臺。
相反，主要包含各類監(jiān)控指標(biāo)數(shù)據(jù)、日志數(shù)據(jù)以及第三方擴(kuò)展應(yīng)用所產(chǎn)生的動(dòng)態(tài)數(shù)據(jù)，一般是實(shí)時(shí)生成并被獲取作為基礎(chǔ)數(shù)據(jù)，過程中需要通過數(shù)據(jù)清洗轉(zhuǎn)換成可使用的樣本數(shù)據(jù)。
其中日志數(shù)據(jù)概念尤其廣泛，機(jī)器產(chǎn)生的文本數(shù)據(jù)與具體數(shù)值都算；但涉及到場景的細(xì)分，用于監(jiān)控的指標(biāo)數(shù)據(jù)才會(huì)被經(jīng)常使用到，例如調(diào)用鏈數(shù)據(jù)等。
以日志為代表的動(dòng)態(tài)數(shù)據(jù)一般按不同的使用場景保存在差異性的大數(shù)據(jù)組件中，例如用于分析的數(shù)據(jù)會(huì)優(yōu)先保存在Hive數(shù)據(jù)庫，用于檢索的日志數(shù)據(jù)可保存在ES（即Elasticsearch）中，當(dāng)然業(yè)界也有進(jìn)行ES改造或者替換的情況，例如日志易Beaver。
Beaver作為一個(gè)由C++語言編寫的高性能、分布式、時(shí)序數(shù)據(jù)庫，對包含日志及指標(biāo)在內(nèi)的各類時(shí)間序列機(jī)器數(shù)據(jù)采取分詞索引、列式存儲等方式，實(shí)現(xiàn)實(shí)時(shí)全文檢索、時(shí)間范圍查詢和統(tǒng)計(jì)分析功能，同時(shí)也支持時(shí)序數(shù)據(jù)特有的滑窗函數(shù)、關(guān)聯(lián)查詢等功能。
聚焦具體的采集過程，以日志易為例，數(shù)據(jù)類型不太會(huì)影響具體的采集過程，只是會(huì)對采集之后是否用于異常檢測或者根因定位的算法加以區(qū)別，數(shù)據(jù)能否在合適的位置產(chǎn)生恰當(dāng)?shù)淖饔貌攀侵攸c(diǎn)。
“我們的智能運(yùn)維更多是定位與分析，利用日志數(shù)據(jù)指標(biāo)去定位故障并進(jìn)一步驅(qū)動(dòng)相應(yīng)的自動(dòng)化運(yùn)維工具來修復(fù)，這也是業(yè)務(wù)運(yùn)維的重點(diǎn)。”智能運(yùn)維領(lǐng)域資深技術(shù)人，也是日志易產(chǎn)品總監(jiān)的饒琛琳說道。
以運(yùn)維排障解釋，排障關(guān)注的并不是每個(gè)設(shè)備的情況，而是頂層業(yè)務(wù)運(yùn)行的概況；簡單來說得到一個(gè)總告警是無用的，更多是深入底層不同的模塊系統(tǒng)加以判斷。
比方說將不同的平臺日志拿來進(jìn)行快速查詢，但如果采取對查詢結(jié)果的一一嘗試所消耗的時(shí)間成本就很巨大；相反若將搜集數(shù)據(jù)聚集，通過性能強(qiáng)大的搜索引擎過濾，再進(jìn)一步憑借AI算法完成結(jié)果分類的幾種模式，如此一來上千萬條日志就會(huì)被“萃取”成幾十條結(jié)果，時(shí)間成本大大降低。
如此說來，剛剛提及的“萃取”理念倒是與日志易Lynxee系統(tǒng)技術(shù)初衷如出一轍。
有資料稱，Lynxee系統(tǒng)應(yīng)用其實(shí)是基于日志易強(qiáng)悍的數(shù)據(jù)檢索平臺功能，再結(jié)合前期豐富的自動(dòng)化運(yùn)維經(jīng)驗(yàn)“鍛造”而成的智能運(yùn)維系統(tǒng)，目前主要應(yīng)用在各類金融行業(yè)的用戶群體中。
在Lynxee中，由于多種智能算法被提供用來自動(dòng)判斷運(yùn)維指標(biāo)的監(jiān)控效果，就無需手動(dòng)設(shè)定監(jiān)控閾值，其中的異常檢測會(huì)自動(dòng)給出監(jiān)控項(xiàng)目的健康分?jǐn)?shù)，幫助用戶主動(dòng)發(fā)現(xiàn)和排查平常難以發(fā)現(xiàn)的問題。
但更多人認(rèn)為，實(shí)踐中的異常檢測就像預(yù)測股票大盤走勢一樣，概念貌似不大，但實(shí)際難度卻不小。面對這樣的判定，日志易采用了“不斷加定語”的方式來循序漸進(jìn)降低應(yīng)用的難度。
所謂“加定語”其實(shí)是更好地運(yùn)用專業(yè)的運(yùn)維知識，不斷縮小異常檢測的場景應(yīng)用范圍，指標(biāo)細(xì)致到是請求量的異常還是響應(yīng)時(shí)間異常等，從而進(jìn)一步明確預(yù)處理的工作內(nèi)容。
比如性能瓶頸被檢測出來后，就可以對這部分進(jìn)行代碼優(yōu)化或者定向擴(kuò)容；如果預(yù)測出來是設(shè)備故障，就可以著手更新設(shè)備；而故障預(yù)測可以幫助進(jìn)行動(dòng)態(tài)流量切換或者硬件替換等。
坦白說這種理念有點(diǎn)兒類似于“庖丁解牛”，從起初的目中全牛且無從下手，到后來的目無全牛，根據(jù)經(jīng)脈切中要害并游刃有余，不困擾在某個(gè)具體的技術(shù)細(xì)節(jié)上。
“我們實(shí)操中的智能運(yùn)維不單單是一個(gè)算法平臺，而是基于成熟的運(yùn)維知識構(gòu)建的流程體系化，其中涉及服務(wù)設(shè)備概念、監(jiān)控來源常識等，從發(fā)現(xiàn)故障到加持檢測算法，然后定位故障全流程一棧式，用戶并不需要過多掛心來源于算法本身的種種技術(shù)問題。”
對于經(jīng)驗(yàn)與未來，不可否認(rèn)，智能運(yùn)維依舊存在很多令人驚喜的可能性。例如在成熟日志處理的基礎(chǔ)上，提升算法的交互融合程度以及更多實(shí)際應(yīng)用場景的拆分等，都是亟待完善的地方。
談及前景，我們留意到，一直在IT圈以“權(quán)威”著稱的Gartner的報(bào)告也曾作出預(yù)測：智能運(yùn)維于2020年將在一半以上的企業(yè)中落地并貢獻(xiàn)生產(chǎn)力。
作為傳統(tǒng)運(yùn)維與新興AI技術(shù)的高度結(jié)合，且一度被譽(yù)為“朝陽產(chǎn)業(yè)”的智能運(yùn)維，看起來前景一片大好，不錯(cuò)；但在技術(shù)成熟度上還有很大的提升空間，亟待被重視。
尤其是近年來得到云原生微服務(wù)架構(gòu)的技術(shù)洗禮，不知不覺也產(chǎn)生了諸多新變化！
或許小伙伴們多少有些了解，過去大家考慮的是如何達(dá)成或者提升自動(dòng)化運(yùn)維水平，快速部署上線才是王道。
如今更多精力則集中在保證規(guī)模與滿足微服務(wù)架構(gòu)的運(yùn)維監(jiān)控方案的高可用性，簡單點(diǎn)兒說就是可觀察性。
畢竟在全面云化的條件下，因?yàn)轶w量規(guī)模增大，業(yè)務(wù)細(xì)分的顆粒度也隨之提升，過程中難免會(huì)涉及到上百個(gè)接口的調(diào)用，這就意味著僅僅依靠單純的性能監(jiān)控指標(biāo)遠(yuǎn)遠(yuǎn)不夠。
而可觀察性就是為了達(dá)成包括指標(biāo)日志、調(diào)用鏈、變更數(shù)據(jù)等不同角度運(yùn)維數(shù)據(jù)在內(nèi)的統(tǒng)一，從各種維度觀察服務(wù)運(yùn)行的狀態(tài)是否良好。
本質(zhì)上可以算是傳統(tǒng)監(jiān)控概念的智慧升級，簡單說就是用智能運(yùn)維的方式解決微服務(wù)架構(gòu)的基礎(chǔ)運(yùn)維問題。
正如饒琛琳所言，其實(shí)對于運(yùn)維數(shù)據(jù)來說，架構(gòu)創(chuàng)新只會(huì)帶來寫入介質(zhì)的更改，比方說從本地磁盤過渡到對象存儲。
這一點(diǎn)不像網(wǎng)絡(luò)抓包，自身依賴的環(huán)境發(fā)生改變，整體的基礎(chǔ)設(shè)施也就隨之變化了。
據(jù)了解，日志易做的是“造福”業(yè)務(wù)運(yùn)維團(tuán)隊(duì)的事兒，不同于傳統(tǒng)數(shù)據(jù)中心基礎(chǔ)運(yùn)維，對于云原生微服務(wù)等一攬子創(chuàng)新架構(gòu)上的應(yīng)用支撐，其實(shí)早早就做好了打算。
但他也表示，就算門檻不高、本質(zhì)未改，但適當(dāng)?shù)募夹g(shù)調(diào)整依舊是需要的。
畢竟新架構(gòu)下的存儲機(jī)制以及輸出方式有了改變，迫切做好的是接入方式的合理適配與改造，以此確保動(dòng)態(tài)調(diào)度的時(shí)候，不會(huì)影響數(shù)據(jù)采集的準(zhǔn)確性。
過去在采集過程中，可能只需要一兩個(gè)數(shù)據(jù)標(biāo)簽完成具體業(yè)務(wù)應(yīng)用來源某臺主機(jī)的區(qū)分。
但在彈性的云原生、微服務(wù)以及容器環(huán)境下，需要配合pod確保映射管理以及數(shù)據(jù)采集完整等細(xì)節(jié)，盡可能降低底層架構(gòu)改變帶來性能的差異。
目前除了像日志易一樣的IT企業(yè)入局智能運(yùn)維領(lǐng)域外，突破運(yùn)維的智能化也成為有關(guān)科研機(jī)構(gòu)的攻堅(jiān)熱點(diǎn)。
其中不僅出爐了有較為先進(jìn)的科技成果，從算法層面上支撐發(fā)展落地；更重要的是已經(jīng)與工業(yè)界展開了密切合作，例如卡內(nèi)基梅隆大學(xué)與Netflix公司聯(lián)手。
另外類似于以專業(yè)大數(shù)據(jù)搜索與可視化見長的Splunk，也將智能運(yùn)維管理平臺的研發(fā)視為幫助用戶實(shí)時(shí)了解IT架構(gòu)現(xiàn)狀的利器之一，通過將機(jī)器學(xué)習(xí)的數(shù)據(jù)加以轉(zhuǎn)化形成有價(jià)值的運(yùn)維建議廣泛傳播，同理還有科技巨頭IBM以及華為等。
當(dāng)然，在高利潤、高技術(shù)含量的驅(qū)動(dòng)下，互聯(lián)網(wǎng)巨頭與金融行業(yè)也爭相參與其中，比方說阿里巴巴針對智能故障管理平臺的研發(fā)以及各類銀行對于運(yùn)維大數(shù)據(jù)平臺的建設(shè)等。
盡管多方入局，但與之關(guān)聯(lián)的企業(yè)級智能運(yùn)維建設(shè)，除了具備全棧式運(yùn)維數(shù)據(jù)的剛性條件外，更重要的是尋找頗具痛點(diǎn)的場景來入局嘗試，避免直接使用標(biāo)準(zhǔn)的算法通過黑盒方式解決問題，目前來看異常檢測絕對是首當(dāng)其沖的應(yīng)用場景。
這樣來看，無論企業(yè)從運(yùn)維數(shù)據(jù)中臺建設(shè)還是從規(guī)模較小的場景化切入，運(yùn)維數(shù)據(jù)的治理能力與質(zhì)量提升以及機(jī)器學(xué)習(xí)技術(shù)的合理應(yīng)用，都是加快智能運(yùn)維發(fā)展的一系列必備因素。
談及智能運(yùn)維的將來，饒琛琳認(rèn)為AIOps早已聲勢浩大，讓運(yùn)維更加智慧便捷，沒什么不可能……
