說明：
作者：王琦
來源：美團技術團隊
最新互聯網大廠面試真題、Java程序員面試策略（面試前的準備、面試中的技巧）請訪問GitHub
我們生活中隨處可見各種巡檢系統，比如電力巡檢、消防檢查等，正是這些巡檢工作，我們才能在穩定的環境下進行工作、生活。巡檢對於數據庫或者其他 IT 系統來說也同樣至關重要，特別是在降低風險、提高服務穩定性方面起到了非常關鍵作用。
一、背景
爲了保障數據庫的穩定運行，以下核心功能組件必不可少：
其中，數據庫巡檢作爲運維保障體系最重要的環節之一，能夠幫助我們發現數據庫存在的隱患，提前治理，做到防患於未然。對於大規模集羣而言，靈活健壯的自動化巡檢能力，至關重要。
任何系統都會經歷一個原始的階段，最早的巡檢是由中控機 + 定時巡檢腳本 + 前端展示構成的。但是，隨着時間的推移，老巡檢方案逐漸暴露出了一些問題：
- 巡檢定時任務執行依賴中控機，存在單點問題；
- 巡檢結果分散在不同的庫表，無法進行統計；
- 巡檢腳本沒有統一開發標準，不能保證執行的成功率；
- 每個巡檢項都需要單獨寫接口取數據，並修改前端用於巡檢結果展示，比較繁瑣；
- 巡檢發現的隱患需要 DBA 主動打開前端查看，再進行處理，影響整體隱患的治理速度；
- ……
所以我們需要一個靈活、穩定的巡檢系統來幫助我們解決這些痛點，保障數據庫的穩定。
二、設計原則
巡檢系統的設計原則，我們從以下三個方面進行考慮：
- 穩定 ：巡檢作爲保證數據庫穩定的工具，它自身的穩定性也必須有所保證；
- 高效 ：以用戶爲中心，儘量化繁爲簡，降低用戶的使用成本，讓新同學也能迅速上手治理和管理隱患；提高新巡檢部署效率，隨着架構、版本、基礎模塊等運維環境不斷變化，新的巡檢需求層出不窮，更快的部署等於更早的保障；
- 可運營 ：用數據做基礎，對巡檢隱患進行運營，包括推進隱患治理，查看治理效率、趨勢、薄弱點等。
三、系統架構
美團 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，以靜態報告形式展示業務線數據庫運行情況以及存在的問題，巡檢隱患是報告內容之一。
四、巡檢項目
巡檢項目根據負責方分爲 DBA 和 RD，DBA 主要負責處理數據庫基礎功能組件以及影響服務穩定性的隱患。RD 主要負責庫表設計缺陷、數據庫使用不規範等引起的業務故障或性能問題的隱患。也存在需要他們同時參與治理的巡檢項，比如“磁盤可用空間預測”等。目前巡檢項目共 64 個，類目分佈情況如下圖所示：
- 集羣 ：主要檢查集羣拓撲、核心參數等集羣層面的隱患；
- 機器 ：主要檢查服務器硬件層面的隱患；
- Schema/SQL ：檢查表結構設計、數據庫使用、SQL 質量等方面的隱患；
- 高可用 / 備份 / 中間件 / 報警 ：主要檢查相關核心功能組件是否存在隱患。
下面，我們通過列舉幾個巡檢任務來對巡檢項做簡單的說明：
五、成果
美團 MySQL 巡檢系統已穩定運行近一年時間，基於新巡檢體系上線的巡檢項 49 個。通過巡檢體系持續運行，在團隊的共同努力下，我們共治理了 8000+ 核心隱患，近 3 個月隱患治理週期平均不超過 4 天，將隱患總數持續保持在極小的量級，有效地保障了數據庫的穩定。
下面的隱患趨勢圖，展示了近一年中隱患的個數，數量突然增長是由於新的巡檢項上線。從整體趨勢上看，隱患存量有非常明顯的下降。
除了推動內部隱患治理之外，我們還通過對接先知平臺，積極推動 RD 治理隱患數量超過 5000 個。
爲了提升用戶體驗，我們在提升準確率方面也做了重點的投入，讓每一個巡檢在上線前都會經過嚴格的測試和校驗。
對比其他先知接入方，DBA 上報隱患在總量、轉化率、反饋率幾個指標上都處於較高水平，可見我們上報的隱患風險也得到了 RD 的認可。
指標說明：
- 反饋率 = 截止到當前時刻反饋過的風險事件數量 / 截止到當前時刻產生的風險事件總量 * 100%；
- 反饋準確率 = 截止到當前時刻反饋準確的風險事件數量 / 截止到當前時刻反饋過的風險事件總量 * 100%；
- 轉化率 = 截止到當前時刻用戶反饋準確且需要處理的風險事件數量 / 截止到當前時刻產生的風險事件總量 * 100%。
六、未來規劃
除了繼續完善補充巡檢項以外，未來巡檢系統還會在以下幾個方向繼續探索迭代：
- 提高自動化能力，完善 CI 和審計；
- 加強運營能力，進一步細化每個隱患的重要程度，輔助決策治理優先級；
- 隱患自動修復。