作者 |金龍

DAS（Database Autonomy Service, 數(shù)據(jù)庫自治服務(wù)）面向研發(fā)和DBA，是一款為用戶提供數(shù)據(jù)庫性能分析、故障診斷、安全管理等功能的數(shù)據(jù)庫自治服務(wù)。DAS利用大數(shù)據(jù)手段、機(jī)器學(xué)習(xí)、專家經(jīng)驗，幫助用戶消除數(shù)據(jù)庫管理的復(fù)雜性及人工操作引發(fā)的服務(wù)故障，有效保障數(shù)據(jù)庫服務(wù)的穩(wěn)定和高效運行。本文主要講述DAS的歷史背景、演進(jìn)策略、重要功能及實現(xiàn)思路，希望能對從事相關(guān)開發(fā)的同學(xué)有所幫助或者啟發(fā)。

1 現(xiàn)狀與問題

1.1 規(guī)模增長與運維能力發(fā)展之間的不平衡問題凸顯

伴隨著最近幾年美團(tuán)業(yè)務(wù)的快速發(fā)展，數(shù)據(jù)庫的規(guī)模也保持著高速增長。而作為整個業(yè)務(wù)系統(tǒng)的“神經(jīng)末梢”，數(shù)據(jù)庫一旦出現(xiàn)問題，對業(yè)務(wù)造成的損失就會非常大。同時，因數(shù)據(jù)庫規(guī)模的快速增長，出現(xiàn)問題的數(shù)量也大大增加，完全依靠人力的被動分析與定位已經(jīng)不堪重負(fù)。下圖是當(dāng)時數(shù)據(jù)庫實例近年來的增長趨勢：

圖1 數(shù)據(jù)庫實例增長趨勢

1.2 理想很豐滿，現(xiàn)實很骨感

美團(tuán)數(shù)據(jù)庫團(tuán)隊當(dāng)前面臨的主要矛盾是：實例規(guī)模增長與運維能力發(fā)展之間的不平衡，而主要矛盾體現(xiàn)在數(shù)據(jù)庫穩(wěn)定性要求較高與關(guān)鍵數(shù)據(jù)缺失。由于產(chǎn)品能力不足，只能依賴專業(yè)DBA手動排查問題，異常處理時間較長。

因此，我們決定補(bǔ)齊關(guān)鍵信息，提供自助或自動定位問題的能力，縮短處理時長。我們復(fù)盤了過去一段時間內(nèi)的故障和告警，深入分析了這些問題的根因，發(fā)現(xiàn)任何一個異常其實都可以按時間拆分為異常預(yù)防、異常處理和異常復(fù)盤三階段。

針對這三階段，結(jié)合MTTR的定義，然后調(diào)研了美團(tuán)內(nèi)部及業(yè)界的解決方案，我們做了一張涵蓋數(shù)據(jù)庫異常處理方案的全景圖。如下圖所示：

圖2 運維能力的現(xiàn)狀

通過對比，我們發(fā)現(xiàn)：

• 每個環(huán)節(jié)我們都有相關(guān)的工具支撐，但能力又不夠強(qiáng)，相比頭部云廠商大概20%～30%左右的能力，短板比較明顯。
• 自助化和自動化能力也不足，工具雖多，但整個鏈條沒有打通，未形成合力。

那如何解決這一問題呢？團(tuán)隊成員經(jīng)過深入分析和討論后，我們提出了一種比較符合當(dāng)前發(fā)展階段的解決思路。

2 解決的思路

2.1 既解決短期矛盾，也立足長遠(yuǎn)發(fā)展

從對歷史故障的復(fù)盤來看，80%故障中80%的時間都花在分析和定位上。解決異常分析和定位效率短期的ROI（投資回報率）最高。長期來看，只有完善能力版圖，才能持續(xù)不斷地提升整個數(shù)據(jù)庫的穩(wěn)定性及保障能力。

因此，我們當(dāng)時的一個想法就是既要解決短期矛盾，又要立足長遠(yuǎn)發(fā)展（Think Big Picture, Think Long Term）。新的方案要為未來留足足夠的發(fā)展空間，不能只是“頭痛醫(yī)頭、腳痛醫(yī)腳”。在宏觀層面，我們希望能將更多的功能做到自動定位，基于自動定位來自助或自動地處理變更，從而提高異常恢復(fù)的效率，最終提升用戶體驗。

