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