DAS（Database Autonomy Service， 資料庫自治服務）面向研發和DBA，是一款為使用者提供資料庫效能分析、故障診斷、安全管理等功能的資料庫自治服務。DAS利用大資料手段、機器學習、專家經驗，幫助使用者消除資料庫管理的複雜性及人工操作引發的服務故障，有效保障資料庫服務的穩定和高效執行。本文主要講述DAS的歷史背景、演進策略、重要功能及實現思路，希望能對從事相關開發的同學有所幫助或者啟發。

1 現狀與問題

1。1 規模增長與運維能力發展之間的不平衡問題凸顯

伴隨著最近幾年美團業務的快速發展，資料庫的規模也保持著高速增長。而作為整個業務系統的“神經末梢”，資料庫一旦出現問題，對業務造成的損失就會非常大。同時，因資料庫規模的快速增長，出現問題的數量也大大增加，完全依靠人力的被動分析與定位已經不堪重負。下圖是當時資料庫例項近年來的增長趨勢：

圖1 資料庫例項增長趨勢

1。2 理想很豐滿，現實很骨感

美團資料庫團隊當前面臨的主要矛盾是：例項規模增長與運維能力發展之間的不平衡，而主要矛盾體現在資料庫穩定性要求較高與關鍵資料缺失。由於產品能力不足，只能依賴專業DBA手動排查問題，異常處理時間較長。因此，我們決定補齊關鍵資訊，提供自助或自動定位問題的能力，縮短處理時長。

我們覆盤了過去一段時間內的故障和告警，深入分析了這些問題的根因，發現任何一個異常其實都可以按時間拆分為異常預防、異常處理和異常覆盤三階段。針對這三階段，結合MTTR的定義，然後調研了美團內部及業界的解決方案，我們做了一張涵蓋資料庫異常處理方案的全景圖。如下圖所示：

圖2 運維能力的現狀

透過對比，我們發現：

每個環節我們都有相關的工具支撐，但能力又不夠強，相比頭部雲廠商大概20%～30%左右的能力，短板比較明顯。

自助化和自動化能力也不足，工具雖多，但整個鏈條沒有打通，未形成合力。

那如何解決這一問題呢？團隊成員經過深入分析和討論後，我們提出了一種比較符合當前發展階段的解決思路。

2 解決的思路

2。1 既解決短期矛盾，也立足長遠發展

從對歷史故障的覆盤來看，80%故障中80%的時間都花在分析和定位上。解決異常分析和定位效率短期的ROI（投資回報率）最高。長期來看，只有完善能力版圖，才能持續不斷地提升整個資料庫的穩定性及保障能力。因此，我們當時的一個想法就是既要解決短期矛盾，又要立足長遠發展（Think Big Picture， Think Long Term）。新的方案要為未來留足足夠的發展空間，不能只是“頭痛醫頭、腳痛醫腳”。

在宏觀層面，我們希望能將更多的功能做到自動定位，基於自動定位來自助或自動地處理變更，從而提高異常恢復的效率，最終提升使用者體驗。將異常處理效率提高和使用者體驗提升後，運維人員（主要是DBA）的溝通成本將會極大被降低，這樣運維人員就有更多時間進行技術投入，能將更多“人肉處理”的異常變成自助或自動處理，從而形成“飛輪效應”。最終達成高效的穩定性保障的目標。

在微觀層面，我們基於已有的資料，透過結構化的資訊輸出，提升可觀測性，補齊關鍵資料缺失的短板。同時，我們基於完善的資訊輸出，透過規則（專家經驗）和AI的配合，提供自助或自動定位的能力，縮短處理時長。

圖3 宏觀和微觀

2。2 夯實基礎能力，賦能上層業務，實現資料庫自治