將異常處理效率提高和用戶體驗提升后，運維人員（主要是DBA）的溝通成本將會極大被降低，這樣運維人員就有更多時間進(jìn)行技術(shù)投入，能將更多“人肉處理”的異常變成自助或自動處理，從而形成“飛輪效應(yīng)”。最終達(dá)成高效的穩(wěn)定性保障的目標(biāo)。在微觀層面，我們基于已有的數(shù)據(jù)，通過結(jié)構(gòu)化的信息輸出，提升可觀測性，補(bǔ)齊關(guān)鍵數(shù)據(jù)缺失的短板。同時，我們基于完善的信息輸出，通過規(guī)則（專家經(jīng)驗）和AI的配合，提供自助或自動定位的能力，縮短處理時長。

圖3 宏觀和微觀

2.2 夯實基礎(chǔ)能力，賦能上層業(yè)務(wù)，實現(xiàn)數(shù)據(jù)庫自治

有了明確的指導(dǎo)思想，我們該采取怎樣的發(fā)展策略和路徑呢？就當(dāng)時團(tuán)隊的人力情況來看，沒有同學(xué)有過類似異常自治的開發(fā)經(jīng)驗，甚至對數(shù)據(jù)庫的異常分析的能力都還不具備，人才結(jié)構(gòu)不能滿足產(chǎn)品的終極目標(biāo)。

所謂“天下大事必作于細(xì)，天下難事必作于易”。我們思路是從小功能和容易的地方入手，先完指標(biāo)監(jiān)控、慢查詢、活躍會話這些簡單的功能，再逐步深入到全量SQL、異常根因分析和慢查詢優(yōu)化建議等這些復(fù)雜的功能，通過這些基礎(chǔ)工作來“借假修真”，不斷提升團(tuán)隊攻堅克難的能力，同時也可以為智能化打下一個良好的基礎(chǔ)。

以下便是我們根據(jù)當(dāng)時人才結(jié)構(gòu)以及未來目標(biāo)設(shè)定的2年路徑規(guī)劃（實現(xiàn)數(shù)據(jù)自治目標(biāo)規(guī)劃在2022以后的啟動，下圖會省略掉這部分）：

圖4 演進(jìn)策略

2.3 建立科學(xué)的評估體系，持續(xù)的跟蹤產(chǎn)品質(zhì)量

美國著名管理學(xué)者卡普蘭說過：“沒有度量就沒有管理”。只有建立科學(xué)的評估體系，才能推進(jìn)產(chǎn)品不斷邁向更高峰，怎樣評估產(chǎn)品的質(zhì)量并持續(xù)改善呢？之前我們也做過很多指標(biāo)，但都不可控，沒有辦法指導(dǎo)我們的工作。

比如，我們最開始考慮根因定位使用的是結(jié)果指標(biāo)準(zhǔn)確率和召回率，但結(jié)果指標(biāo)不可控難以指導(dǎo)我們的日常工作。這就需要找其中的可控因素，并不斷改善。我們在學(xué)習(xí)亞馬遜的時候，剛好發(fā)現(xiàn)他們有一個可控輸入和輸出指標(biāo)的方法論，就很好地指導(dǎo)了我們的工作。只要在正確的可控輸入指標(biāo)上不斷優(yōu)化和提升，最終我們的輸出指標(biāo)也能夠得到提升（這也印證了曾國藩曾說過的一句話：“在因上致力，但在果上隨緣”）。

以下是我們關(guān)于根因定位的指標(biāo)設(shè)計和技術(shù)實現(xiàn)思路（在模擬環(huán)境不斷提升可控的部分，最終線上的實際效果也會得到提升。主要包括“根因定位可控輸入和輸出指標(biāo)設(shè)計思路”和“根因定位可控輸入指標(biāo)獲取的技術(shù)實現(xiàn)思路”）。根因定位可控輸入和輸出指標(biāo)設(shè)計思路

圖5 可控輸入與輸出指標(biāo)設(shè)計

根因定位可控輸入指標(biāo)獲取的技術(shù)實現(xiàn)思路

圖6 可控輸入與輸出指標(biāo)技術(shù)設(shè)計

在圖5中，我們通過場景復(fù)現(xiàn)方式，用技術(shù)手段來模擬一些用低成本就能實現(xiàn)的異常（絕大部份異常）。在對于復(fù)現(xiàn)成本比較高的異常（極少部分），比如機(jī)器異常、硬件故障等，我們目前的思路是通過“人肉運營”的方式，發(fā)現(xiàn)和優(yōu)化問題，等到下次線上異常重復(fù)發(fā)生后，根據(jù)優(yōu)化后診斷的結(jié)果，通過和預(yù)期比較來確定驗收是否通過。

