58雲DB平台自動化運維建設實踐

簡介

58雲DB平台是由58集團總部DBA團隊打造的雲資料庫平台，為集團各業務線提供高可靠、高性能的MySQL、Redis和MongoDB雲服務，助力與賦能業務發展，提高效率。

通過雲DB平台，在用戶端開發人員不僅可以基於工單進行資料庫資源申請和變更操作，還可以通過自助管理功能實現資料庫自助運營,如實時監控資料庫狀態和集群訪問趨勢、自助查詢數據、慢SQL統計與追蹤等，充分滿足了開發人員對資料庫基本性能查詢、常見問題診斷的需求，提升工作效率；在管理端，DBA可以一鍵自動化完成絕大部分日常重複、複雜的運維工作，極大提高需求的交付效率，保障資料庫的穩定、高效運行。

誕生背景

58集團業務這幾年發展迅猛，隨著先後合併趕集網、安居客、中華英才網、駕校一點通等眾多業務，各對應的資料庫運維工作陸續併入集團DBA團隊統一負責管理，隨之也給DBA團隊帶來了很大的挑戰，主要體現在：

各家子公司資料庫運維標準規範不一致，管理複雜；

資料庫日常工單眾多，提交方式多樣化且人工處理，效率低下；

伺服器和資料庫數量眾多，無管理平台，EXCEL手工維護。

面臨越來越多的資料庫需求，急需要一個資料庫自動化運維平台來釋放DBA的人力，58雲DB平台也就是在這種情況下誕生。在雲DB平台的建設過程中，初期核心為自動化，後期開始考慮智能化運維，本文將會重點介紹這兩面的實踐及遇到的一些問題。

整體架構

上面是我們平台的整體架構，主要分為Web服務、介面代理服務、自動化服務、機器學習服務等。各服務的功能如下：

Web服務：由nginx和Web應用，提供基本的HTTP服務。其中前端用React編寫，由webpack2打包後發布到nginx伺服器上。後端介面由python開發，放在Web應用伺服器中。為了數據的安全性，Web應用只能對用戶的資料庫作讀取操作，所有的變更操作都交由自動化服務處理。

下載服務：主要為用戶從DB中數據導出和binlog提取等提供下載服務。

介面代理服務：平台與其他公共服務的交互都是盡量走Restful協議，對於一些不支持的介面，我們搭建了代理服務，將其轉為Restful協議。

自動化服務：自動化服務是雲DB平台的核心服務，主要將DBA日常運維操作拆解組合成一系列的自動化任務，為了保證這些運維任務能安全執行，我們將一部分MySQL日常工單需求交由Inception來處理，這樣既能最大限度的降低運維操作對線上環境的影響，又兼具數據備份功能，為以後數據恢復的需求提供便利。

機器學習服務：為了提高運維效率、降低運維成本，我們在自動化的基礎上，對智能化運維進行了探索，孵化出了像伺服器的智能優選功能和告警智能合併功能，極大的提高了運維體驗。

運維自動化

隨著公司業務的發展，運維團隊的自動化進程是必然要經歷的階段。提高運維效率，降低運維成本，排除人工操作帶來的不穩定性等，是自動化與生俱來的優勢；但我們在實現的過程中遇到下面幾個問題：

第一個問題，涉及面廣：資料庫的運維操作不僅是對資料庫本身做一些操作，還要在伺服器層面上做一些配置，此外還要對接其他系統，如監控、虛擬IP、高可用等，基本涉及到各個層面上的操作。

第二個問題，操作多樣：對資料庫的運維操作有很多，而且彼此差異很大。比如說：資料庫初始化，操作步驟多，執行時間長；MySQL改表，操作步驟相對簡單，但執行時間有時很短，有時非常長；MySQL建表，操作步驟簡單，執行時間很短。如何平衡銜接好這些自動化的執行，還要保證高速路不塞車，這就是一個需要考究的問題。

第三個問題，日誌顯示：要想實時顯示出日誌，就要實時捕獲日誌，而且還要實時顯示在Web頁面上，就需要一套消息推送機制，保證整個流程最後一環的用戶體驗。

上面就是平台上自動化需要解決的問題，我們原先是想用Ansible來處理，相中它主要是因為其輕量的特點，因為資料庫對性能要求很高，我們不想再部署agent來佔用系統寶貴資源，同時部署agent本身也是成本較高的事情。但經過研究發現Ansible並不能完全滿足我們對自動化操作的要求，它對伺服器層面的操作很擅長，但其他的操作可能就需要自己寫腳本或插件來實現，而且還要獲取它的日誌輸出給Web服務，這勢必要在其外面再加一層，於是我們選了Celery，就行成了平台自動化的基本架構:

