螞蟻集團技術風險程式碼化平臺實踐（MaaS）

?

文｜吳成輝（花名：清霄螞蟻集團高階技術專家)

校對｜陳真、莊曉丹、馮家純

本文 6250 字閱讀 11 分鐘

▼

我們一起回顧下監控上層業務曾經面臨的問題：

煙囪式的監控分析重複建設

在技術風險領域，一度有超過 5 個系統在做監控分析的能力建設，大致邏輯基本都是拉監控的 Raw Data，做基礎的聚合、分析處理後（類似同環比、閾值類的方式），根據一些當前的場景輸入，結合一些演算法能力，得出一個結論並觸發一系列的 Action。類似這種煙囪式的監控分析場景，都是比較初級的重複建設，缺乏智慧化、體系化。

SRE 經驗標準化沉澱的問題

在分析場景裡也面臨 SRE 經驗無法標準化沉澱複用的問題，什麼是 SRE 經驗？拿交易付款下跌來舉例，如果當前交易付款下跌 10%，SRE 通常有這麼幾個分析路徑，首先看下淘寶交易是否下跌（來源），再看交易建立，收銀臺渲染是不是下跌等，這一類我們稱為業務依賴。從全域性看是否有大規模的壓測、變更等動作，這一類稱為變更關聯，以及如何根據當前故障情況決策進行切流、限流等恢復措施，我們稱為分析後置操作。

長尾需求

比如比較常見的，算多資料之間的成功率，流量損耗等等需求，通過產品化解決的成本非常高，而且使用者不能快速修改、定製相關能力。

在這裡插入圖片描述

同時我們看到當前監控系統自身面臨的問題：

監控的資料使用複雜

包含了幾萬張資料表、十幾萬張自定義資料表，資料型別超過 20+，以及跨站點、資料來源異構等等問題。

監控服務不夠開放

如何動態日誌清洗計算、如何做分析後的時序儲存、監控的時序檢測能力如何複用等等。我們需要把監控的資料、能力完全服務化出來。

高效的可程式設計程式碼化平臺缺失

沒有一個高效平臺幫助 SRE 先沉澱經驗、再促進經驗的標準化、複用，最後產品化。

基於上面問題，我們提出了 MaaS 的設想（Monitoring as a Service), 監控能力服務化，開放、融合監控能力到技術風險各個領域，快速完成 SRE 場景建設，沉澱可複用能力，主要包含以下 4 個階段目標：

在這裡插入圖片描述

1.開放服務把監控的計算、儲存、演算法、檢視等等能力開放出來。

2.核心共建幾個重點的技術風險領域場景，比如變更防禦、壓測引流、無損注入、定位應急等等。

3.促進服務的標準化沉澱，讓更多的場景可以複用、共同建設這部分的能力。

4.解決“監”與“控”之間的連結問題。

在這裡插入圖片描述

（我們的這裡的 AIOPS 更多指的是

一系列專家經驗的集合、沉澱、持續維護優化）

PART. 1 平臺技術概覽

能力服務化

監控的服務化能力整體包含這麼幾部分，資料服務化、配置服務化、計算、儲存服務化、演算法服務化、通知、雲原生服務化等等，也包括一些外部能力整合比如訊息快取等等。

我簡單舉兩個服務化的例子來介紹下什麼是服務化：

比如檢視服務，當某個變更發起後，這個變更關聯的 100 個應用指標、20 個業務指標中的 10 個指標出現了問題，這個時候，我們需要動態為這個 10 個指標建立一個資料檢視，來分析業務影響範圍，這個時候就會用到我們的檢視服務。

動態計算服務，比如我需要實時計算下某個應用在 A 機房（或某個 ZONE 如：GZXXX）的其中 5 臺機器在 11:00~12:00 的介面方法呼叫情況，動態的計算服務就會派得上用場。

在這裡插入圖片描述

資料服務化

能力服務化中非常重要的一環就是資料服務化，因為資料是所有監控分析的基礎，資料服務化主要分成兩部分。

第一步是監控資料模型化

我們從資料的使用視角把資料抽象出資料虛擬表、虛擬表列定義、列關係。以及虛擬表的實現繫結，包含指標資料，也包含關係後設資料，最後把這些物理實現對映到監控具體的資料指標或者底層的後設資料服務上。

