2019阿裡雲上海峰會，由阿裡雲資深技術專家周琦帶來以“基于AlOps的探索和最佳實踐”為題的演講。AIOps意味着智能、安全的管控平台，阿裡巴巴經過十年的變革在AIOps上有重大探索，那麼AIOps究竟能夠為大家帶來什麼益處呢？接下來本文将對AIOps進行詳細的介紹。 視訊直播回顧 雲原生專場PPT下載下傳 以下為精彩視訊内容整理：
AIOps 能帶來什麼？
現在無人駕駛技術一直備受關注，無人駕駛技術從L1到L5一共有5個等級代表越來越智能的自動化程度，從目标來看，無人駕駛技術希望在安全駕駛的過程中不斷去提升整個通行效率，并且降低整個公路的安全隐患，并降低污染的排放。
與無人駕駛類似，AIOps目标是為IT基礎設施平台的運轉提升效率，提升系統穩定性并解放人在運維上的投入。近幾年來，雲原生和容器服務使應用、釋出、部署的環節效率能夠大大加快，但在整個釋出和營運的過程中環境的複雜性、應用部署規模、使用者多樣性等使得整體風險越來越高。AIOps目标就是通過數值驅動手段，在更快的釋出效率同時兼顧更低的風險，減少人力投入，使得IT設施具備既快又安全的“自動駕駛”的能力。
飛天研發史：人與機器鬥争史
飛天作業系統是阿裡雲的基礎設施，要知道研發基礎平台是一個非常複雜的事情。可以認為就是一部人和機器的鬥争史。在第一個階段，為了能夠在大量機器上進行調試，我們使用了大量的監控工具解決可觀測性的問題，這個階段大約需要2個員工管理大小不等的20個叢集。
在叢集規模從20個變成400個過程中，工程師會花費大量的時間在如何标準化接入、标準化營運上。是以在這個階段，主要任務就是如何把整個監控和分析能力标準化，接入自動化，本質上是一個把監控+運維工具标準化，服務化的階段。
在第三個階段由于叢集規模和業務量的不斷增大，我們所面臨的問題更加複雜，傳統手段往往很難解決一些比較複雜的可觀測性問題。是以我們使用了大量資料化、智能化的手段進行嘗試，獲得了較好的結果，每個員工管理叢集的和應用的能力，可以達到1：1000或者更高。
雲原生和Docker技術解決了一部分運維和釋出的負擔，但對于個人承擔的責任仍然變得越來越大，我們可以把應用上線的過程分成三個階段：第一個階段開發人員需要騰出一半的精力測試系統是否穩定、高效，代碼是否有邏輯；第二階段，在整個上線過程中，除了将産品釋出以外，還需要花40%的時間在部署和營運上，讓使用者能夠更好的運用産品；第三階段為上線後階段，除了運維和營運支撐外，還需要花時間關注安全問題，例如某個系統有沒有人登入，登入之後是否做了一些非法操作等。
研發、運維、營運的挑戰
作為研發（DevOps） 如何能在快節奏下做到以上的點呢？我們可以看一條非常著名的法則：海恩法則(Ohain's law)是德國飛機渦輪機的發明者帕布斯·海恩提出的一個在航空界關于飛行安全的法則，多被用于企業的生産管理，特别是安全管理中。海恩法則指出: 每一起嚴重事故的背後，必然有29次輕微事故和300起未遂先兆以及1000起事故隐患。法則強調兩點:一是事故的發生是量的積累的結果;二是再好的技術，再完美的規章，在實際操作層面，也無法取代人自身的素質和責任心。
我們關注的是第一點，如何建立一套風險的監控、分析、洞察體系。從安全人員角度來講，安全人員關注的是在叢集上線之後有沒有非法登入的現象，安全人員需要采集大量的Logs和規則，用來判斷是否防火牆被匿名打開過。對于營運人員來講，無非是把logs内容變成User Click，然後根據使用者的增長進行營運。
是以我們可以把常見工作做一個抽象：對運維、安全、營運而言，無論是從監控場景，還是平時用的基于ELK的Logs場景，還是對安全日志模組化場景。要做的往往都是四個步驟：資料采集，根據假設建立一套模型獲得初步的結果（Event），根據初步結果獲得最後的結論，在步驟三和步驟四的過程中需要進行探索性的Drill Down、Roll Up等操作，不斷去Refine自己的假設和模型。
可觀察性的挑戰
在建立這樣一個體系之前，我們結合AIOps場景特點需要解決三個挑戰，具體介紹如下：
更快的響應：對于一個線上服務而言，從觀測資料的采集到行動，期待能夠在秒級之内完成，這樣才能保障快速解決。
更多的視角：在安全的角度觀察的是有沒有漏洞；在研發的角度關心的是有沒有錯誤；在營運人員的角度關心的是流失率和使用者點選的路徑。是以必須要從更多的視角觀察資料。
深入到細節：對資料進行分析時，應該關注資料的具體詳情，例如很多細節的狀況都需要在秒級才能發現。
統一的資料模型、通用架構、面向分析類的設計
從平台的架構來看，我們建構了一套面向觀測資料（Telemetry Data）的系統，資料源主要分成Tracing、 Metric、Logging三類，将三個資料采集到同一套架構中，運用一套方法論和平台對資料進行查詢、分析、聚類和預測。在這個基礎上，可以利用開源或者商業的可視化軟體，建構一套所見即所得的可視化架構，幫助使用者更好的感覺業務的形态和細節。
Sec、Dev、Ops 解決問題思路
系統建構完成後，我們把問題分析和調查的高頻場景做了抽象，并提出了7個高頻使用的手段，接下來将會對這7種方法進行詳細的介紹。
查找：Grep
GREP是查詢問題最頻繁的方法，通過這種方式能夠快速的找到問題發生的位置。從業界統計《50 Most Frequently Used Unix Command》看，Grep是使用最多的指令之一（排名第一的是tar、第二就是它）。Grep提供了一種“簡單暴力”方式過濾掉無用的資訊。從業務的視角來看，無論是pssh + pgm方式，還是對Tracing類資料的應用形态進行剖析，或通過開源ELK工具對通路日志的篩選 + 排查，背後都是查找這種方式。
上下文
當查找到關鍵點後，我們需要定位關鍵點的上下文。這個就像調查一個犯罪現場一樣，需要看周圍的環境，該環境一般對于程式人員而言就是上下文。比如一個程式執行出現錯誤時，出現問題的上十行和下十行代碼很有可能和這個錯誤相關，比如之前傳入的參數，或錯誤後的執行邏輯等，這些上下文能夠有效的幫助程式員找到上下遊的線索。
上下文對于不同的應用含義是不一樣的：
• 一個錯誤，同一個日志檔案中的前後資料
• 一行LogAppender中輸出，同一個程序順序輸出到日志子產品前後順序
• 一次請求，同一個Session組合
• 一次跨服務請求，同一個TraceId組合
例如一個很常見操作是grep拿到檔案後，跳轉到對應機器用vim打開檔案，上下翻閱查查找這些線索。在這個過程中，有不少程式員貢獻過一些vim插件幫助标記（不同顔色标記error、info、level等級别）。縱觀整個過程，我們為了拿到前後幾行的資料，做了很多不必要的操作。
我們把上下文定義如下：在一個最小區分粒度上能夠準确還原出最原始的序列，不受日志存儲、采集等環節影響。
• 最小區分粒度：區分上下文的最小空間劃分，例如同一個線程、同一個檔案等。在定位階段非常關鍵，能夠使得我們在調查過程中避免很多幹擾
• 保序：在最小區分粒度下保證原子有序，及時一秒内有幾萬次操作，也要保證順序是嚴格的
為了有效的找出問題的上下文，我們設計了一套對應的協定。該協定會在所有的采集器、SDK、Appender中統一實作。該協定的主要思想是，在原始日志産生過程中，設定一個單調遞增的ID，這個ID使得服務端在亂序存儲的情況下，也能夠進行全局的排序。通過全局的排序之後，當命中一條錯誤的日志時，就能夠對整個錯誤日志的上下遊進行關聯，進而拿到錯誤的上下文。為了能夠更直覺的感受上下文方法，接下來舉一個案例（視訊）。
案例如圖所示，在圖中的7月22日中找到線上出現問題的位置，通過上下文快速的浏覽這一行錯誤的上遊和下遊分别是什麼，進而解決對應的問題。
SQL分析
尋找問題的第三種方式為SQL分析，在稍複雜一些場景中，我們需要對資料進行統計發現其中規律。在Linux理念中，任何複雜任務都是可以用一組指令的組合來達到（運維大法的一個入門的例子就是對Nginx通路日志進行指令行處理）。
例如線上在多次通路後依舊請求失敗，若想知道這些請求是來自于哪些營運商，或者來自哪個省市，就需要對線上資料做完基礎的查詢後，再通過SQL分析得出想要的結果。
我們在查找後建構了一套SQL92文法的分析系統，能夠對滿足結果的資料進行實時統計，讓我們來看以下這個例子，動态根據線上資料進行分析：
“線上有大量錯誤發生時，我們需要需要對這些錯誤各次元去聚合，是一個全局的錯誤？還是一個使用者的錯誤？如果是使用者的錯誤，是來自于某些省市的營運商？還是來自于使用者的某個業務？每個推斷後都是一個不斷變化的SQL”
聚類
尋找問題的第四種方式為聚類，在機器學習中就介紹過“聚類”的概念，即資料不需要許多人工制定的規則就能夠自動聚集起來。
在過去，如何從正常的資料中判斷出異常很依賴于領域專家能力和經驗：以系統Latency作為例子，25ms是個絕對數值，隻對特定場景有意義：25ms對于一個包大小為4KB 請求偏大，但對于一個2MB 大小的請求是合适的數值。
如何在缺乏領域專家知識情況下如何發現異常？ 這時可以借助統計意義上的大數定律：
大資料定律通俗一點講，就是樣本數量很大的時候，樣本均值和真實均值充分接近。例如從資料本身的分布規律來比較哪些是異常的。例如通過聚類我們可以快速将“相似”執行個體彙聚在一起，定位到“小衆”的資料（但不一定是異常）。
對錯誤類的日志，通過關鍵字找一個錯誤可能會搜尋到幾千條相關資訊，但其中隻有一兩條是問題所在的地方，我們需要用很多grep -v排除掉無用的資訊。
對整個線上監控類資料也是類似，假設線上有很多執行個體，若想看一下負載均衡是否起作用，那麼隻要将這個執行個體目前的平均CPU拿出來做排序，看一下哪些機器的CPU使用過高即可。
我們根據線上日志類資料、時序資料（Metric）做了兩套原生的聚類算法，例如對日之類資料能夠自動識别出變量（例如時間、線程Id、執行個體資訊等），把結構化類的Pattern留下代表一類事件，這樣就能夠排除數量上的影響，讓我們找到背後的關鍵事件。
以線上為例再進一步介紹聚類方法，選中sys_log搜尋資料的結果有3000多條，通過翻頁尋找想要的資料非常困難，但是通過使用聚類方法，就能把同一日志裡面符合搜尋的資料全部選取出來，包括時間、IP等等。3000多條資料通過聚類篩選後隻剩20條左右，接着将這20條資訊進行對比，判斷哪些是新篩選出來的資訊，哪些是以前存在的資訊。
對于線上伺服器的流量資料， 我們也能夠通過形态進行聚類，以診斷出哪些機器的行為與其他不一緻，負載均衡是否起了作用。
異常發現（時序模組化）
聚類解決了同一時刻不同執行個體下的異同點問題，但在很多場景下我們沒有别的參照系。在缺乏專家經驗情況下，一種簡單方法是從曆史角度來判别。
例如我們可以用環比和同比函數，和昨天（Yesterday），一周前（Week）和月（Month）進行對比，如果差别大于某一個Threshold（例如10%）可以認為是異常。
這種方法看似簡單直覺，但面對複雜一些場景就會産生失效情況，例如“标準月曆 vs 零售月曆”缺陷：
在零售行業中節假日、周末會比工作日帶來60%以上營收。是以每個月進行預測時，往往會随着月的大小周（例如5個周末 vs 4個周末）造成比較大的偏差。
是以對于非平穩序列資料，通過簡單同比環比還不夠，我們需要對資料規律進行更複雜的模組化。例如可以自動排除資料中的噪聲，學習資料的趨勢、周期等規模，形成一個根據曆史資料自動學習的基線。目前資料和基線有較大偏差時，可以認為就是異常。
根因分析
通過方式五中的異常發現已經能夠找出異常，接下來我們需要能找到問題的根本原因（Root Cause Analysis）。 假設工程師收到一條流量下降的告警，有經驗的工程師會有一個猜疑鍊，究竟是使用者的問題還是網站的問題。若是使用者的問題，分析是城市的問題還是某個用戶端引起的問題；若是網站開發版本的問題，判斷究竟是移動端的問題還是網頁端的問題。若是移動端問題，那麼還需要判斷究竟時安卓帶來的，還是IOS。
一個簡單的思路就是統計意義上的“啤酒和尿布”問題-頻繁模式挖掘，我們可以建立一張表，這個表能夠把所有失敗的請求列出來，同時相關屬性。接着做一個簡單的統計，就能知道在所有錯誤的日志裡哪個屬性占的比例較多，在這個例子裡面很明顯，問題發生在交換機（ASW=DEV1）。
模式挖掘方法從統計角度考慮頻率的次元，如果資料有時間次元的屬性，那我們可以有更多Feature可以提升準确性：根因特征對陡升陡降的變化量影響？根因特征貢獻的絕對值與相對值？
一個改進的根因分析算法：
1） 線上流量有突增、将異常資料（突增）标記
2） 根據搜尋算法計算突增的影響根元素組合相關性
3） 向使用者推薦最有可能的組合（行為和整體的流量突增一緻）
領域模組化與本體建構
以上的方法提供了一批适合發現、定位問題的有力工具，但一旦離開了人，這些好比是空中樓閣，是以我們如何把人對系統的經驗和認知，能夠固化成一種讓計算機了解并推斷的方式會非常重要，隻有這樣才能做到最後一公裡的完全自動化。
從計算機曆史上看，AI在上個世紀七十年代提出後經曆過一次小高潮後，受限于資料量和計算規模在90年代後沒有大的突破。是以2000後科學家把提升準确性的工作借助另一個方向：
• 網際網路之父"Time Bernus Lee" 提出《Semantic Web》概念，希望能讓網際網路的内容都有标注，具備一定的語義性，進而使得機器能夠去了解人類在網際網路上留下的半結構化知識，并做更好的推理
• 2003年一篇著名Paper
提出也提出了一個概念：建構一張不斷更新，能夠具備一定推理能力的網絡，網絡能夠自動去識别可能的問題。2005年後，各公司開始嘗試通過知識圖譜（Knowledge Graph）把知識更有效組織起來應用在各領域中輔助AI。以人腦為例，很容易解釋Knowledge Graph：
• 一個有經驗程式員去調查問題時，會有一定的背景知識。例如有大量請求發生錯誤時，他可能會從腦海裡去查找過去是否有類似的現象。當聚焦點到某一個裝置時，他可能會從腦海裡去考慮裝置對應的網絡結構。
• 所謂的曆史經驗，問題所依賴的環境，環境背後的關聯等就Knowledge，通過Graph這種結構能夠把零散的Knowledge組成一張體系的圖譜在腦海中存儲。當有一個新問題來的時候，他可以根據過去的經驗，問題背景（例如業務的架構）等作為判斷因素，快速去做推理和假設。
與這個過程類似，我們正在圍繞CMDB、雲産品API、容器拓撲結構、Logging、Metric等資料整合一張知識圖譜。當有了這張圖譜後，我們就可以有機地把上訴各種算法定位的結果進行整合，無論是故障搜尋、線上環境的自動檢查等，都可以更權威、準确地完成。
AIOps 算法落地場景
最後總結一下本文提出的幾個方法，通過時序資料的算法能夠解決趨勢預測的問題；通過異常檢測能夠分析資料的周期性變化問題；通過聚類方法能夠幫助資料進行降維；通過根因推導方法有助于搜尋整個模組化的問題和故障。