有了明確的指導思想，我們該採取怎樣的發展策略和路徑呢？就當時團隊的人力情況來看，沒有同學有過類似異常自治的開發經驗，甚至對資料庫的異常分析的能力都還不具備，人才結構不能滿足產品的終極目標。所謂“天下大事必作於細，天下難事必作於易”。我們思路是從小功能和容易的地方入手，先完指標監控、慢查詢、活躍會話這些簡單的功能，再逐步深入到全量SQL、異常根因分析和慢查詢最佳化建議等這些複雜的功能，透過這些基礎工作來“借假修真”，不斷提升團隊攻堅克難的能力，同時也可以為智慧化打下一個良好的基礎。

以下便是我們根據當時人才結構以及未來目標設定的2年路徑規劃（實現資料自治目標規劃在2022以後的啟動，下圖會省略掉這部分）：

圖4 演進策略

2。3 建立科學的評估體系，持續的跟蹤產品質量

美國著名管理學者卡普蘭說過：“沒有度量就沒有管理”。只有建立科學的評估體系，才能推進產品不斷邁向更高峰，怎樣評估產品的質量並持續改善呢？之前我們也做過很多指標，但都不可控，沒有辦法指導我們的工作。比如，我們最開始考慮根因定位使用的是結果指標準確率和召回率，但結果指標不可控難以指導我們的日常工作。這就需要找其中的可控因素，並不斷改善。

我們在學習亞馬遜的時候，剛好發現他們有一個可控輸入和輸出指標的方法論，就很好地指導了我們的工作。只要在正確的可控輸入指標上不斷最佳化和提升，最終我們的輸出指標也能夠得到提升（這也印證了曾國藩曾說過的一句話：“在因上致力，但在果上隨緣”）。

以下是我們關於根因定位的指標設計和技術實現思路（在模擬環境不斷提升可控的部分，最終線上的實際效果也會得到提升。主要包括“根因定位可控輸入和輸出指標設計思路”和“根因定位可控輸入指標獲取的技術實現思路”）。

根因定位可控輸入和輸出指標設計思路

圖5 可控輸入與輸出指標設計

根因定位可控輸入指標獲取的技術實現思路

圖6 可控輸入與輸出指標技術設計

在圖5中，我們透過場景復現方式，用技術手段來模擬一些用低成本就能實現的異常（絕大部份異常）。在對於復現成本比較高的異常（極少部分），比如機器異常、硬體故障等，我們目前的思路是透過“人肉運營”的方式，發現和最佳化問題，等到下次線上異常重複發生後，根據最佳化後診斷的結果，透過和預期比較來確定驗收是否透過。

未來我們會建立回溯系統，將發生問題時刻的異常指標儲存，透過異常指標輸入給回溯系統後的輸出結果，判斷系統改進的有效性，從而構建更加輕量和更廣覆蓋的復現方式。圖6是復現系統的具體技術實現思路。

有了指導思想，符合當前發展階段的路徑規劃以及科學的評估體系後，接下來聊聊技術方案的構思。

3 技術方案

3。1 技術架構的頂層設計

在技術架構頂層設計上，我們秉承平臺化、自助化、智慧化和自動化四步走的演進策略。

首先，我們要完善可觀測的能力，透過關鍵資訊的展示，構建一個易用的資料庫監控平臺。然後我們根據這些關鍵資訊為變更（比如資料變更和索引變更等）提供賦能，將一部分高頻運維工作透過這些結構化的關鍵資訊（比如索引變更，可以監測近期是否有訪問流量，來確保變更安全性）讓使用者自主決策，也就是自助化。接下來，我們加入一些智慧的元素（專家經驗+AI），進一步覆蓋自助化的場景，並逐步將部分低風險的功能自動化，最終透過系統的不斷完善，走到高階或完全自動化的階段。

為什麼我們將自動化放在智慧化之後？因為我們認為智慧化的目標也是為了自動化，智慧化是自動化的前提，自動化是智慧化的結果。只有不斷提升智慧化，才能達到高階或者完全自動化。下圖便是我們的頂層架構設計（左側是演進策略，右側是技術架構的頂層設計以及2021年底的現狀）：