第二步是服務模板化

我們把一個資料服務抽象出三類：

實體查詢，比如查詢一個應用或者一個 Tbase 的叢集；

資料查詢，比如查詢一個應用的 Sofa Service 在 APP 聚合維度上的資料；

關係查詢，查詢一個實體的關聯實體，比如 cif 關聯的 Tbase 叢集等。

最後，我們實現了 5w+ 資料服務自動生成，分鐘級別 SDK 更新的能力，我們可以通過非常語義化的訪問方式來訪問監控的所有資料，我們可以做到只要是監控體系內的資料，都可以通過我們這套能力訪問到對應的資料服務，從而達到整個監控資料的服務化開放。

在這裡插入圖片描述

研發效能

大庫管理，我們設計了一種可以支援服務沉澱、許可權隔離（可以獨立按目錄管理 CR）、邏輯複用的程式碼結構，比如快取 Tbase 的研發 + SRE 可以共同在 cache 目錄裡面定義快取問題的發現、分析、恢復。同時可以複用到 core-service 裡面的比如容器是否健康，網路是否異常等標準服務。平臺能夠提供一致的多環境除錯能力，方便監控分析邏輯可以直接執行在本地 IDE 環境中，我們通過動態代理的模式把本地訪問的資料、函式服務代理到服務端，從而達到了本地跟線上完全一致的研發體驗。這項能力極大地提高了研發效率，研發過程中可以直接 debug 線上資料，比傳統的日誌模式的除錯方式有非常大的效率提升，一個基礎的分析函式基本可以在小時級別內完成。

一站式釋出運維，傳統的 Serverless 釋出模式大致要經歷這麼幾個階段，從工程打包到 Jar 檔案，耗時 1min，大概在 100-300MB，從 Jar 檔案打包 Build 出映象，大致 10min，最後做映象化釋出整體耗時約 20min, 整體流程大概耗費半個小時。我們研發了一套基於函式粒度的釋出運維模式，以 MaaSFunction 為入口，做跨檔案 Linker，如何做 Linker，看這個示意圖，我們從 MaasFunction 入口開始解析本類依賴的檔案，比如這邊依賴的其他函式，到下面的 service，再到 util 層的相互依賴，從而通過這種方式解析出業務程式碼片段，通過動態編譯完 Jar 大小目前最大在 500KB 左右，根據程式碼大小一般在 5s 內，再通過熱載入到目標機器上，整體可以做到 5s 級釋出，1s 回滾，其他還有配套的日誌、監控等等能力。

在這裡插入圖片描述

多語言 Runtime

我們在初期建設的時候函式是都執行在一個叢集裡面，經常會遇到例如：死迴圈、OOM、執行緒頻繁建立等等效能問題，因為業務程式碼不可控，CR 不能完全杜絕這類問題，這樣我們就需要完全隔離的函式執行環境，從圖中可以看到，每個函式至少具備 2 個獨立的容器（容災的需要），函式 1OOM（Out Of Memory），不會影響到函式 2。這樣我們就可以基本做到函式級別的執行層隔離，我們通過 SLO 的度量，平臺穩定性有了非常大的提升。

當我們按照函式級別隔離的模式大規模上線的時候遇到了成本問題，底層 sigma 支援的 pod 排程的最小規模是 0.5c（底層物理網路卡等等限制），如果 2 臺容災，基本上一個函式至少佔用 1c 的物理資源，隨著函式業務的大規模使用，這塊成本是很難持續的。通過我們的觀察，絕大多數函式佔用實際的 CPU10% 不到，甚至更低。我們同 Serverless Paas 團隊一起共建了函式的高密度部署模式，通過 0.5c 的 pod 中隔離 5 個 0.1c 的容器，然後通過容器 IP + 埠的方式繫結到函式的執行上去，這樣整體的資源成本可以從 1c 降低到 0.2c，成本降低到 1/5。

在這裡插入圖片描述

最近我們還支援了 Python 語言，下圖是簡易的程式碼 Demo。

在這裡插入圖片描述

PART. 2 應用場景

變更監控

