AIOps 為什麼不溫不火?

高效開發運維2019-09-13 06:38:24

嘉賓 | 周琦(簡志)
策劃 | 薛樑
AIOps 這兩年在工業界雷聲大雨點小,聽到最多的應用場景就是智能監控,離真正將人工智能技術應用於運維環境的理想情況還有一段距離,這裡面既有業務場景的影響,也與生產組織自身掣肘因素有關。

骨感的現實中,如何找到豐滿的解決答案,今天我們就來和阿里雲資深技術專家周琦老師聊聊,他是如何理解 AIOps 不溫不火的原因的。

人物故事線  

我從高中開始學習編程,第一門語言是 PASCAL(主要是用來參加競賽),之後學習 C、VC++ 等語言,編寫過各種應用端(IDE、MFC)和 Web 的程序(ASP、PHP 等)。在高中階段幫餐飲公司開發過賬務管理系統,音樂公司的宣傳網站等。

後來步入大學,開始慢慢正規化學習計算機編程,這些年的經歷總的概括起來可以分為這四個時間段:

軟件工程時代:關注應用邏輯正確性,發展過程中沉澱了大量的框架和最佳實踐,例如 Spring、TDD 方法(Test Driven Development),重構(Refactor)等,研發工作從個人行為轉為一個可以提升的專業能力;

Web 服務時代:2008 年末 iOS + Android 誕生使得移動互聯網在繼 WAP 後真正成形,研發的技術點也逐步從功能關注轉為如何構建一個高擴展的架構,例如 Hadoop、NoSQL 等就是該時代的產物;

O2O 業務開花:新的業態大量誕生鑄造了敏捷開發的模式,更快產品迭代速度對上線發佈提出更高要求;

雲原生時代:在混合雲(線上、線上)過度中,如何保證系統架構穩定性,彈性伸縮,如何快速適配業務邏輯。

從這幾個時代的發展來看,能夠看到三個趨勢:

  1. 專業程度很高:分工更細了,前端、後端,應用層開發,對 DevOps 而言需要管理部分也越來越多;

  2. 更快發佈速度:在過去一個版本發佈需要漫長過程,但目前業務發展很快,開發速度更快,如何能夠又快又不出錯是一個很高業務要求;

  3. 更高可用性:異構環境下,業務 7*24 要求對可用性越來越高。

對 DevOps 而言,承載的職責範圍變大,業務壓力變高了,並且需要更高的穩定性要求。好比你在駕駛一輛坐著很多人(前端、服務端、應用開發)的汽車,在更高速度行駛,並且要保證不能有差錯。因此需要你對汽車的速度、油耗、運行狀況能有更好的感知,對行駛的路況有提前判斷的能力,更安全的駕駛行為。

資深技術專家目前的工作狀態  

大部分時間在做產品設計和技術選型工作,也仍在做一些基礎開發。因為我們平時都在做面向 DevOps 的工作,必須能夠對問題有感覺,所以離不開基礎研發工作。

從個人經歷來看,5 年前曾有一個比較大的轉變,慢慢從做純技術轉為面向產品的技術,來服務技術人員,具體有亮點:

  1. 讓自己從純技術思維中跳出來,考慮如何通過產品來解決用戶的問題,要考慮如何把問題能夠抽象和組合,而不是解決一個表面問題;

  2. 能夠清楚核心能力是什麼,如何從下往上逐步觸達。以汽車自動駕駛為例,其定義 L1-L5 的層次,使得大家能有階段性的目標來達成。

AIOps 和自動駕駛  

工作中在 AIOps 領域的數據處理、建模、異常檢測、故障診斷、知識圖譜等有實踐經驗,也正推進在業務場景的落地。從個人角度來看,AIOps 本質和自動駕駛是類似的,目的是為了提升 IT 系統安全性、穩定性和可用性,減少人力和硬件上的投入。

同時我們可以把自動駕駛與 AIOps 整個技術體系做一個類比,也是類似的效果。為了達到 L4 終極目標,有如下橫向工作需要建立:

  1. 傳感技術:如何使用可觀察性數據(例如 CNCF 中 OpenTelemetry)來構建一套完整的運行數據觀察體系,越多數據意味著掌握更多情況;

  2. 感知:通過數據處理、加工計算等技術,實時地從傳感數據中計算出運行狀態,並加以建模;

  3. 高精度地圖:通過知識圖譜和數據挖掘描述出對象之間的關係和影響;

  4. 決策層:根據多維的實時數據進行計算並獲得結果,發現其中的異常並進行規模和處理。

目前業界努力的終極目標是完全無人運維的平臺,但道阻且長。當前業界主要工作集中在決策層的方法中,例如對通用日誌數據聚類和異常判別,通用時序數據的建模與異常檢測,和對結構化數據的搜索與根因分析。在這些垂直領域上已經有不少成果已經落地。