圖7 架構頂層設計

頂層設計只是“萬里長征第一步”，接下來我們將自底向上逐步介紹我們基於頂層設計開展的具體工作，將從資料採集層的設計、計算儲存層的設計和分析決策層的設計逐步展開。

3。2 資料採集層的設計

這上面的架構圖裡，資料採集層是所有鏈路的最底層和最重要的環節，採集資料的質量直接決定了整個系統的能力。同時，它和資料庫例項直接打交道，任何設計上的缺陷都將可能導致大規模的故障。所以，技術方案上必須兼顧資料採集質量和例項穩定性，在二者無法平衡的情況下，寧可犧牲掉採集質量也要保證資料庫的穩定性。

在資料採集上，業界都採取基於核心的方式，但美團自研核心較晚，而且部署週期長，所以我們短期的方式是採用抓包的方式做一個過渡，等基於核心的採集部署到一定規模後再逐步切換過來。以下是我們基於抓包思路的技術方案調研：

從調研上我們可以看到，基於pf_ring和dpdk的方案都有較大的依賴性，短期難以實現，之前也沒有經驗。但是，基於pcap的方式沒有依賴，我們也有過一定的經驗，之前美團酒旅團隊基於抓包的方式做過全量SQL資料採集的工具，並經過了1年時間的驗證。因此，我們最終採取了基於pcap抓包方式的技術方案。以下是採集層方案的架構圖和採集質量以及對資料庫效能帶來的影響情況。

Agent的技術設計

圖8 Agent的技術設計

對資料庫的影響

圖9 Agent對資料庫的影響測試

3。3 計算儲存層的設計

由於美團整個資料庫例項數量和流量巨大，而且隨著業務的快速發展，還呈現出快速增長的態勢。所以，我們的設計不僅要滿足當前，還要考慮未來5年及更長的時間也能夠滿足要求。同時，對資料庫故障分析來說，資料的實時性和完備性是快速和高效定位問題的關鍵，而保證資料實時性和完備性需要的容量成本也不容忽視。因此，結合上述要求和其他方面的一些考慮，我們對該部分設計提出了一些原則，主要包括：

全記憶體計算

：確保所有的計算都在單執行緒內或單程序內做純記憶體的操作，追求效能跟吞吐量的極致。

上報原始資料

：MySQL例項上報的資料儘量維持原始資料狀態，不做或者儘量少做資料加工。

資料壓縮

：由於上報量巨大，需要保障上報的資料進行極致的壓縮。

記憶體消耗可控

：透過理論和實際壓測保障幾乎不可能會發生記憶體溢位。

最小化對MySQL例項的影響

：計算儘量後置，不在Agent上做複雜計算，確保不對RDS例項生產較大影響。以下是具體的架構圖：

圖10 Agent對資料庫的影響測試

全量SQL（所有訪問資料庫的SQL）是整個系統最具挑戰的功能，也是資料庫異常分析最重要的資訊之一，因此會就全量SQL的聚合方式、聚合和壓縮的效果和補償設計做一些重點的介紹。

3。3。1 全量SQL的聚合方式

由於明細資料巨大，我們採取了聚合的方式。消費執行緒會對相同模板SQL的訊息按分鐘粒度進行聚合計算，以“RDSIP+DBName+SQL模版ID+SQL查詢結束時間所在分鐘數”為聚合鍵。聚合健的計算公式為：Aggkey=RDS_IP_DBName_SQL_Template_ID_Time_Minute （Time_Minute的值取自SQL查詢結束時間所在的“年、月、日、時、分鐘”）

圖11 SQL模版聚合設計

圖12 SQL模版聚合方法

3。3。2 全量SQL資料聚合和壓縮的效果