未來我們會建立回溯系統(tǒng)，將發(fā)生問題時刻的異常指標(biāo)保存，通過異常指標(biāo)輸入給回溯系統(tǒng)后的輸出結(jié)果，判斷系統(tǒng)改進(jìn)的有效性，從而構(gòu)建更加輕量和更廣覆蓋的復(fù)現(xiàn)方式。圖6是復(fù)現(xiàn)系統(tǒng)的具體技術(shù)實現(xiàn)思路。

有了指導(dǎo)思想，符合當(dāng)前發(fā)展階段的路徑規(guī)劃以及科學(xué)的評估體系后，接下來聊聊技術(shù)方案的構(gòu)思。

3 技術(shù)方案

3.1 技術(shù)架構(gòu)的頂層設(shè)計

在技術(shù)架構(gòu)頂層設(shè)計上，我們秉承平臺化、自助化、智能化和自動化四步走的演進(jìn)策略。

首先，我們要完善可觀測的能力，通過關(guān)鍵信息的展示，構(gòu)建一個易用的數(shù)據(jù)庫監(jiān)控平臺。然后我們根據(jù)這些關(guān)鍵信息為變更（比如數(shù)據(jù)變更和索引變更等）提供賦能，將一部分高頻運維工作通過這些結(jié)構(gòu)化的關(guān)鍵信息（比如索引變更，可以監(jiān)測近期是否有訪問流量，來確保變更安全性）讓用戶自主決策，也就是自助化。接下來，我們加入一些智能的元素（專家經(jīng)驗+AI），進(jìn)一步覆蓋自助化的場景，并逐步將部分低風(fēng)險的功能自動化，最終通過系統(tǒng)的不斷完善，走到高級或完全自動化的階段。

為什么我們將自動化放在智能化之后？因為我們認(rèn)為智能化的目標(biāo)也是為了自動化，智能化是自動化的前提，自動化是智能化的結(jié)果。只有不斷提升智能化，才能達(dá)到高級或者完全自動化。下圖便是我們的頂層架構(gòu)設(shè)計（左側(cè)是演進(jìn)策略，右側(cè)是技術(shù)架構(gòu)的頂層設(shè)計以及2021年底的現(xiàn)狀）：

圖7 架構(gòu)頂層設(shè)計頂層設(shè)計

只是“萬里長征第一步”，接下來我們將自底向上逐步介紹我們基于頂層設(shè)計開展的具體工作，將從數(shù)據(jù)采集層的設(shè)計、計算存儲層的設(shè)計和分析決策層的設(shè)計逐步展開。

3.2 數(shù)據(jù)采集層的設(shè)計

這上面的架構(gòu)圖里，數(shù)據(jù)采集層是所有鏈路的最底層和最重要的環(huán)節(jié)，采集數(shù)據(jù)的質(zhì)量直接決定了整個系統(tǒng)的能力。同時，它和數(shù)據(jù)庫實例直接打交道，任何設(shè)計上的缺陷都將可能導(dǎo)致大規(guī)模的故障。所以，技術(shù)方案上必須兼顧數(shù)據(jù)采集質(zhì)量和實例穩(wěn)定性，在二者無法平衡的情況下，寧可犧牲掉采集質(zhì)量也要保證數(shù)據(jù)庫的穩(wěn)定性。

在數(shù)據(jù)采集上，業(yè)界都采取基于內(nèi)核的方式，但美團(tuán)自研內(nèi)核較晚，而且部署周期長，所以我們短期的方式是采用抓包的方式做一個過渡，等基于內(nèi)核的采集部署到一定規(guī)模后再逐步切換過來。以下是我們基于抓包思路的技術(shù)方案調(diào)研：

從調(diào)研上我們可以看到，基于pf_ring和dpdk的方案都有較大的依賴性，短期難以實現(xiàn)，之前也沒有經(jīng)驗。但是，基于pcap的方式?jīng)]有依賴，我們也有過一定的經(jīng)驗，之前美團(tuán)酒旅團(tuán)隊基于抓包的方式做過全量SQL數(shù)據(jù)采集的工具，并經(jīng)過了1年時間的驗證。

因此，我們最終采取了基于pcap抓包方式的技術(shù)方案。以下是采集層方案的架構(gòu)圖和采集質(zhì)量以及對數(shù)據(jù)庫性能帶來的影響情況。Agent的技術(shù)設(shè)計