上面就是我們對整個自動化架構的設想，整個架構以Celery作為整個自動化的核心任務調度系統，Ansbile最後成為其中的一個子任務類型。完整的自動化處理流程如下：

任務下發

平台發出一個自動化任務到Celery的管理服務(CeleryMain)中，這部分是用Flower作了Celery的服務封裝。

Celery Main會生成一個任務，並將此任務放到對應的Redis任務隊列中，同時返回給平台對應的任務號，平台拿這個任務號跳轉到任務顯示頁面。

任務顯示頁面會啟動Websocket與平台的Web服務建立一個長連接，等待服務返回任務日誌進行展示。

主任務分解

Celery Worker與Redis上自己對應的任務隊列建立一個消息管道，當有任務進入隊列後，就會立即接收並開始執行對應的任務。這時運行的任務，我們稱之為主任務。

主任務不做具體的自動化操作，它的工作是根據程序編排好的邏輯對任務進行分解，然後將分解的子任務串成任務鏈。

子任務會一個接一個的串列執行，如果其中任何一個執行失敗，則整個任務鏈中斷執行，整個任務失敗。

運行子任務

子任務和主任務一樣也是通過Redis的消息隊列傳遞給CeleryWorker。但子任務是執行具體自動化操作的。其中分為三類：

Ansible類子任務——這類子任務是通過執行Ansible的Playbook來對伺服器進行配置操作；

DB類子任務——這類子任務是通過Python中對應資料庫的連接驅動庫，直接連上資料庫執行資料庫操作；

Http類子任務——這類子任務是通過Python的Http庫，調用第三方業務系統的http介面，來做相關業務操作。

子任務執行結束後，會將執行日誌傳遞給平台Web服務。

日誌顯示

平台Web服務在接收到自動化任務執行日誌後，會以時間軸的方式展示出來。輸出日誌的粒度是子任務，也就是子任務執行完後，才會顯示出來，可能有的子任務執行時間比較長，等待的時間可能會久一些。

嚴格來講這隻能算是准實時，要想做到真實時日誌顯示，成本會高很多，目前這種准實時方案，目前是可以滿足需求的。

智能化探索

伺服器智能優選

伺服器智能優選針對的是資料庫集群初始化場景，上線自動化部署後，集群初始化的運維操作被大大簡化，但在自動化執行前需要DBA提供部署的伺服器列表，而目前伺服器數量多達上千台，所以人工來篩選伺服器成為了一個高成本的操作，最後只能做局部最優解。

針對此問題，我們並沒有使用通過業務類型的劃分來做為選擇伺服器的標準，因為58的伺服器是混部部署。我們採取的策略是讓DBA教AI來選伺服器，也就是機器學習中的監督學習。由於沒有數據方面的積累，我們採用在線學習，通過在平台中埋點，實時生成訓練數據進行訓練，不過這需要一定時間的積累，剛開始的效果不是很理想。但在上線跑了大概一個多月，訓練了不到一千套集群的數據後，已經可以輔助DBA來選擇全局最優的伺服器了。

上圖中推薦度部分就是機器學習給出的參考值，從圖上中可以看到給出的分值對Redis的實例數和內存這兩個指標有了很好的權衡，符合我們之前的預期。

告警智能合併

告警是每個運維人員工作過程中很重要的一部分，針對告警我們做了一些優化工作，其中最主要就是告警的智能合併功能。合併後的告警內容僅更加清晰，關聯性更強，而且對於簡訊風暴也能起到一定的預防作用。

上面就是告警內容在改進前後的對比，其中告警合併的核心演算法是用無監督學習演算法中的層次聚類實現的。層次聚類演算法能夠給出數據在每個維度上的相似度。那麼核心問題是如何從一堆相似度中進行分組呢？我們的演算法是，如果兩個向量相似，向量的夾角和距離都應該較小，那就將小於其平均值的劃為一組。

還有一個問題是，一個數據可能隸屬於多個維度中的不同分組，那這樣的數據該如何分組？我們的原則是最大分組原則，優先將在多個維度下有相同的數據劃分為一組，然後再對剩下的數據按此原則進行分組，直到數據都被劃分了分組為止。

最後就可以根據分組的相似維度選取對應的告警內容模板，渲染出告警內容。

總結

本文只是58雲DB平台在自動化、智能化運維建設過程的一些小總結，實際上58雲DB平台已經整合實現了MySQL、Redis以及MongoDB資料庫運維管理的多個功能模塊，比如高可用管理、監控系統、備份系統、一鍵運維管理等各個子系統。目前我們平台的各個功能仍然在快速迭代中，在未來將會探索更多的用戶自助管理和智能化運維功能，歡迎感興趣的同學和我們一起交流。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！