在資料壓縮方面，遵循層層減流原則，使用訊息壓縮、預聚合、字典化、分鐘級聚合的手段，保證流量在經過每個元件時進行遞減，最終達到節省頻寬減少儲存量的目的。以下是相關的壓縮環節和測試資料表現情況（敏感資料做了脫敏，不代表美團實際的情況）：

圖13 全量SQL壓縮設計與效果

3。3。3 全量SQL資料補償機制

如上所述，在資料聚合端是按一分鐘進行聚合，並允許額外一分鐘的訊息延遲，如果訊息延遲超過1分鐘會被直接丟棄掉，這樣在業務高峰期延遲比較嚴重的場景下，會丟失比較大量的資料，從而對後續資料庫異常分析的準確性造成較大的影響。

因此，我們增加了延遲訊息補償機制，對過期的資料發入補償佇列（採用的是美團訊息佇列服務Mafka），透過過期資料補償的方式，保證延遲久的訊息也能正常儲存，透過最終一致性保證了後續的資料庫異常分析的準確性。以下是資料補償機制的設計方案：

圖14 全量SQL補全技術設計

3。4 分析決策層的設計

在有了比較全的資料之後，接下來就是基於資料進行決策，推斷出可能的根因。這部分我們使用了基於專家經驗結合AI的方式。我們把演進路徑化分為了四個階段：

第一階段

：完全以規則為主，積累領域經驗，探索可行的路徑。

第二階段

：探索AI場景，但以專家經驗為主，在少量低頻場景上使用AI演算法，驗證AI能力。

第三階段

：在專家經驗和AI上齊頭並進，專家經驗繼續在已有的場景上迭代和延伸，AI在新的場景上進行落地，透過雙軌制保證原有能力不退化。

第四階段

：完成AI對大部分專家經驗的替換，以AI為主專家經驗為輔，極致發揮AI能力。

以下是分析決策部分整體的技術設計（我們參考了華為一篇文章：《網路雲根因智薦的探索與實踐》）：

圖15 分析決策的技術設計

在決策分析層，我們主要採取了專家經驗和AI兩者方式，接下來會介紹專家經驗（基於規則的方式）和AI方式（基於AI演算法的方式）的相關實現。

3。4。1 基於規則的方式

專家經驗部分，我們採取了GRAI（Goal、Result、Analysis和Insight的簡稱）的覆盤方法論來指導工作，透過持續、大量、高頻的覆盤，我們提煉了一些靠譜的規則，並透過持續的迭代，不斷提升準確率和召回率。下面例舉的是主從延遲的規則提煉過程：

圖16 專家經驗的覆盤和改進

3。4。2 基於AI演算法的方式

異常資料庫指標檢測

資料庫核心指標的異常檢測依賴於對指標歷史資料的合理建模，透過將離線過程的定期建模與實時過程的流檢測相結合，將有助於在資料庫例項存在故障或風險的情況下，有效地定位根本問題所在，從而實現及時有效地解決問題。

建模過程主要分為3個流程。首先，我們透過一些前置的模組對指標的歷史資料進行預處理，包含缺失數值填充，資料的平滑與聚合等過程。隨後，我們透過分類模組建立了後續的不同分支，針對不同型別的指標運用不同的手段來建模。最終，將模型進行序列化儲存後提供Flink任務讀取實現流檢測。

以下是檢測的設計圖

圖17 基於AI的異常檢測設計

根因診斷（構建中）

訂閱告警訊息（基於規則或者異常檢測觸發），觸發診斷流程，採集、分析資料，推斷出根因並篩選出有效資訊輔助使用者解決。診斷結果透過大象通知使用者，並提供診斷診斷詳情頁面，使用者可透過標註來最佳化診斷準確性。

圖18 基於AI的異常檢測設計

資料採集

：採集資料庫效能指標、資料庫狀態抓取、系統指標、硬體問題、日誌、記錄等資料。

特徵提取

：從各類資料中提取特徵，包括演算法提取的時序特徵、文字特徵以及利用資料庫知識提取的領域特徵等。

