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