白屏化背後，DBA應有的資料庫自動化建設思路
一、背景
兩年多的時間裡，我們DBA Team快速完成了資料庫自動化、白屏化、閉環化、服務化的建設。 完成了JKDB資料庫自動化平臺（含元資料管理、自動化部署排程系統、監控系統、備份系統、高可用和線上切換、容量趨勢分析規劃、校驗中心等）、資料庫自助查詢平臺、許可權申請和審批平臺、自助變更執行平臺、流程引擎、工單系統、敏感資訊探測系統等等。
在這期間，除了偶爾故障和特殊支援之外，DBA 基本不需要登入伺服器去部署和操作資料。從2016年到現在，我們管理的資料庫例項大概翻了3倍，但是DBA人數基本沒有變化，目前是4個DBA維護了約1000+的SQL/">MySQL例項、1500+Redis例項，另外還維護著若干PostgreSQL / Oracle / MongoDB / Hbase叢集。
本文就將針對我們DBA Team完成的資料庫自動化平臺構建和期間的建設思路做一些簡單介紹，主要分享前期標準化構建和自動化模型搭建思路方面的部分。後續如果大家有興趣，我可以更加深入的介紹一下自動化平臺其他方面的內容。
關於資料庫標準化構建
2016年，當我入職公司時，大概經過了兩週的熟悉，儼然發現公司資料庫自動化的影子。
其一是標準化，標準化是自動化的重要前提。那個時候，我們這邊標準化是做得比較好的，從OS的標準化到DB層的標準化都有著統一的標準。比如OS的作業系統版本、檔案系統格式、磁碟掛載點、預裝軟體、核心引數等等，我們所有MySQL伺服器基本都是一致的。
這裡我們是怎麼做到保持一致的呢？
首先是我們DBA對其中一臺伺服器經過初始化設定和優化，比如按資料庫的最優策略調整核心引數，分割槽和掛在磁碟，預裝pt-tool \ MHA Node \ Xtrbackup \ Innotop \ oak-tool等資料庫常用的管理軟體，然後交付給運維同學進行打包映象，之後所有交付給DBA的伺服器都是按此映象進行部署。這樣一來，我們的OS伺服器就非常標準化了，同時也預裝了我們常用的管理工具。
我們的資料庫也有自己的部署標準，比如配置檔案標準化，除了部分可調引數是變數，其他引數全部使用標準化模板；另外像MySQL的安裝目錄、資料目錄、二進位制日誌目錄、臨時檔案目錄都有統一的標準，根據不同的例項埠來區分。
當然MySQL嚴格要做到標準化，在未做到自動化部署之前，是比較困難的，困難的不是部署技術，而是規則意識。通常一個公司都有好多個DBA共同管理資料庫，由於之前的工作習慣大家喜歡按照自己的方式來部署資料庫，或者沒有標準部署規則、有規則但是沒有嚴格遵守，都是無法做到標準化的。我們是從一開始就做了標準化規則和自動化部署指令碼，所以我們目前線上所有資料庫的部署都是標準化的，為後續自動化平臺建設打下了非常好的基礎。
例如，我們在管理機使用如下命令，則會在對應的IP伺服器上建立一個innodb_buffer_pool等於10GB的資料庫例項，埠為3306，掛載裝置為fioa，版本為MySQL-5.6.28-OS7-x86_64，資料庫編碼為utf8：
#pythonInstall_MySQL_Multi.py --ip=xx.xx.xx.xx --port=3306 --mem=10240 --device=/storage/fioa--mysql-version=MySQL-5.6.28-OS7-x86_64 --character=utf8
自動化建立的例項按照埠進行標準化部署，如下所示，某臺伺服器安裝了3306、3307、3308三個埠，則部署目錄如下所示：
配置檔案路徑： /etc/my3306.cnf /etc/my3307.cnf /etc/my3308.cnf
資料庫安裝路徑： /storage/fioa/mysql3306: binlog data mysql-error.log mysql-tmpdir /storage/fioa/mysql3307: binlog data mysql-error.log mysql-tmpdir /storage/fioa/mysql3308: binlog data mysql-error.log mysql-tmpdir
這樣部署的資料庫達到了標準化的水平，所以我們DBA只要知道IP和埠，就可以很容易地知道這個例項的所有資訊，無疑是自動化的良好基石。
二、自動化任務平臺構建
有了好的標準化基礎，我們就開始著手構建平臺了。
既然作為平臺，那麼WEB管理介面、任務排程、API服務幾個核心部分是不可以少的。下面展示一個建設初期的一個基礎架構：
如上圖所示，自上而下，系統核心部分由3層架構組成：
-
第一層為WEB控制層；
-
第二層為任務管理層和資料採集層，用於任何排程管理和資料的互動處理；
-
第三層為工作模組層，用於實現各功能的功能，比如安裝例項、配置Replication、配置MHA、建立資料庫、授權等等，這些都是由不同的底層模組來完成，通常由一系列指令碼組成。
同時系統將提供Restful API用於內部資料更新，提供HTTP API用於外部系統對接，例如和CMDB、釋出平臺等平時實現資料共享和任務對接，提供訊息通知功能用於傳送各類報警和服務類的通知功能，提供任務上報功能用於各工作模組和WEB層的資訊對接。
當然，後期我們資料庫平臺和中介軟體團隊、SA團隊、配置中心團隊完成了很多資料和功能的對接，打造了資料庫管理的閉環，例如CDMD建立好DB的資源後會通過我們的API將機器資訊推送到元資料中心，我們也會呼叫DNS平臺的服務介面來更改DNS，或者我們的平臺自動化部署完資料庫後會將域名、埠、授權使用者密碼自動推送到釋出平臺實現資料庫自動配置，開發在配置中心申請git庫時就可以同步申請資料庫等等。
通過DB平臺和公司其他部門的平臺相互打通，減少了很多人為操作環節，實現了資料庫管理閉環。
如下圖所示為我們平臺更加詳細的架構圖：
系統的核心是任務排程管理層，我們任務管理的介面如下所示，可以看到每個任務都有一個任務模組名稱，並實時記錄任務執行狀態和執行日誌：
三、關於模組化設計構建
在上面我們簡單介紹了系統的基礎架構，裡面提到了底層任務模組，比如安裝例項、建立主從模組等等，那麼這些模組底層如何優雅地設計呢？
我們平臺從開始設計時後端程式碼層就遵循高內聚、低耦合的設計思想進了模組化開發，這是我們後端設計的核心思想。
很多人在想，程式碼實現功能不就好了嗎？還需要什麼設計思想？這可能也就是開發與運維同學的思維差別。
我們知道運維同學常常忙於很多瑣碎的事情，效率優先，也習慣於指令碼化開發，可能分分鐘就寫一個指令碼實現某個功能。但是在平臺建設中，這種方式是不可取的。如果程式碼沒有規範的思想指導，當多人協同開發的過程中，很難進行專案的管理和跟進。
我們在設計時，在遵照模組化開發思想的同時，根據任務情況，設計出了任務三層排程模式，類似堆積木方式，可以很快地完成不同需求的底層任務模組，同時可維護性可非常高。另外就是複用和解耦，模組不允許同級模組相互呼叫和依賴，只允許高階模組呼叫低階模組。
如下面所示：
上面這幅圖可以很好的解釋底層的三級模組呼叫流程：
-
Level 1 為底層支援模組： 例如SSH操作模組、MySQL連線和操作模組、訊息模組（簡訊，郵件，內部資訊）、日誌模組、外部介面模組（DNS變更，CDMD同步等）、元資料維護模組(meatdata)等。
-
Level 2 為基礎單元模組： 比如安裝MySQL節點、配置主從、配置MHA、建立資料庫、DB授權等等，這些都是二級模組，基本就是完成某一個特定功能。注意Level 2裡程式碼除了業務邏輯部分，其餘只需要呼叫Level 1的模組即可。例如下面是一個安裝MySQL例項的截圖，屬於二級模組：
-
Level 3則為服務模組： 真正經常使用的模組，都是呼叫Level 2模組來進行封裝的。例如在一般業務方使用資料庫中，DBA至少需要安裝2個例項，配置個主從複製，也需要配置MHA，當然備份和監控配置也不能少。這些工作一個DBA來完成通常大半天時間過去了。那麼如果需要部署10套呢？會花費更多的時間。所以這種情況下就需要一鍵部署，一鍵通通搞定。說到這裡，還有一個問題——大家大概也注意到了安裝例項、建立資料庫等這些單一模組在Level 2模組都有，那麼Level 3幹嘛呢？其實就是呼叫Level 2就可以了。如下是一鍵部署頁面截圖，DBA填寫好提交任務即可，剩下的時候就可以處理其他工作了：
然後我們監控上報的任務日誌可以看到底層執行過程，大家可以看到任務會建立2個例項，然後配置了主從，最後配置了MHA，當然這裡面還有一些元資料維護，備份和監控開關設定等等，其實在後臺已經完成了。大概6分鐘，完成了一個DBA半天的工作，並且保證了部署的資料庫都是標準化的，不同DBA部署沒有任何差異。
再舉另外一個場景例子，通常公司對核心大業務會做TDDL分庫分表，比如十庫百表、百庫千表，需要部署在不同的物理機，這時候我們就開發了TDDL批量部署模組，基本就是封裝並行任務呼叫Level 2模組的各個模組，例如建立100個數據庫sharding的TDDL叢集，無非就是並行呼叫200次安裝MySQL例項的模組，然後呼叫100次配置主從，呼叫100次配置MHA，最後發個訊息通知。一般手工操作需要1-2天時間的任務幾十分鐘就完成了。
有了上述自動化任務排程平臺和設計規範作為基礎，我們DBA基本都很快參與進行了進行模組開發。模組開發的好處就是大家很容易上手開發，甚至之前有不會Python的同學，在簡單學習了Python之後也能照貓畫虎很快完成一個模組。
在大家的共同努力下，MySQL以及Redis日常部署和維護工作都實現了任務排程化管理。通常需要大家登入伺服器的操作現在基本都在WEB介面端就完成了。一般除了需要登伺服器定位問題和處理線上故障，基本就白屏化了資料庫管理。
這樣下來，對於整個公司而言效率高了，DBA不需要那麼多了，資料庫人為故障也少了；但對個人而言，職業工作就受到了挑戰，機會也少了，所以個人的發展只能說主要是看自己，靠自己。
最後講一點題外話，經常看到一些文章在講資料庫自動化、未來AI智慧化，預測將來DBA可能會失業。這個觀點我是二分之一認同的：隨著很多公司的自動化越來越完善，可能需要的DBA會越來越少，但我認為DBA這個崗位在任何時候都不會被淘汰。
雖然資料庫完全自動化後，難免對DBA的職業發展造成影響，但換個角度來看，留給DBA思考創新、提升自我價值的時間也更多了。其實從資料庫在公司的重要性和敏感性來看，從業務向技術轉換過程中，DBA作為資料庫的專業評審員，發揮的作用是其他崗位所無法替代的。而未來DBA應該做的，是試著轉變觀念去接收一些新事物，比如可以嘗試開發，參與到平臺開發中，或者學習一些大資料、機器學習相關的技能，又或者更深入鑽研資料庫。我相信，只要自己努力，是金子總會發光的。