美團 MySQL 數據庫巡檢系統的設計與應用

說明：
做者：王琦
來源：美團技術團隊
最新互聯網大廠面試真題、Java程序員面試策略（面試前的準備、面試中的技巧）請訪問GitHub

---

咱們生活中隨處可見各類巡檢系統，好比電力巡檢、消防檢查等，正是這些巡檢工做，咱們才能在穩定的環境下進行工做、生活。巡檢對於數據庫或者其餘 IT 系統來講也一樣相當重要，特別是在下降風險、提升服務穩定性方面起到了很是關鍵做用。

1、背景

爲了保障數據庫的穩定運行，如下核心功能組件必不可少：

其中，數據庫巡檢做爲運維保障體系最重要的環節之一，可以幫助咱們發現數據庫存在的隱患，提早治理，作到防患於未然。對於大規模集羣而言，靈活健壯的自動化巡檢能力，相當重要。

任何系統都會經歷一個原始的階段，最先的巡檢是由中控機 + 定時巡檢腳本 + 前端展現構成的。可是，隨着時間的推移，老巡檢方案逐漸暴露出了一些問題：

• 巡檢定時任務執行依賴中控機，存在單點問題；
• 巡檢結果分散在不一樣的庫表，沒法進行統計；
• 巡檢腳本沒有統一開發標準，不能保證執行的成功率；
• 每一個巡檢項都須要單獨寫接口取數據，並修改前端用於巡檢結果展現，比較繁瑣；
• 巡檢發現的隱患須要 DBA 主動打開前端查看，再進行處理，影響總體隱患的治理速度；
• ……

因此咱們須要一個靈活、穩定的巡檢系統來幫助咱們解決這些痛點，保障數據庫的穩定。

2、設計原則

巡檢系統的設計原則，咱們從如下三個方面進行考慮：

• 穩定 ：巡檢做爲保證數據庫穩定的工具，它自身的穩定性也必須有所保證；
• 高效 ：以用戶爲中心，儘可能化繁爲簡，下降用戶的使用成本，讓新同窗也能迅速上手治理和管理隱患；提升新巡檢部署效率，隨着架構、版本、基礎模塊等運維環境不斷變化，新的巡檢需求層出不窮，更快的部署等於更早的保障；
• 可運營 ：用數據作基礎，對巡檢隱患進行運營，包括推動隱患治理，查看治理效率、趨勢、薄弱點等。

3、系統架構

美團 MySQL 數據庫巡檢系統架構圖設計以下所示。接下來，咱們按照架構圖從下到上的順序來對巡檢系統主要模塊進行簡單的介紹。

1. 執行層

• 巡檢執行環境 ：由多臺巡檢執行機組成，巡檢任務腳本會同時部署在全部執行機上。執行機會定時從巡檢 Git 倉庫拉取最新的腳本，腳本使用 Python Virtualenv + Git 進行管理，方便擴充新的執行機。
• 任務調度 ：巡檢任務使用了美團基礎架構部研發的分佈式定時任務系統 Crane 進行調度，解決傳統定時任務單點問題。Crane 會隨機指派某一臺執行機執行任務，假如這臺執行機出現故障，會指派其餘執行機從新執行任務。通常一個巡檢任務對應着一個巡檢項，巡檢任務會針對特定的巡檢目標根據必定的規則來判斷是否存在隱患。
• 巡檢目標 ：除了對生產數據庫進行巡檢之外，還會對高可用組件、中間件等數據庫周邊產品進行巡檢，儘量覆蓋全部會引起數據庫故障的風險點。

2. 存儲層

巡檢數據庫 ：主要用來保存巡檢相關數據。爲了規範和簡化流程，咱們將巡檢發現的隱患保存到數據庫中，提供了通用的入庫函數，可以實現如下功能：

• 自動補齊隱患負責人、隱患發現時間等信息；
• 入庫操做冪等；
• 支持半結構化的巡檢結果入庫，不一樣巡檢的隱患結果包括不一樣的屬性，好比巡檢 A 的隱患有「中間件類型」，巡檢 B 有「主庫 CPU 核數」，以上不一樣結構的數據都可解析入庫；
• 針對表粒度的隱患項，若是分庫分表的表出現隱患，會自動合併成一個邏輯表隱患入庫。

巡檢腳本 Git 倉庫 ：用來管理巡檢腳本。爲了方便 DBA 添加巡檢，在系統建設過程當中，咱們增長了多個公共函數，用來下降開發新巡檢的成本，也方便將老的巡檢腳本遷移到新的體系中。

3. 應用層

