資料庫運維新思路：解讀甜橙金融自動化運維平臺亮點
樑寶利， 甜橙金融資料庫高階研發工程師，多年資料庫運維研發經驗，目前主要負責甜橙金融資料庫自動化運維設計與開發工作。
隨著 甜橙金融 業務的不斷增長，技術架構不斷更新迭代，底層資料庫架構和資料容量也在快速增長，給資料庫運維帶來了很多挑戰。
甜橙金融的 資料庫團隊在迎接挑戰的過程中逐漸形成了獨特的自動化運維體系，下面我們簡單介紹一下自動化運維的心路歷程，同時對自動化過程中碰到的問題給出我們的解決思路，希望能夠互相借鑑。
接下來將從以下幾個方面對公司的自動化運維進行介紹：
-
日常工作——知道DBA是做什麼的；
-
資料庫運維三個歷程——知道自動化運維是做什麼的；
-
MOZIS平臺架構——整個平臺的自動化架構；
-
自動化運維設計例項篇——基本設計思路；
-
未來展望與總結。
一、DBA日常工作
DBA日常工作範圍很廣，遠沒有部分開發同學想象的僅僅是執行工單、搭建資料庫這麼簡單。按照工作內容可分為下圖所示的三大工作體系：
-
業務對接部分，主要是和研發同學直接對接，進行表結構設計、SQL優化、資料訂正以及版本釋出相關的工作；
-
資料庫管理部分，主要保障資料庫的穩定進行，並且保障資料庫的高效能，這需要對資料使用形成規範、定期備份和資料遷移；
-
技術架構部分保證公司的底層架構、技術核心跟上公司的發展以及時代的步伐，不至於一直停止不前。
公司做自動化的目的就是為了能夠實現日常工作的平臺化，把重複的手工來動轉變為自動化的程式執行；把DBA從繁瑣的勞動中解放出來，投身於更有價值的工作。接下來介紹一下我們在自動化過程中經歷的幾個階段。
二、資料庫運維
1、人肉運維
這個階段是公司最初的運維模式，靠人工來解決遇到的所有資料庫問題。當時公司的運維狀態基本上是每個DBA管理三到四套資料庫，涉及到資料庫的所有工作都由相關負責DBA進行操作。每天定時巡檢相應的資料庫，沒有相關的監控系統，資料庫的問題大部分是通過應用的反饋發現的。
當時公司規模較小，且資料庫體量和資料壓力不大，因此這種方式勉強可以維持公司業務的正常運轉。
但隨著公司業務的不斷髮展，資料體量和資料庫壓力顯著增高，這種運維方式給DBA的壓力也越來越大。不斷的增加人手也只是暫時性緩解，並不能從根本上解決問題。因此運維團隊開始慢慢引入各種開源工具，有針對性的解決運維面臨的問題。
2、工具運維
隨著各種開源工具的引入，公司的運維開始轉向工具運維時代。工具運維主要針對工作通過使用一些開源或者購買相關的商業產品來解決某一個特定的問題。並且在此基礎上，DBA也不斷開發自研一些自動化指令碼，輔助自己的日常工作，減輕重複性的勞動。
這個階段公司引入的平臺大體可分為下圖所示的幾類：流程把控、資料庫監控告警、資料庫慢SQL、批量部署和一些自研的自動化指令碼。
工具的使用，解決了日常工作面臨的很多難題。Zabbix的引入解決了資料庫的監控問題，JIRA的引入打通了整個公司從上到下的通道，可以說每一個工具都還加了一個模組的工作，但是工具解決的大部分是如何發現問題，如何解決問題卻很少涉及。而且工具之間的壁壘也使得整個運維體系零零散散。
3、平臺運維
基於工具化的運維思路只是“頭疼醫頭，腳疼醫腳”，雖然緩解了一部分的工作壓力，但是沒有一個體系化的構建。在此基礎上，公司開始了自動化運維平臺的建設。
自動化運維的目標如下圖所示：
把DBA日常工作抽離出來進行平臺化、流程化，並且希望能打破工具間的壁壘，實現從流程到運維的一體化架構。
平臺初期希望承載的業務包括：元資料管理（CMDB）、資料訂正流程、版本釋出流程、服務部署、資料遷移、批量任務執行等操作。這些都是DBA日常最繁重也急切希望能夠解決的問題，只有這些最基本訴求得到實現，才能緩解DBA大部分的工作壓力，並把節省的時間精力投入到更高層次的工作中。
針對上述的平臺設計思路，接下來將會詳細介紹整個平臺架構，並對實現過程中遇到的問題，給出自己的分析。
三、MOZIS平臺整體架構
1、技術結構
平臺後臺採用Python3.6開發，基本的前後端架構如下圖所示：
技術結構的選型主要秉承平臺可擴充套件性強以及快速搭建這兩個特點。接下來簡單介紹一下圖中的各個模組：
-
VUE屬於前端的架構，為了儘量避免耦合，採用前後端分離的方式，沒有采用DJANGO的Jinja2主要是考慮到未來的後端框架的擴充套件性以及伸縮性，後臺和前端的互動只通過標準的RESTful介面進行資料傳輸；
-
後臺採用DJANGO架構，比較成熟，且能夠快速搭建一個後臺網站；
-
Redis作為資訊快取器主要儲存一些前端Dashboard以及資料庫基本的資訊，加快前端訪問速度；
-
ANTLR主要用於SQL語法解析，最終採用ANTLR也是經歷了很多個版本迭代，優勢很明顯，它能夠較為精準的進行SQL語法判斷；
-
CELERY用於非同步任務，由於一些資料庫操作：加表空間、執行大批量SQL等需要時間較長，因此採用非同步任務形式完成資料庫操作；
-
SSH用於連線到遠端資料庫伺服器，不可避免有些操作需要在宿主機進行操作，比如說Oracle的expdp/impdp；
-
Ansible用於一些批量的資料庫推送，批量的資料庫搭建以及批量資料庫配置都需要Ansible進行相關的處理；
-
資料連線，就是一些基本的模組能夠實現不同種類資料庫連線；
-
採用MySQL平臺數據儲存；
-
採用Nginx提供對外服務。
2、功能結構
下圖是MOZIS的整體功能架構圖：
架構中我們對整個資料庫體系劃分了一下基本的層次。從上到下分別是：管理介面、優化分析、基礎能力、CMDB。當然CMDB中又分為3個層次。我們將在接下來的詳細設計中進行相關分析。這麼拆分也是因為每一個層次的能力很大程度上依賴於下層的功能或者資料。
通過上圖可以看到平臺基礎能力包含了基本的資料庫搭建等多個日常維護動作。基本上這些功能能夠保證資料庫的建立以及日常基本維護。接下來將對系統中比較重要的幾個模組設計進行詳細的論述。
四、自動化運維設計
1、元資料管理
自動化運維實現，面臨的第一個挑戰就是元資料管理，一個運維成員最重要的是對自己的資料庫做到心中有數，一個平臺更是如此。下圖是基於資料庫運維的工作提取出的相關運維元資料塊，可以看到資料庫涉及的源資訊來自多個領域：
主機、網路、儲存以及資料庫本身，每個領域的元資料都有其各自的複雜性，且根據公司的情況不同，使用的架構，設計的思路千差萬別，因此從哪個角度設計、如何設計我們基礎元資料成為了自動化運維開發的頭一道難關。
資料庫運維中涉及到的主機網路儲存等模組，既相互獨立又相互關聯，包羅永珍而又層次分明，經歷了無數的坑，我們認為進行資料庫元資料設計應包含以下特性：
-
適配性： 龐大的運維體系以及複雜的運維環境決定元資料結構設計應具備一定的適配性。同時在滿足規範標準的前提下應相容一定的特例。為了實現這一特性，需要對運維體系進行抽象，並在此抽象的基礎 上延伸出 相應的特殊化結構。
-
層次性： 層次 性反映的是整個運維框架從 下到上的分層，是從底層硬體到作業系統到網路再到資料庫這一整套的層次體系。元資料的設計中只需要展現出其資料邏輯，真正的空間邏輯需要我們在業務層進行體現。
-
完整性： 資料庫元資料涉及多個層次、各種型別，缺失任一部分的資料都會掣肘後續的自動化功能。且作為公司整體架構而言，資料庫資訊完整性是保證整個運維平臺正常運轉的基礎。完整性與其說是設計原則，不如說是元資料的基本需求。
基於上述特性和總結，我們對公司運維體系進行服務化抽象，這樣能夠更好地反映各個運維流程的層次化關係，抽象是為了更好的展現資料的層次性與通用性，讓我們在進行元資料設計時更方便。
下圖即是我們抽象出的運維服務化架構：
可以看出，我們的服務從下到上分別為：
-
儲存服務，用於提供儲存資源；
-
主機服務，為上層提供CPU、記憶體、本地路徑等服務；
-
資料服務，為上層提供基本的資料管理查詢處理服務；
-
叢集架構服務，提供資料庫的高可用服務；
-
連線服務，提供資料傳輸、監聽響應的服務；
-
網路服務，提供網路支撐定位主機的作用；
-
域名服務，提供域名與IP的對映關係。
在抽象出相關資料庫服務的基礎上，完成元資料結構基礎設計，就相對簡單了。特殊化的資訊可在這個基礎上進行拓展。
上述的抽象分析是從資料庫運維的角度進行的，實際中對於不同的運維體系如主機運維、網路運維可能會抽象出更多的相關層次。而且從整個運維體系來講還有應用運維的相關服務，最優化的方式其實不是針對每個服務設計一套資料結構，而是直接針對每個服務設計一套微服務架構。每個微服務針對的是不通的運維體系。
不過這種形式的設計將是一個複雜的過程，而且涉及的領域眾多，不可能一蹴而就。但是運維體系的微服務框架必然是未來自動化運維的趨勢。
2、訂正發版流程設計演進
元資料結構的設計，是為資料庫自動化平臺打基礎，接下來針對特定的功能，分析我們在自動化運維建設上的一些思考，這裡拿資料訂正以及版本釋出為例來簡單介紹內部如何不斷的優化與創新最終實現真正的自動化流程。
下圖是公司SQL稽核的第一個版本：
由於公司對發版的資料結構有自己的規範，比如說表名、索引名、註釋等等，因此人工稽核費時費力。
稽核1.0就是為了解決這個問題。我們從JIRA工單上下載需要執行的SQL，然後放到稽核平臺上進行稽核，稽核通過後，再手動的拿到資料庫上進行執行。從原來的肉眼稽核，變成工具稽核；從之前的小時級的稽核時間變成分鐘級的稽核時間，減少人為的失誤，尤其是DDL語句。
稽核1.0面臨的最大缺陷是沒有對接資料庫。主要原因是SQL的正則匹配稽核無法很好把控SQL可能帶來的潛在風險。比如說一條Update語句，無法獲取Update的資料量，也就無法起到風險把控的作用。
在1.0的基礎上，我們對DML稽核做了如下改造：
即通過連線資料庫對DML語句進行EXPLAIN獲取SQL執行計劃，並通過稽核執行計劃完成SQL稽核。這樣一方面可以確保SQL的可執行性，另一方面利用執行計劃的資訊進行風險把控、SQL的影響行數等資訊，雖然通過執行計劃獲取的影響行數不一定最準，但是可以一定程度上反映SQL對資料庫的影響。
稽核2.0出現之後，為我們日常工作節省了大量時間。幾乎所有的資料訂正都走稽核平臺。而且我們還加入了一些統計介面，用來跟進相關應用訂正量大小，並要求其進行整改。
2.0基本上完美解決了DML稽核問題，但是對於DDL依然只存在於正在稽核，雖然不斷迭代使語法規則趨於完善，但由於其複雜性依然沒有對接資料庫，而且稽核現在存在於DBA手中依然避免不了出問題時與開發的溝通。為避免開發與DBA由於SQL規範問題導致的來回溝通，我們重新設計了整個稽核流程，把稽核許可權下放到開發手中，如下圖所示：
新版本的主要流程如下：
由運營或者開發人員提工單，當到達編寫SQL這一步驟時跳轉到MOZIS平臺完成SQL上傳並進行稽核，稽核成功後提交至DBA處理階段。此時平臺會把稽核結果作為記錄插入到當前JIRA工單的註釋中，JIRA正常流轉到DBA手中時，點選執行按鈕可直接執行相關的SQL語句。
流程上的優化減少了溝通，縮短了整個執行過程，節省時間的同時也為之後的一體化發展打下堅實的基礎。
而且為了保證DDL稽核的精準性，放棄了之前的正則稽核。採用ANTLR進行語法語義解析，最大的好處就是其簡潔語法解析結構使得優化開發的速度更快更準。
3、自定義SQL稽核規則
平臺中還有一大亮點就是SQL稽核的可自定義化。以往的設計中，稽核規則直接是寫死在程式中，每次規則的調整，都不可避免的修改程式碼，導致SQL稽核規則的不透明化、平臺的不穩定性，無法滿足迫切的業務需求，因此我們設計如下圖所示的可配置稽核規則模式：
規則值、規則描述、規則等級以及是否啟動都是可以設定的。一方面這種方式使得稽核的通用性更強，另一方面可以使我們的稽核更具靈活性、透明化、視覺化，也能更好的普及SQL 規範。
五、總結與展望
資料庫自動化於DBA而言節省的是時間，避免的是人為的誤操作；於公司而言節省的是人力，避免的是人為失誤導致的故障；於整個運維體系來講它沉澱的是知識。
時間、人力和誤操作都很好理解，自動化平臺化，很多工作交予機器去處理，節省時間人力也避免手工操作失誤。最重要的是它能把DBA的經驗與知識固化到我們的程式之中，它承載的是一整套資料庫運維知識體系。
運維自動化的未來必然是智慧化，這是毋庸置疑的。但是如何開始，從哪裡開始才是真正需要關注的，可能每個團隊有自己不同見解。MOZIS平臺這塊從SQL優化、故障解決著手去探索智慧的門檻。
為什麼從這兩塊入手，主要是因為SQL優化以及基礎的故障排查慢慢的已經形成了一套簡單的排查流程，那麼把這套流程體系或者說把這些DBA的經驗程式化就可以完成這項工作。原理很簡單，實現起來可能需要我們更多的努力。
千里之行始於足下，對於SQL優化這塊前期可能也僅僅是排查一下是否全表掃描、執行計劃是否變更、索引是否最優。雖然很簡單，但是就像自動化設計是一個不斷優化的過程，我相信智慧化也是一個過程。只有從最簡單的開始不斷深入挖掘，才能從自動化過渡到智慧化。
雖然說DBA開發自動化工具甚至是智慧化工具是砸運維人自己的飯碗，但這就是趨勢。我們大可積極改變和更新運維工作者的職責認知， 順勢而動，在推動運維高效化的同時也使自己快速成長。