圖8 Agent的技術(shù)設(shè)計

對數(shù)據(jù)庫的影響

圖9 Agent對數(shù)據(jù)庫的影響測試

3.3 計算存儲層的設(shè)計

由于美團(tuán)整個數(shù)據(jù)庫實例數(shù)量和流量巨大，而且隨著業(yè)務(wù)的快速發(fā)展，還呈現(xiàn)出快速增長的態(tài)勢。所以，我們的設(shè)計不僅要滿足當(dāng)前，還要考慮未來5年及更長的時間也能夠滿足要求。同時，對數(shù)據(jù)庫故障分析來說，數(shù)據(jù)的實時性和完備性是快速和高效定位問題的關(guān)鍵，而保證數(shù)據(jù)實時性和完備性需要的容量成本也不容忽視。因此，結(jié)合上述要求和其他方面的一些考慮，我們對該部分設(shè)計提出了一些原則，主要包括：

• 全內(nèi)存計算：確保所有的計算都在單線程內(nèi)或單進(jìn)程內(nèi)做純內(nèi)存的操作，追求性能跟吞吐量的極致。
• 上報原始數(shù)據(jù)：MySQL實例上報的數(shù)據(jù)盡量維持原始數(shù)據(jù)狀態(tài)，不做或者盡量少做數(shù)據(jù)加工。數(shù)據(jù)壓縮：由于上報量巨大，需要保障上報的數(shù)據(jù)進(jìn)行極致的壓縮。
• 內(nèi)存消耗可控：通過理論和實際壓測保障幾乎不可能會發(fā)生內(nèi)存溢出。
• 最小化對MySQL實例的影響：計算盡量后置，不在Agent上做復(fù)雜計算，確保不對RDS實例生產(chǎn)較大影響。以下是具體的架構(gòu)圖：

圖10 Agent對數(shù)據(jù)庫的影響測試

全量SQL（所有訪問數(shù)據(jù)庫的SQL）是整個系統(tǒng)最具挑戰(zhàn)的功能，也是數(shù)據(jù)庫異常分析最重要的信息之一，因此會就全量SQL的聚合方式、聚合和壓縮的效果和補(bǔ)償設(shè)計做一些重點的介紹。

3.3.1 全量SQL的聚合方式

由于明細(xì)數(shù)據(jù)巨大，我們采取了聚合的方式。消費線程會對相同模板SQL的消息按分鐘粒度進(jìn)行聚合計算，以“RDSIP+DBName+SQL模版ID+SQL查詢結(jié)束時間所在分鐘數(shù)”為聚合鍵。聚合健的計算公式為：Aggkey=RDS_IP_DBName_SQL_Template_ID_Time_Minute （Time_Minute的值取自SQL查詢結(jié)束時間所在的“年、月、日、時、分鐘”）

圖11 SQL模版聚合設(shè)計

圖12 SQL模版聚合方法

3.3.2 全量SQL數(shù)據(jù)聚合和壓縮的效果

在數(shù)據(jù)壓縮方面，遵循層層減流原則，使用消息壓縮、預(yù)聚合、字典化、分鐘級聚合的手段，保證流量在經(jīng)過每個組件時進(jìn)行遞減，最終達(dá)到節(jié)省帶寬減少存儲量的目的。以下是相關(guān)的壓縮環(huán)節(jié)和測試數(shù)據(jù)表現(xiàn)情況（敏感數(shù)據(jù)做了脫敏，不代表美團(tuán)實際的情況）：

圖13 全量SQL壓縮設(shè)計與效果

3.3.3 全量SQL數(shù)據(jù)補(bǔ)償機(jī)制

如上所述，在數(shù)據(jù)聚合端是按一分鐘進(jìn)行聚合，并允許額外一分鐘的消息延遲，如果消息延遲超過1分鐘會被直接丟棄掉，這樣在業(yè)務(wù)高峰期延遲比較嚴(yán)重的場景下，會丟失比較大量的數(shù)據(jù)，從而對后續(xù)數(shù)據(jù)庫異常分析的準(zhǔn)確性造成較大的影響。

因此，我們增加了延遲消息補(bǔ)償機(jī)制，對過期的數(shù)據(jù)發(fā)入補(bǔ)償隊列（采用的是美團(tuán)消息隊列服務(wù)Mafka），通過過期數(shù)據(jù)補(bǔ)償?shù)姆绞剑ＷC延遲久的消息也能正常存儲，通過最終一致性保證了后續(xù)的數(shù)據(jù)庫異常分析的準(zhǔn)確性。以下是數(shù)據(jù)補(bǔ)償機(jī)制的設(shè)計方案：