集成到數據庫運維平臺 ：做爲隱患明細展現、配置巡檢展現、管理白名單等功能的入口。爲了提升隱患治理效率。咱們作了如下設計。

• 隱患明細展現頁面會標註每一個隱患出現的天數，便於追蹤隱患出現緣由。
• 配置新的巡檢展現時必需要同時制定隱患解決方案，確保隱患治理有章可循，避免錯誤的治理方式致使「錯上加錯」。

隱患運營後臺 ：這個模塊主要目的是推動隱患的治理。

• 運營報表，幫助管理者從全局角度掌握隱患治理進展，報表包括隱患趨勢、存量分佈、增量分佈、平均治理週期等核心內容，進而由上到下推進隱患治理；報表數據一樣是經過 Crane 定時任務計算得到。
  = 隱患治理催辦功能，用來督促 DBA 處理隱患。催辦內容中會帶有隱患具體內容、出現時長、處理方案等。催辦形式包括大象消息、告警，具體選用哪一種形式可根據巡檢關鍵程度作相應配置。

外部數據服務 ：主要是將巡檢隱患數據提供給美團內部其餘平臺或項目使用，讓巡檢數據發揮更大的價值。

• 對接先知平臺，美團 SRE 團隊開發的主要面向研發人員（下稱 RD）用戶的風險發現和運營平臺，平臺接收各服務方上報的隱患數據，以 RD 視角從組織架構維度展現各服務的風險點，並跟進 RD 處理進度。巡檢系統會把須要 RD 參與治理的隱患，好比大表、無惟一鍵表等，藉助先知平臺統一推送給 RD 進行治理。
• 運維週報，主要面向業務線 RD 負責人和業務線 DBA，以靜態報告形式展現業務線數據庫運行狀況以及存在的問題，巡檢隱患是報告內容之一。

4、巡檢項目

巡檢項目根據負責方分爲 DBA 和 RD，DBA 主要負責處理數據庫基礎功能組件以及影響服務穩定性的隱患。RD 主要負責庫表設計缺陷、數據庫使用不規範等引發的業務故障或性能問題的隱患。也存在須要他們同時參與治理的巡檢項，好比「磁盤可用空間預測」等。目前巡檢項目共 64 個，類目分佈狀況以下圖所示：

• 集羣 ：主要檢查集羣拓撲、核心參數等集羣層面的隱患；
• 機器 ：主要檢查服務器硬件層面的隱患；
• Schema/SQL ：檢查表結構設計、數據庫使用、SQL 質量等方面的隱患；
• 高可用 / 備份 / 中間件 / 報警 ：主要檢查相關核心功能組件是否存在隱患。

下面，咱們經過列舉幾個巡檢任務來對巡檢項作簡單的說明：

5、成果

美團 MySQL 巡檢系統已穩定運行近一年時間，基於新巡檢體系上線的巡檢項 49 個。經過巡檢體系持續運行，在團隊的共同努力下，咱們共治理了 8000+ 核心隱患，近 3 個月隱患治理週期平均不超過 4 天，將隱患總數持續保持在極小的量級，有效地保障了數據庫的穩定。

下面的隱患趨勢圖，展現了近一年中隱患的個數，數量忽然增加是因爲新的巡檢項上線。從總體趨勢上看，隱患存量有很是明顯的降低。

除了推進內部隱患治理以外，咱們還經過對接先知平臺，積極推進 RD 治理隱患數量超過 5000 個。

爲了提高用戶體驗，咱們在提高準確率方面也作了重點的投入，讓每個巡檢在上線前都會通過嚴格的測試和校驗。

對比其餘先知接入方，DBA 上報隱患在總量、轉化率、反饋率幾個指標上都處於較高水平，可見咱們上報的隱患風險也獲得了 RD 的承認。

指標說明：

• 反饋率 = 截止到當前時刻反饋過的風險事件數量 / 截止到當前時刻產生的風險事件總量 * 100%；
• 反饋準確率 = 截止到當前時刻反饋準確的風險事件數量 / 截止到當前時刻反饋過的風險事件總量 * 100%；
• 轉化率 = 截止到當前時刻用戶反饋準確且須要處理的風險事件數量 / 截止到當前時刻產生的風險事件總量 * 100%。

6、將來規劃

除了繼續完善補充巡檢項之外，將來巡檢系統還會在如下幾個方向繼續探索迭代：

• 提升自動化能力，完善 CI 和審計；
• 增強運營能力，進一步細化每一個隱患的重要程度，輔助決策治理優先級；
• 隱患自動修復。