螞蟻變更故障佔比是整體故障佔比的三分之一，而監控是變更過程中非常重要的一環，當前面臨很多問題，當一個變更發起的時候，我們拿到根據變更的範圍，自動化的生成核心的系統、業務指標比如應用的 gc 、CPU 、服務成功率，錯誤資料等等，解決第一個不知道變更看什麼指標的問題。我們的 MaaS 計算服務會根據變更範圍動態生成一組指標的實時計算，（變更前、變更後，變更組、非變更組）等等，因為是根據變更範圍動態生成的計算，所以解決了監控粒度粗的問題，這些資料產出後，根據我們的異常檢測演算法，得出本次變更過程是否有指標異常，解決不知道怎麼看的問題，我們通過函式編排的方式同變更核心流程打通，整個過程無需使用者參與，如果變更監控發現異常會自動觸發攔截阻塞異常。

有效：全年累計攔截真實故障 163 筆，變更監控攔截 75 筆，佔總體攔截數的 46.01%。

通用：變更監控核心防禦服務統一，覆蓋全站 87.74% 主要運維場景。

規模：日均 1.2w 次變更防禦，30w 動態監控建立。

在這裡插入圖片描述

業務鏈路報警分析

常態情況下業務告警噪音的比例達到了 66%，對日常研發、SRE 同學的打擾非常高，不利於業務的應急流程、穩定性建設。其實 SRE 同學有非常多的噪音判定經驗，但是降噪邏輯沒法自定義，導致降噪非常困難。

我們通過與國際 SRE 團隊深度共建，建設了一套告警分析服務，流程可以簡單概括為：

構建業務鏈，拉資料
做異常檢測
定位分析
推送異常、構建分析檢視

通過這個場景，我們可以看到 SRE 經驗是什麼，什麼是來源下跌、如何處理小流量業務，如何處理業務過程中正常的服務損耗，以及如何做業務的分析定位等等。

告警有效率從 34.68% 提升到 91.15%。
國際 GOC P1、P2 業務告警覆蓋率 85%， S2 大規模推廣到全站。
SRE 從整體構思到第一個 Poc 實現只花了 2 周時間。

配置程式碼化

這個場景主要是要解決批量化覆蓋的效率問題，比如模擬建站，應用監控規則自動覆蓋等場景，我們通過服務化的方式把這些能力暴露出來達到一個提效的效果。簡單拿應用監控規則覆蓋來說，程式碼邏輯是通過先配置好模板，然後經過一些配置替換，最後批量大規模覆蓋。在模擬環境建設過程中，做到了根據流量實時調整閾值，0 人工配置，重慶消金建站，5 人天的配置工作降低到 0 人工監控配置。應用規則自動化覆蓋也是從往年 527 的幾十人日，降低到 1 小時。

（中介軟體 SRE 同學的程式碼化案例：）

應用規則自動化覆蓋：

全站應用規則覆蓋降低到 1 小時，527 國際應用告警 0 人工配置。

xx 業務建站：

中介軟體 10+ 產品降低到 0 人工監控配置。

模擬環境建設：

模擬規則自動化覆蓋、閾值動態調整，0 人工配置。

在這裡插入圖片描述

後續我們會有更多的系列文章來詳盡的介紹如何通過 MaaS 來做更多技術風險能力建設（盡請期待），這裡先不展開敘述了。

PART. 3 寫在最後

MaaS 未來規劃主要分三部分：

平臺能力建設，把監控的服務化路徑複製到技術風險更多場景，動態彈性、以及研發流程標準化。

程式碼生態化建設、社群化建設，建設監控分析領域的服務目錄（比如說容器 CPU 如何分析、熱點方法是什麼等等），函式服務、應用市場的建設，來讓更多 SRE 合作在一個領域裡面進行持續建設，最後是社群化的運營能力。

監控 + X（跨技術風險領域）探索，從我們這兩年的經驗來看，監控 + 變更 = 變更監控、監控 + 演練 = 無損注入、監控 + 壓測 = 效能分析等等，我們看到了這些領域一些質的變化，我們希望挖掘出更多這樣的場景，比如監控 + 限流 + 容量，做精細化的限流能力建設等等。

在這裡插入圖片描述