圖14 全量SQL補(bǔ)全技術(shù)設(shè)計

3.4 分析決策層的設(shè)計

在有了比較全的數(shù)據(jù)之后，接下來就是基于數(shù)據(jù)進(jìn)行決策，推斷出可能的根因。這部分我們使用了基于專家經(jīng)驗結(jié)合AI的方式。我們把演進(jìn)路徑化分為了四個階段：

• 第一階段：完全以規(guī)則為主，積累領(lǐng)域經(jīng)驗，探索可行的路徑。
• 第二階段：探索AI場景，但以專家經(jīng)驗為主，在少量低頻場景上使用AI算法，驗證AI能力。
• 第三階段：在專家經(jīng)驗和AI上齊頭并進(jìn)，專家經(jīng)驗繼續(xù)在已有的場景上迭代和延伸，AI在新的場景上進(jìn)行落地，通過雙軌制保證原有能力不退化。
• 第四階段：完成AI對大部分專家經(jīng)驗的替換，以AI為主專家經(jīng)驗為輔，極致發(fā)揮AI能力。

以下是分析決策部分整體的技術(shù)設(shè)計（我們參考了華為一篇文章：《網(wǎng)絡(luò)云根因智薦的探索與實踐》）：

圖15 分析決策的技術(shù)設(shè)計

在決策分析層，我們主要采取了專家經(jīng)驗和AI兩者方式，接下來會介紹專家經(jīng)驗（基于規(guī)則的方式）和AI方式（基于AI算法的方式）的相關(guān)實現(xiàn)。

3.4.1 基于規(guī)則的方式

專家經(jīng)驗部分，我們采取了GRAI（Goal、Result、Analysis和Insight的簡稱）的復(fù)盤方法論來指導(dǎo)工作，通過持續(xù)、大量、高頻的復(fù)盤，我們提煉了一些靠譜的規(guī)則，并通過持續(xù)的迭代，不斷提升準(zhǔn)確率和召回率。下面例舉的是主從延遲的規(guī)則提煉過程：

圖16 專家經(jīng)驗的復(fù)盤和改進(jìn)

3.4.2 基于AI算法的方式

異常數(shù)據(jù)庫指標(biāo)檢測

數(shù)據(jù)庫核心指標(biāo)的異常檢測依賴于對指標(biāo)歷史數(shù)據(jù)的合理建模，通過將離線過程的定期建模與實時過程的流檢測相結(jié)合，將有助于在數(shù)據(jù)庫實例存在故障或風(fēng)險的情況下，有效地定位根本問題所在，從而實現(xiàn)及時有效地解決問題。

建模過程主要分為3個流程。首先，我們通過一些前置的模塊對指標(biāo)的歷史數(shù)據(jù)進(jìn)行預(yù)處理，包含缺失數(shù)值填充，數(shù)據(jù)的平滑與聚合等過程。隨后，我們通過分類模塊創(chuàng)建了后續(xù)的不同分支，針對不同類型的指標(biāo)運用不同的手段來建模。最終，將模型進(jìn)行序列化存儲后提供Flink任務(wù)讀取實現(xiàn)流檢測。以下是檢測的設(shè)計圖

圖17 基于AI的異常檢測設(shè)計

根因診斷（構(gòu)建中）訂閱告警消息（基于規(guī)則或者異常檢測觸發(fā)），觸發(fā)診斷流程，采集、分析數(shù)據(jù)，推斷出根因并篩選出有效信息輔助用戶解決。診斷結(jié)果通過大象通知用戶，并提供診斷診斷詳情頁面，用戶可通過標(biāo)注來優(yōu)化診斷準(zhǔn)確性。

圖18 基于AI的異常檢測設(shè)計

• 數(shù)據(jù)采集：采集數(shù)據(jù)庫性能指標(biāo)、數(shù)據(jù)庫狀態(tài)抓取、系統(tǒng)指標(biāo)、硬件問題、日志、記錄等數(shù)據(jù)。
• 特征提取：從各類數(shù)據(jù)中提取特征，包括算法提取的時序特征、文本特征以及利用數(shù)據(jù)庫知識提取的領(lǐng)域特征等。
• 根因分類：包括特征預(yù)處理、特征篩選、算法分類、根因排序等部分。
• 根因擴(kuò)展：基于根因類別進(jìn)行相關(guān)信息的深入挖掘，提高用戶處理問題的效率。具體包括SQL行為分析、專家規(guī)則、指標(biāo)關(guān)聯(lián)、維度下鉆、日志分析等功能模塊。

