骨感的現實中，如何找到豐滿的解決答案，今天我們就來和阿里雲資深技術專家周琦老師聊聊，他是如何理解 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 本質和自動駕駛是類似的，目的是為了提升 IT 系統安全性、穩定性和可用性，減少人力和硬體上的投入。

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

1. 感測技術：如何使用可觀察性資料（例如 CNCF 中 OpenTelemetry）來構建一套完整的執行資料觀察體系，越多資料意味著掌握更多情況；

2. 感知：通過資料處理、加工計算等技術，實時地從感測資料中計算出執行狀態，並加以建模；

3. 高精度地圖：通過知識圖譜和資料探勘描述出物件之間的關係和影響；

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

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

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

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

從技術採用生命週期模型來看，任何技術在大規模運用之前，都需要跨過鴻溝，有一個從爬坡到下降最後持續爬坡過程，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 落地和嘗試主要集中在學術界和企業界，例如國內學術界領域比較有名的是清華大學裴丹老師，在學術會議上發表很多優秀文章，也組織了非常好的會議。其次是企業 DevOps 部門，例如國內各大網際網路廠商，企業 IT 部門，使用 AI 技術解決運維、釋出、供應鏈等場景上解決問題。最後就是 IT 軟體廠商：例如 APM、SIEM、DevOps 等廠商等在技術堆疊上引入了 AI 元素，加深產品的功能和場景覆蓋面等。

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

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

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

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

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

歡迎關注 ArchSummit 全球架構師峰會，點選“閱讀原文”檢視官網。