例如右半部分“自動運維技術堆棧”主要分為四個部分:動態數據採集層,能夠從各個系統中獲得運行數據,例如 Log,Metric 和 Tracing 等。可以認為是自動駕駛的攝像頭、激光雷達等感知設備。靜態數據採集層:將 IT 架構的型號、上下游依賴等進行構建,以確定上下文。類似自動駕駛的靜態地圖。處理層(包括數據存儲、搜索、計算等工作):把採集到的數據運行各種規則,以形成可以被分析的數據。類似自動駕駛中對其他車輛、人、交通信號等進行建模,以判斷對應的速度、區域、方向等。決策層:最重要的部分,根據計算後的數據對關聯的對象行為進行預測、分析、推理等,以確定風險和下一步的行為,類似自動駕駛中的大腦。

自動化運維和智能化運維之間的溝塹  

自動化運維是一個基於規則的工作,例如我們定義出創建的狀態和處理的規則,當某某條件發生後,會進行下一步操作。

而智能化運維會面向很多不確定性的工作,需要去執行預測、推理、分析等任務,並且能夠通過建模等適配新的場景進行泛化。因此智能化運維能夠承載更多、更具挑戰的工作。

AIOps 風聲大雨點小的內外因?  


從技術採用生命週期模型來看,任何技術在大規模運用之前,都需要跨過鴻溝,有一個從爬坡到下降最後持續爬坡過程,AI 是如此(想想 70 年代的 AI 技術),AIOps 也一樣。Gartner 最新《Hype Cycle for ICT in China 2019》中對 AIOps 的評價比較客觀:該技術處於從一項創新(Innovation Trigger)到萬眾期待頂點(Peak of Inflated Expectation)過程中,之後還會經歷一個低谷期(Trough of Disillusionment)直到最終成果。但 AIOps 目前在國內已經被各行各業逐步認可,普遍被認為該技術在接下來 2~5 年內會產生較高收益,是值得投入的方向。

個人覺得內在原因很簡單,技術創新剛剛開始,需要 1-2 年時間逐步成熟並商用的過程。這是客觀規律:任何技術短期內會被高估,而長期內是被低估的。

外在原因我認為有兩方面:

  1. IT 基礎架構最近幾年隨著雲計算、雲原生、移動端等技術發展,變化非常大,開發與運維人員知識體系也在不停更新中,因此缺乏一個比較穩定場景讓配套的 AIOps 技術能夠誕生;

  2. 數據與算法平臺缺乏:AIOps 本質上是 DataOps + Domain Knowledge,其中前者是一個工程問題,對於 AI 而言,首先需要有充足的“多維數據 + 配套的算力(實時性)”才能夠達到真正駕駛上路的水平,試想神經網絡算法 80 年代就有了,也是 2012 年後算力和數據豐富了,才提升了一個臺階。這點好在目前的“數據採集 + 大數據架構”已日漸成熟,這個問題會逐步消失。

工業界 AIOps 的案例  

目前 AIOps 落地和嘗試主要集中在學術界和企業界,例如國內學術界領域比較有名的是清華大學裴丹老師,在學術會議上發表很多優秀文章,也組織了非常好的會議。其次是企業 DevOps 部門,例如國內各大互聯網廠商,企業 IT 部門,使用 AI 技術解決運維、發佈、供應鏈等場景上解決問題。最後就是 IT 軟件廠商:例如 APM、SIEM、DevOps 等廠商等在技術堆棧上引入了 AI 元素,加深產品的功能和場景覆蓋面等。

作為“提升效率的 AIOps”專題出品人寄語  

AIOps 是一個開放領域,目前工業界和學術界並沒有嚴格定義,因此無論是異常發現、故障定位、知識管理、或面向場景的解決方案都是受歡迎的。但希望話題具備以下三個特質:

  1. 時代性:特別是在雲原生、容器、移動端等場景下,如何應對環境的複雜性;

  2. 通用:能夠解一個或多個通用問題,並且方法有一定的泛化能力,這些問題是業務的痛點,能夠引起共鳴,能夠具備一定的複製能力;

  3. 啟發:方法的創新性,能夠給同行工作帶來一定啟示,至少能夠開闊思路。

希望參會者首先能聽懂問題、有共鳴感、並且能夠引發該場景的思考。用一句古話道:學而時習之,不亦說乎?

作者介紹

周琦(簡志),阿里雲資深技術專家。從 2009 年加入阿里雲,曾負責分佈式系統開發,並且負責其中監控、診斷等系統,也承擔技術雲化的重任。目前負責阿里集團 / 螞蟻金服 / 阿里雲日誌處理、分析平臺,同時也是 ArchSummit 全球架構師峰會(北京·2019 年 12 月)AIOps 專題出品人。很有幸採訪到周琦老師,多年的技術積累,希望對運維領域的你有幫助。

歡迎關注 ArchSummit 全球架構師峰會,點擊“閱讀原文”查看官網。

https://weiwenku.net/d/201371714