4 建設(shè)成果

4.1 指標(biāo)表現(xiàn)

我們目前主要是通過“梳理觸發(fā)告警場景->模擬復(fù)現(xiàn)場景->根因分析和診斷->改進(jìn)計劃->驗收改進(jìn)質(zhì)量->梳理觸發(fā)告警場景”的閉環(huán)方法（詳情請參考前文建立科學(xué)的評估體系，持續(xù)的跟蹤產(chǎn)品質(zhì)量部分），持續(xù)不斷的進(jìn)行優(yōu)化和迭代。

通過可控輸入指標(biāo)的提升，來優(yōu)化改善線上的輸出指標(biāo)，從而保證系統(tǒng)不斷的朝著正確的方向發(fā)展。以下是近期根因召回率和準(zhǔn)確率指標(biāo)表現(xiàn)情況。用戶告警根因反饋準(zhǔn)確率

圖19 用戶反饋準(zhǔn)確率

告警診斷分析總體召回率

圖20 根因分析召回率

4.2 用戶案例

在根因結(jié)果推送上，我們和美團(tuán)內(nèi)部的IM系統(tǒng)（大象）進(jìn)行了打通，出現(xiàn)問題后通過告警發(fā)現(xiàn)異常->大象推送診斷根因->點擊診斷鏈接詳情查看詳細(xì)信息->一鍵預(yù)案處理->跟蹤反饋處理的效果->執(zhí)行成功或者回滾，來完成異常的發(fā)現(xiàn)、定位、確認(rèn)和處理的閉環(huán)。以下是活躍會話規(guī)則觸發(fā)告警后根因分析的一個案例。自動拉群，并給出根因

圖21 鎖阻塞導(dǎo)致活躍會話過高

點擊診斷報告，查看詳情

圖22 鎖阻塞導(dǎo)致活躍會話過高

以下是出現(xiàn)Load告警后，我們的一個慢查詢優(yōu)化建議推送案例（脫敏原因，采用了測試環(huán)境模擬的案例）。

圖23 慢查詢優(yōu)化建議

5 總結(jié)與未來展望

數(shù)據(jù)庫自治服務(wù)經(jīng)過2年左右的發(fā)展，已基本夯實了基礎(chǔ)能力，在部分業(yè)務(wù)場景上完成了初步賦能（比如針對問題SQL，業(yè)務(wù)服務(wù)上線發(fā)布前自動識別，提示潛在風(fēng)險；針對索引誤變更，工單執(zhí)行前自動檢測索引近期訪問流量，阻斷誤變更等）。接下來，我們的目標(biāo)除了在已完成工作上繼續(xù)深耕，提升能力外，重點會瞄準(zhǔn)數(shù)據(jù)庫自治能力。主要的工作規(guī)劃將圍繞以下3個方向：

（1）計算存儲能力增強(qiáng)：隨著數(shù)據(jù)庫實例和業(yè)務(wù)流量的持續(xù)高速增長，以及采集的信息的不斷豐富，亟需對現(xiàn)有數(shù)據(jù)通道能力進(jìn)行增強(qiáng)，確保能支撐未來3-5年的處理能力。

（2）自治能力在少部分場景上落地：數(shù)據(jù)庫自治能力上，會采取三步走的策略：

• 第一步：建立根因診斷和SOP文檔的關(guān)聯(lián)，將診斷和處理透明化；
• 第二步：SOP文檔平臺化，將診斷和處理流程化；
• 第三步：部分低風(fēng)險無人干預(yù)，將診斷和處理自動化，逐步實現(xiàn)數(shù)據(jù)庫自治。

（3）更靈活的異常回溯系統(tǒng)：某個場景根因定位算法在上線前或者改進(jìn)后的驗證非常關(guān)鍵，我們會完善驗證體系，建立靈活的異常回溯系統(tǒng)，通過基于現(xiàn)場信息的回放來不斷優(yōu)化和提升系統(tǒng)定位準(zhǔn)確率。

6 本文作者

金龍，來自美團(tuán)基礎(chǔ)技術(shù)部/數(shù)據(jù)庫研發(fā)中心/數(shù)據(jù)庫平臺研發(fā)組。