根因分類

：包括特徵預處理、特徵篩選、演算法分類、根因排序等部分。

根因擴充套件

：基於根因類別進行相關資訊的深入挖掘，提高使用者處理問題的效率。具體包括SQL行為分析、專家規則、指標關聯、維度下鑽、日誌分析等功能模組。

4 建設成果

4。1 指標表現

我們目前主要是透過“梳理觸發告警場景->模擬復現場景->根因分析和診斷->改進計劃->驗收改進質量->梳理觸發告警場景”的閉環方法（詳情請參考前文

建立科學的評估體系，持續的跟蹤產品質量

部分），持續不斷的進行最佳化和迭代。透過可控輸入指標的提升，來最佳化改善線上的輸出指標，從而保證系統不斷的朝著正確的方向發展。以下是近期根因召回率和準確率指標表現情況。

使用者告警根因反饋準確率

圖19 使用者反饋準確率

告警診斷分析總體召回率

圖20 根因分析召回率

4。2 使用者案例

在根因結果推送上，我們和美團內部的IM系統（大象）進行了打通，出現問題後透過告警發現異常->大象推送診斷根因->點選診斷連結詳情檢視詳細資訊->一鍵預案處理->跟蹤反饋處理的效果->執行成功或者回滾，來完成異常的發現、定位、確認和處理的閉環。以下是活躍會話規則觸發告警後根因分析的一個案例。

自動拉群，並給出根因

圖21 鎖阻塞導致活躍會話過高

點選診斷報告，檢視詳情

圖22 鎖阻塞導致活躍會話過高

以下是出現Load告警後，我們的一個慢查詢最佳化建議推送案例（脫敏原因，採用了測試環境模擬的案例）。

圖23 慢查詢最佳化建議

5 總結與未來展望

資料庫自治服務經過2年左右的發展，已基本夯實了基礎能力，在部分業務場景上完成了初步賦能（比如針對問題SQL，業務服務上線釋出前自動識別，提示潛在風險；針對索引誤變更，工單執行前自動檢測索引近期訪問流量，阻斷誤變更等）。接下來，我們的目標除了在已完成工作上繼續深耕，提升能力外，重點會瞄準資料庫自治能力。主要的工作規劃將圍繞以下3個方向：

（1）計算儲存能力增強

：隨著資料庫例項和業務流量的持續高速增長，以及採集的資訊的不斷豐富，亟需對現有資料通道能力進行增強，確保能支撐未來3-5年的處理能力。

（2）自治能力在少部分場景上落地

：資料庫自治能力上，會採取三步走的策略：

第一步：建立根因診斷和SOP文件的關聯，將診斷和處理透明化；

第二步：SOP文件平臺化，將診斷和處理流程化；

第三步：部分低風險無人干預，將診斷和處理自動化，逐步實現資料庫自治。

（3）更靈活的異常回溯系統

：某個場景根因定位演算法在上線前或者改進後的驗證非常關鍵，我們會完善驗證體系，建立靈活的異常回溯系統，透過基於現場資訊的回放來不斷最佳化和提升系統定位準確率。

6 作者及團隊

金龍，來自美團基礎技術部/資料庫研發中心/資料庫平臺研發組。

美團基礎技術部-資料庫技術中心誠招高階、資深技術專家，Base上海、北京。美團關係資料庫規模大，每年快速的增長，每天承載數千億的訪問流量。在這裡可以體驗高併發，高可用，高可擴充套件性的業務挑戰，可以緊跟並開拓業界前沿技術，體會到技術進步帶來的生產力提升。歡迎有興趣的同學投送簡歷至：edp。itu。zhaopin@meituan。com。

| 本文系美團技術團隊出品，著作權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容，敬請註明“內容轉載自美團技術團隊”。本文未經許可，不得進行商業性轉載或者使用。任何商用行為，請傳送郵件至tech@meituan。com申請授權。