梁寶利，甜橙金融數據庫高級研發工程師，多年數據庫運維研發經驗，目前主要負責甜橙金融數據庫自動化運維設計與開發工作。
隨著甜橙金融業務的不斷增長，技術架構不斷更新迭代，底層數據庫架構和數據容量也在快速增長，給數據庫運維帶來了很多挑戰。
甜橙金融的數據庫團隊在迎接挑戰的過程中逐漸形成了獨特的自動化運維體系，下面我們簡單介紹一下自動化運維的心路歷程，同時對自動化過程中碰到的問題給出我們的解決思路，希望能夠互相借鑑。
接下來將從以下幾個方面對公司的自動化運維進行介紹：
日常工作——知道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開發自動化工具甚至是智能化工具是砸運維人自己的飯碗，但這就是趨勢。我們大可積極改變和更新運維工作者的職責認知，順勢而動，在推動運維高效化的同時也使自己快速成長。
近期熱文
閱讀更多 DBAplus社群 的文章
