筆者是飛天最早的研發人員之一，曾經參與從0到5000台飛天叢集和作業系統的建構。飛天是一個龐大的軟體系統，既有非常多的子產品，也要跑在幾萬台實體機上，如何讓分布式軟體高效地運作離不開監控、性能分析等環節，是以在飛天研發的第一天我們就同時開始研發飛天監控系統“神農”。神農通過采集大量的系統資料，幫助我們更好地了解系統、軟體協作複雜性背後的關系。同時神農也在伴随着越來越大、越來越多海内外叢集的飛天作業系統成長，支撐阿裡巴巴集團和阿裡雲的業務。在2015年，經曆過一番思考，我們決定把神農抽象成一個更底層的服務——SLS（日志服務，第一天主要focus在日志場景中），希望通過SLS能夠服務支撐更多的Ops場景，包括AIOps（智能分析引擎）。
一 建構可觀察性中台的背景
先說說從一個工程師的角度看到的變化：對一個工程師而言，5年前的工作是非常細分的，研發的工作就是把代碼開發好。但随着網際網路的發展，業務系統Scope越來越大，需要在品質、可用性和可運維性上有更高的要求。并且為了保障我們的業務是持續改進的，必須在工作中涉及到更多營運的因素，例如統計系統通路、留存和體驗等情況。
從個人視角轉化到行業視角也能發現一個趨勢：在十幾年前，研發的時間會花在三個部分：創新（編碼），部署+上線，觀察+分析，并且部署+上線會花費大量的時間。近幾年雲計算和雲原生的興起解放了開發運維在部署、上線和環境标準化上的精力。但業務的高要求需要在各個環節中承擔更大的Scope，從多個視角來看待問題。背後就會有大量、碎片化的資料分析工作。
如果我們把具體的資料分析工作進行拆分，可以拆解成一個簡單的黑盒。黑盒的左邊是資料源，右邊是我們對資料源觀測判斷後的行動。例如：
- 在安全場景中，安全營運工程師會采集防火牆、主機、系統等日志、根據經驗對日志進行模組化，識别其中的高危操作，生成關鍵性事件，系統根據多個事件進行告警。
- 在監控和營運場景中，這個過程是類似的。無非是把資料源和模組化的方法做了替換。
是以我們可以看到，雖然各個場景角色不同，資料源不同，但在機制上我們是可以建立一套系統性分析架構來承載這類可觀察性的需求的。
二 中台的技術挑戰
建構中台的思路看起來很直接，要做這件事情有哪些挑戰呢？
我們可以從資料源、分析和判别這三個過程來分析：
- 第一大挑戰來自于資料源接入。以監控場景為例，業界有不同的可視化、采集、分析工具針對不同的資料源。為了能建立監控可觀察性體系，需要引入大量的垂直系統。這些系統之間有不同的存儲格式，接口不統一，有不同的軟體體驗，往往難以形成合力。
- 第二大挑戰來自于性能與速度。資料分析的過程實際上是把專家經驗（Domain Knowledge）沉澱的過程，而Ops場景一般都是Mission Critical過程，是以需要非常快地分析速度和所見即所得能力。
- 第三大挑戰來自于分析能力。在接入足夠多的資料後，往往會面臨監控項太多，資料量太多，線索太多等問題，我們需要有成套的方法幫助我們去降維、去發現、去關聯、去推理。AIOps算法目前聚焦在這一層上。
前兩個問題本質上是一個系統問題，而後面兩個問題和算法與算力相關。中台的推出可以解決第1和第2個問題。
三 阿裡雲SLS，自研自用可觀察性中台
2015年我們研發了SLS，經過幾年的錘煉和演進，正在向統一的可觀察性中台發展。SLS向下對接各種開源的協定與資料源，向上對各種場景提供支撐能力。核心能力在于圍繞可觀察性的各種監控資料，提供統一的存儲與計算能力，平台可以用 “1、2、3、4” 四個詞來概括。
- “1” 代表一個中台。
- “2” 代表提供兩種基本的存儲模型：Logstore與MetricStore，分别面向适合Trace/Log類型的日志存儲（Logstore），适合監控資料Metric類型的時序存儲（MetricStore）。這兩種存儲并不是孤立的，建立在統一的存儲概念上，并且可以非常靈活的互相轉化。
- “3” 代表三類分析引擎：資料加工引擎（DSL）、SQL查詢分析引擎（SQL）、智能分析引擎（AIOps）。DSL主要面向資料加工和與預處理場景，解決格式多樣化的問題；SQL查詢分析引擎面向存儲資料提供清洗、計算能力；而内嵌的AIOps可以給特定問題提供智能算法。
- “4” 代表四類典型場景：例如ITOps、DevOps、SecOps、BusinessOps等。涉及到運維、研發、營運和黑客增長等領域。阿裡集團80%以上類似場景都基于SLS來建構。
平台始終向使用者提供支撐能力，相容各種資料源與協定，支撐業務但不做業務産品。
1 存儲設計
為了建構可觀察性的中台，我們先看看目前存儲系統的現狀。在運維領域AIOps系統的建構過程中，長期并存四種類型的存儲系統，分别是：
- Hadoop/Hive：存放曆史日志，Metric等資料，存儲成本便宜，分析能力較強，但延時較高。
- ElasticSearch：存放需要實時通路的Trace，Log資訊，檢索速度快，但成本較高，适合近線的熱資料，分析能力中等。
- NoSQL：用來存儲經過聚合的名額類資料，TSDB類是NoSQL存儲擴充，檢索聚合後的名額速度快，成本較便宜，缺點是分析能力較弱。
- Kafka：用來導入導出路由各種資料，主要存儲臨時資料，上下遊接口豐富，沒有分析能力。
這四類獨立的存儲系統較好地解決了四種不同類型的需求，但存在兩大挑戰：
資料流動性
資料存儲後能夠支撐某個場景的服務能力，但随之而來的問題就是流動性。資料存在于多個系統中，做資料關聯、對比、整合時就需要去搬資料，這往往需要花費非常多的時間。
接口易用性
面對不同的存儲對象的接口不統一，例如Log一般使用ES的API來包裝，而Metric一般會用Prometheus協定或通過NoSQL接口直接調用等等。為了內建資料往往需要涉及到不同的API與互動方式，增加了系統的整體複雜性。
目前四種存儲系統的現狀導緻資料使用需要較長的周期及一定的開發量，限制了AIOps，DataOps等場景發揮更大的作用。
2 如何抽象存儲
如果我們把監控資料的生成過程做一個抽象，可以發現一般會由兩個過程組成：變化+狀态。所有的事物都是一個待續變化的過程，例如資料庫的一張表在某一個時刻（例如2點）的狀态實際上是由曆史上所有變化累計的結果。在監控領域中也是一樣，我們可以通過Log、Trace等方式把系統狀态的變化盡可能儲存（或采樣）下來。例如使用者在1小時内做了5次操作，我們可以把這5次操作的日志或Trace捕捉下來。當我們需要一個狀态值時（比如2點的系統狀态是什麼），我們可以對這些所有的記錄檔做一個回放，形成某一個時間點的一個彙總值，例如在視窗大小為1小時的區間内，操作QPS為5。這裡就是一個簡單的Log轉為Metric的關系，我們可以使用其他邏輯，例如對Log中的Latency字段做一個Avg來獲得該視窗的Latency。
在SLS存儲設計的過程中，我們也遵循了這樣的客觀規律：
- 底層提供了一個FIFO Binlog隊列，資料寫入和讀取都是順序的，以嚴格的寫入時間（Arrival Time）作為排序。
- 在Binlog之上，我們可以挑選某些字段生成一個Logstore，Logstore可以認為是資料庫的一個表：是帶Schema的，至少有EventTime這個字段（事件發生的原始時間），可以指定列的類型和名字。這樣我們就可以通過關鍵詞和SQL檢索Logstore中的内容。
- 除此之外，我們可以根據需求對Logstore中的某些列生成多個Metric存儲，例如根據Host+Method+Time建構一個以Host+Method作為Instance的監控資料存儲表，進而可以根據時間段把資料撈出。
讓我們來看一個例子：以下是一個站點的通路記錄，在1秒内經曆了4次通路。
time, host, method, latency, uid, status
[2020-08-10 17:00:00, Site1, UserLogin, 45ms, 1001, OK]
[2020-08-10 17:00:01, Site1, UserBuy, 25ms, 1001, OK]
[2020-08-10 17:00:01, Site1, UserBuy, 1ms, 1001, OK]
[2020-08-10 17:00:01, Site1, UserLogout, 45ms, 1001, OK]
[2020-08-10 17:00:01, Site2, UserLogin, 45ms,1002, Fail] 當這些資料寫入Logstore後，相當于寫入了一張存放日志的資料庫，可以通過SQL對其中任意字段進行查詢與分析。例如“ select count(1) as qps”，獲得目前彙總的QPS。
也可以通過預定義好一些次元，例如希望通過host+method組合來建構最小監控粒度，每隔1秒鐘獲得QPS，Latency等資料，那我們可以定義如下的MetricStore，當資料寫入後，能夠自動根據規則生成如下結果：
[host, method, time], [qps, latency]
[site1, userLogin, 2020-08-10 17:00:00], [1, 45]
[site1, userBuy, 2020-08-10 17:00:01], [2, 15]
[site1, userLogout, 2020-08-10 17:00:01], [1, 25] 通過這種方式，我們就可以在一種存儲中通過原始資料的存儲、聚合形成日志與Metric轉移。
3 計算設計
根據平時遇到的場景，我們把監控資料的計算抽象成三類問題：
- 非結構化資料如何變為結構化資料
- 面對複雜系統，能否設計一套所見即所得低門檻語言進行資料分析
- 面對海量資訊，是否有降維算法來降低問題複雜度
我們建構了三類計算方法分别來處理以上問題：
第一個問題實際上一個業務複雜度的問題，根源來自産生資料的人和使用資料的人之間的GAP。在大部分開發流程中打日志的往往是開發者，但分析日志的往往是運維和營運，在寫日志過程中沒有足夠預見性導緻資料無法直接被使用。這裡需要有一套低代碼開發的語言來做各種各樣的資料轉化、分派、富化，把多個業務系統不同格式的資料進行簡化。為此我們設計了一套面向資料加工（ETL）場景的語言（DSL)，該語言提供了300多個常用算子，專制日志格式的各種疑難雜症。
例如在原始日志中，隻有一個project_id字段在通路url參數裡，ip這個字段對應的設計我們無法拿到。在SLS的DSL語言中，我們隻需要寫3行代碼，從url中提取參數，與資料庫中字段進行富化。原來看起來無用的通路日志就立即盤活，可以分析出主機和使用者之間的通路關系了。
第二個問題是一個多語言融合的問題，我們的選擇是以SQL作為查詢和分析架構，在架構中融入PromQL及各種機器學習函數。這樣就可以通過子查詢+主查詢進行嵌套，對結果進行計算并預測。
SLS SQL = Search + SQL92（Agg，WIndow，GroupBy...）+ PromQL + ...
以下就是一個複雜分析的例子：
- 先通過調用promql算子拿到主機每分鐘的監控值
- 通過視窗函數對原始資料進行降采樣，例如變為每秒的數值
- 通過外層的預測函數對查詢結果進行預測
第三個問題是算法的問題，我們内置了大量基于AI的巡檢、預測、聚類、根因分析等算法，可以在人工分析和自動巡檢告警中直接使用到。這些算法通過SQL/DSL函數向使用者提供，可以在各種場景中用到。
四 中台支撐案例
SLS在阿裡集團内外有萬級的使用者，大量運用到AIOps各種資料分析場景中，這裡列舉兩個比較有意思的案例。
案例1：流量解決方案
流量日志是最常見的通路日志類型，無論是Ingress，Nginx還是CDN Access Log都可以抽象成通路日志類型，在SLS解決方案中：
- 采集一份原始日志保留7天時間（LogStore）進行查詢，更長時間備份到對象存儲（OSS）。
- 通過SLS原生的SQL對日志進行資料加工+各次元聚合，例如根據微服務接口進行Group By。
- 對聚合後的資料進行時序類型存儲（MetricStore）。
- 通過AIOps巡檢函數對數以千計的接口進行智能巡檢，生成告警事件。
整個過程從采集到配置到運作隻需要花5分鐘，滿足多樣性需求。
案例2：雲成本監控與分析
阿裡雲的使用者每天會面臨大量的賬單資料，雲成本中心就利用SLS采集、分析、可視化與AIOps功能開發了一款成本管家應用，智能幫助使用者分析雲産品成本，預測成本的趨勢，找到賬單中異常的原因。
五 寫在最後
雖然過去幾年我們沒有直接做AIOps應用，但通過把資料能力、AI能力中台化，反而支撐了更多的使用者與場景。最後簡單總結下過去兩年做可觀察性中台的心得體會：
AIOps = AI + DevOps/ITOps/SecOps/BusinessOps…
目前大部分人覺得AIOps解決的是運維的問題，實際上該套方法可以無縫地切換到各種OPs場景中，例如DevOps，SecOps（Bigdata Security），以及通過AI來進行運維與使用者增長，方法都是通用的。和AI所在的任何一個領域一樣，資料是根本、算力是基礎、算法是核心，缺一不可。
Domain Knowledge是AIOps落地關鍵
一個有經驗的運維或分析師，對系統有深刻的見解和模組化經驗。是以AIOps要落地，我們必須尊重專家系統的經驗沉澱，例如通過模闆化、知識表示與推理、或在一些場景中使用遷移學習等。