如上圖，MaaS 的 Logo 看起來像一個木頭搭成的房子，象徵著我們希望業務能夠像積木一樣快速建設，M 又是兩個小三角形，三角形象徵著穩定，我們希望 MaaS 平臺能夠非常穩定地支援上面的業務。M 中還融合了曲別針的圖形，象徵著連線。

平臺的目標與夢想：有一天我們分析作業系統不再找系統部同學，分析中介軟體不再依賴中介軟體同學，分析快取不再等著同學（支付寶一位負責快取的 SRE 專家）給排查結論，程式起不來，配置中心連不上，都可以通過程式碼線上診斷的方式一鍵分析，而不是冗長低效、口口相傳的文件，讓技術風險知識可以真正通過程式碼的方式共享。

我們夢想整個技術風險能力都可以通過 MaaS 平臺實現 Auto 化。有一天，秒級壓測熔斷、變更防禦、流量精細化調撥、預案決策、自愈等等可以真正做到 Auto，真正的無人值守。

END -

2019 年雙十一之後，我們開始了 MaaS，一晃近兩年了。到目前為止，MaaS 有效研發使用者近 200 人，函式服務超過 1000+，日函式呼叫達到 1000w，分析近 200 億資料點。我們的 MaaSHub（社群化產品）、多語言支援等等也在快速迭代中。

質疑

MaaS 在最早期推廣的時候（包括現在仍然存在），為什麼要用這個平臺？其實大多數同學是帶著質疑的，最常見的幾個反問：我的程式碼為什麼要寫在你的平臺；你們平臺現在還不成熟，我的業務很重要；我只是想拉個資料而已，還要學你這麼複雜的東西等等。這個過程比較艱難，但是通過我們的引導和支援，使用者已經可以自助地在平臺上做各種函式研發，並且使用者之間開始自發推廣傳播，不是我們平臺牛逼，而是我們有監控堅實的資料、計算、儲存、演算法能力，有整個 Antmonitor 40 人團隊作為我們最堅定的後盾。

獲客成本

程式碼化的產品是天然區別於產品化產品的，在早期時候，服務化能力匱乏，單個使用者的轉化留存，至少要花費 2 人/周的研發成本，可以想象這樣高昂的付出促使我們會多麼珍惜現有的 200+ 使用者，需求基本都是當天研發到預發，次日上線。讓使用者有了安全感、信任感，才能留存。

平臺生態

生態這個詞比較大，比較空。用寫實一點的話來描述，如何建設 MaaS 生態，需要回答好下面幾個問題：

如何讓使用者的程式碼慢慢轉換為平臺的沉澱，快取的診斷程式碼到底什麼時候能夠做到標準化、快速複用（快取是我們合作比較久，相對已經是比較成熟的領域），這個很難，但是需要去做，或者說我們需要建立一種機制讓這個通道變得可能、簡單。
平臺的沉澱如何再反向促進平臺使用者的發展，平臺有了非常多的分析能力，如果快速推介到使用者，讓使用者感知到，使用起來，讓使用者構建場景更加簡單、快速。
如何複用使用者場景，使用者解決的問題是一個特例問題，還是一個通用問題？如果是通用問題，是不是可以直接通過複用使用者場景，達到通用問題解決方案的邏輯複用。

當然整個服務化的過程是非常乏味、枯燥的。未來我們想從監控跨越到技術風險，那麼更多技術風險平臺的服務化整合是條必經之路。但是如何快速整合外部系統的服務化能力，這塊我們也正在做一些探索，並且已取得了一些成果。

大庫模式 & FaaS 模式的生產實踐

為什麼採用大庫，大庫主要解決程式碼透明性的問題，透明性的目標是為了促進程式碼沉澱、更高層次的複用，所以我們摒棄了傳統 FaaS 平臺的單函式單庫模式，因為我們的首要目標是程式碼的沉澱複用，其次是高效的函式研發平臺。

FaaS 模式還是太超前了，絕大多數同學還是習慣於傳統的 Project 模式，各種三方包、TR 、反射滿天飛，不太適應函式的研發模式，在這個過程中我們也做了非常多的相容，讓函式也能像傳統應用一樣使用各種功能，但是在 Serverless 還沒有普及的今天， FaaS 未來的路是還需要更多的探索與實踐創新。