美團數據庫運維自動化系統構建之路

【目錄】

• 構建前的苦惱

  • 數據庫運維的多、雜、煩

• 構建中的坎坷和思考

  • 第一次吃螃蟹：1.0版系統
  • 吃螃蟹以後的反思
  • 2.0版系統的架構設計&典型功能實現案例（三個）

• 構建後的效果&後期計劃

構建前的苦惱——一線運維DBA

首先說一下數據庫運維自動化系統構建前，運維DBA都有哪些煩惱？

這是咱們的一線運維DBA的小團，它天天須要對接不少的RD（Research&Development 研發）的需求。從咱們如今的系通通計來看，使用咱們平臺系統的RD大概是一千五六百人，咱們的人數是RD人數的十分之一不到。咱們每一個DBA對接的RD需求仍是很是多的。新業務的上線，RD須要申請新的數據庫集羣。隨着業務的發展，好比：數據庫的流量大了，須要拆分了，都須要DBA手動去作。第三個是SQL的審覈和上線，SQL會不會有什麼問題，可能他測試環境OK，可是到了線上會有各類各樣的問題。第四個是變動、升級。第五個是備份，否則的話，RD把數據寫壞了，你就沒地方找了，再就是賬號和安全，虛IP的維護，DNS、MySQL自己的維護，還有數據一致性，包括RD提的一些問題的排查，自身報警的處理。這就是咱們一線運維的DBA，小團天天須要幹不少的事情，這些事情都很重複，相信你們在座的有DBA的話，確定是天天都會遇到我列的這些事情中的一個或多個。

構建前的苦惱——手動運維的煩惱

接下來，咱們先看一下美團點評初期數據庫系統的架構：一開始是兩層的架構，在主從庫的基礎上配置讀寫DNS，後來引入LVS。這個兩層或者三層的數據庫架有什麼問題呢？

好比底層的數據庫作切換了，上層的DNS配置也要變動，生效到各個機房，幾分鐘過去了……

RD說：「這個不行，你不能這麼搞，忍不了」。

因此說，這樣的數據庫架構在切換或者從庫上下線流量的時候，都會致使業務的報錯，業務接受不了。

第二個是多：重複沒有成長，你讓一個DBA一開始作搭建、擴容、拆分、切換，他們可能以爲頗有新鮮感和成就感，可是你讓他作了上百次甚至上千次以後他們以爲這個沒有成長。

第三個是雜：常常被打斷，有報警處理的時候須要立馬處理，RD找到你說這個問題必須立刻、馬上處理，因此常常在作一些事情的時候被打斷，總感受本身在作瑣事。

最後一個煩：RD常常不按照規範作事，包括上線一些大SQL、慢查詢。程序不加劇試，在網絡抖動的時候，發現數據庫怎麼鏈接斷了？他就會找到你。還有一些誤操做，前幾天有一個RD半夜打電話跟我說，線上數據誤刪除了須要恢復，經過咱們平臺去Delete數據的話，是很好恢復的，可是他說很差意思，我經過賬號直連線上刪了數據。有些明白的RD會很差意思，知道數據很差恢復；可是，有些RD會說：「你DBA就是幹這個事兒的，你就是得幫我恢復數據。」

你們很鬱悶，在沒有自動化運維繫統以前的DBA仍是很是苦惱的。

構建中的坎坷和思考——1.0版系統設計之初的考慮

以上講完了數據庫運維自動化系統構建前DBA的苦惱，接下來講一說咱們若是想去構建一套數據庫自動化運維繫統應該從哪裏開始着手，我這裏列的都是很是重要的。

第一個就是CMDB，若是你作的自動化系統中沒有CMDB，那麼，我以爲你作的自動化系統就不叫自動化系統。作自動化其實就是作標準化，這樣的話，你在作自動化運維的時候，CMDB能夠很方便的讓你查詢到信息，對業務進行合理的描述，這樣的話有一個基本的地方，其實就是數據標準，我後面會說。

第二個就是你想想在你作自動化運維繫統以前，你整個公司或者RD的需求、DBA的需求，你須要作哪些自動化。美團初期只作了三個，在線DDL，數據庫賬號申請和慢查詢。有些RD或者DBA常常出去聽一些會，好比騰訊講藍鯨，阿里講魯班，咱們回去搞一套這麼大的，其實沒有必要，大家公司須要什麼，你迫切須要的應該最早作，先把系統搭起來，再迭代。這裏我給你們說個經驗就是，能夠先從DBA內部入手，再推廣到RD。

第三個就是開發人員和成本，當時2015年初期的時候，美團App的DBA只有4我的，那時候既沒有FE，也沒有後臺作開發的，這個時候就須要考慮到開發會有一些人員和成本的問題。會想，我是否是招一我的或者招兩我的？其實沒有必要，你能夠放眼整個公司看一看，有沒有共用的平臺或者資源給你使用，這樣更快，更便利的讓你搭建平臺。

最後就是開發形式，咱們整個大的運維部是有開發人員相關資源的，咱們找到他們去幫咱們作一些頁面，這樣的話，你就會迅速的搭建你的1.0版本。

以上就是我要說的四點。

構建中的坎坷和思考——1.0版系統架構設計&使用狀況

你們能夠看一下咱們1.0版系統的總體框圖，用戶就不說了，前端模塊主要是Django+MVC的方式，前端開發是不懂DBA業務的，他們須要作什麼事情呢？他們把用戶提交的任務寫到數據庫的task表中，咱們後臺的DBA去寫一些腳本，去把前端提交的任務拉出來，拉出來以後若是有日誌，會反寫到task表裏，這就是咱們1.0版的架構，很是的簡單，可是也是很是的實用，右邊這個圖是咱們1.0版的效果，其實我後來加了DML，一開始只有DDL，業務他只須要選擇他所須要變動的SQL類型以後，提交到後端DB的task表。後臺會有一個常駐內存的進程，掃描這個DB，去發現當前有沒有須要我去執行的任務，若是有就拉出去執行，執行的過程當中會有一些日誌，會回填到這個DB中，前端從DB拉去日誌信息，就能夠展現了。當時的效果，日均的訂單是1840，2015年初，公司正是快速增加期的時候，如今應該比這個稍微少一點，當時使用人數大概600人，雖然是很簡單的一套架構，可是使用的人數仍是很是多。

構建中的坎坷和思考——1.0版的反思

1.0版的系統作完了以後爲何作2.0版的系統呢？

不是說1.0版的系統很差，或者使用的人少，隨着美團的發展你的標準化程度就慢慢得知足不了要求，因此咱們會反思1.0版的一些問題，開始去作2.0版的系統。

1.0版有什麼問題呢？

首先是前瞻模塊重，開發人員不少，由於咱們當時都是公用開發人員，開發人員不少，依賴也很是多，其實我開發習慣不太喜歡依賴什麼太多的框架、組建，這樣的話感受很重，可能致使你代碼的遷移、擴展性差。

第二個是沒有接口化，RD不方便接入，很深入的一個例子就是，有一個業務，他可能到某天的凌晨須要建跟時間相關的表，須要刪表、建表，他每次都等到凌晨的時候去平臺提交去作，他以爲很辛苦，因而就問我：「大家有沒有接口讓我去調，我寫個腳本到那個時間就把個人表建上，由於每一個時間表結構都是同樣的」。若是你的平臺沒有接口化很不方便，特別有一些須要按期跑的業務。

第三個就是開發週期長、成本高，得跟他們溝通，需求調整複雜。固然它主要在高併發、高性能上不好，緣由是什麼？由於後臺是一個常駐內存的進程，我當時只起了大概多是6個線程就跑了，併發的話只能跑6個，咱們2.0版的系統你想跑多少個就跑多少個，我一下子給你們介紹一下怎麼作的，不易擴展，這個也不方便擴展，後臺的任務就一個，掛了就掛了，圖象化作的也很差，畢竟是找人家幫咱們作的，效果也不是太好。這個是咱們爲何作2.0下定決心的一個緣由吧！

最後就是任務的不可干預性，有一個改表操做，改到一半不想改了，這時候須要DBA上去手動操做，且不能暫停、回滾，2.0版的支持。

構建中的坎坷和思考——2.0版架構設計

隨着業務的發展，1.0版系統已經不能知足咱們如今的需求，咱們就作了2.0版。

2.0版須要遵循三個方面：標準化、自助化、自動化。

第一個標準化，指的是：接口標準、數據標準、流程標準。接口標準。你不能說，個人平臺（WEB前端）提交的是一種方式，API接口提交是另外一種方式，這是不行的。數據標準，就是CMDB，必定要準，必定要實時得更新，否則整個上層，它是基石，整個上面的框架搭起來都是白費的。流程標準，你須要制定ABCD各類各樣的流程，不少DBA，他有本身的方式、方法。好比說對於拆分來講，A有它的方法，B有它的方法，可能都能達到目的，可是標準化，只能用一種方式。

第二個自助化，操做自助，只要能放給RD自主操做的就自主操做。問題定位的自助，RD碰到了數據庫相關的問題，不是第一時間找DBA，而是第一時間在你平臺上能夠看到如今數據庫的情況，定位到如今數據庫的問題，去操做相關業務邏輯解決問題。

第三個自動化，高可用和報警自動處理。高可用，從庫宕機你能夠把它剔掉；報警自動處理，對於收到報警看一眼，後臺有報警自動處理的程序就給它處掉了。

這是咱們須要遵循的三個化，標準化、自助化和自動化。

構建中的坎坷和思考——2.0版架構設計

介紹2.0版系統總體的架構以前，我先給你們介紹一下兩個開源的組件，第一個是RabbitMQ，這是一種應用程序對應用程序的通信方法，這個端對於另外一個端的通信，它是經過這個端來發消息，另外一個端接消息，從而鏈接了兩個端，很簡單，其實他的做用就是鏈接消息的橋樑，美團點評如今作的O2O，就是鏈接人和服務，你不須要本身找，你只須要在APP上操做就好了。對於消息隊列，你只須要提交到對應的隊列中去就好了。

構建中的坎坷和思考——2.0版架構設計

第二個就是Celery，這個Rabbit的中文翻譯是兔子，Celery翻譯成中文就是芹菜，兔子和芹菜構建了咱們2.0版系統。你們能夠這麼理解，Celery其實就是封裝在消息隊列上面一個很是好用的任務調度者，是基於Python開發的，他能夠幫你幹什麼呢？能夠幫你發任務，能夠幫接任務，能夠幫你定時的起任務，我今天凌晨2點拆分，能夠白天提交，凌晨Celery幫你調度。它是對於消息中間件上面很好用的封裝。

構建中的坎坷和思考——2.0版架構設計

說完了以上兩個開源的組建，咱們接下來講整個2.0版系統的架構，一點點的放出來，首先是用戶，經過前端的Web，他的全部的操做所有打到咱們的API層，業務模塊：腳本也好，系統也好，也是打到咱們的API層，這樣作到了接口的統一，後端的處理都是同樣的，無論是任何人，對於我來講都是個人一個端。

API層它能夠作兩個事情，好比我想查詢當前數據庫的主從架構狀況，當前服務裏的數據庫列表，那麼API層直接跟CMDB交互獲取數據並返回。第二種是須要後臺作任務的，好比搭建，擴容，拆分這些都是任務，它們須要到後臺的任務管理模塊去作。任務管理模塊會把任務分發下去。這中間會有CMDB。任務管理模塊能夠詳細講一下，這個就是剛纔我所說的MQ的消息管道，這裏是Celery，這裏有兩個Celery，你能夠理解爲它是MQ的封裝，你只須要給Celery通訊就能夠了。TaskControl是掛載到整個消息中間件上面的一個任務處理者。它會生成父子進程去處理任務。

構建中的坎坷和思考——2.0版架構設計

我剛纔說的爲何任務是能夠無限地增長，前提是在機器能夠承載的狀況下無限增長。第一步，TaskControl先fork出一個子進程，第二步，子進程1再fork出一個子進程，這個子進程2，是真正得作任務的進程，這個進程再調用任務執行腳本或者模塊去進行任務操做。子進程1，它會把子進程2的一些信息，好比進程PID，回填到數據庫裏，子進程一1就退出了，子進程1退出以後，它跟子進程2的關係就斷開了，這裏要說一點，子進程1得忽略回收子進程，這時候子進程2就託管給了init進程，這樣的話就生成了這麼一個任務執行單元。任務執行單元只是須要本身去作任務，好比說它去作DDL，這個子進程2是父進程，會去作子進程的回收操做，任務日誌的回填工做等。

構建中的坎坷和思考——2.0版架構設計

最後的效果你們能夠看到，就是右下角這樣的，這個TaskControl，每次生成父子進程完成以後，它就回去從消息隊列去拿新的任務，一臺機器上，好多個父子進程，併發高的時候，這些任務會有一百多個，這樣的話，大大提高了整個系統的併發性，正常的話，這裏起6個子進程就夠了，用來監放任務，生成任務執行單元。我看有些公司會起不少不少模塊去處理，用這種技巧的話，就可讓任務的執行脫離整個任務系統。

這麼作還有什麼好處呢？在作升級或者整個系統掛了的時候：咱們直接升級好了，系統掛了也沒事，任務仍是不受影響。機器掛了怎麼辦？這個就沒辦法了，機器掛了確實就掛掉了，上面的任務須要從新發起，可能須要人工的干預。

構建中的坎坷和思考——2.0版功能實現案例一：集羣搭建

說完了上面的總體架構以後我會給你們講三個案例：

第一個案例是咱們現有的集羣的搭建過程，我先說一下咱們線上跑的總體數據庫的四層架構：第一層是業務層，業務層，訪問咱們都是經過DNS，DNS下面掛的是虛IP層，虛IP層下面會掛咱們的中間件，atlas，每一個機房會有並行得部署多個，最下面掛的是數據庫主從架構，這個是如今美團用的線上數據庫主流架構。

構建中的坎坷和思考——2.0版功能實現案例一：集羣搭建

如今開始說搭建流程，我說了這麼多，你們沒看到咱們系統的廬山真面目，這個是咱們2.0版本系統的頁面。對於搭建，DBA須要先點擊一下服務組初始化，首先須要去建立一個服務，咱們每個DB集羣在數據庫裏面都是有一個標識的，被稱作服務組。

構建中的坎坷和思考——2.0版功能實現案例一：集羣搭建

接着，須要選擇你要搭建的類型，我剛纔說的四層的架構是這裏的A套餐，可是若是說是一些統計、運營類的庫，咱們可能會用到BCD套餐，後面三個套餐用的比較少。固然由於這裏有四個，可能涉及到的狀況很是多：有沒有atlas、有沒有MGW、有無DNS……可能至少得有八種狀況。有時候你們作自動化的時候，就會遇到矛盾，這種狀況怎麼辦？如今給DBA的四個套餐其實就是制定標準，就是你搭建的數據庫集羣，都是按照個人標準來的，只有這四種，DBA就說了：你有時候不知足個人狀況，DBA就要手動去作，怎麼辦？

構建中的坎坷和思考——2.0版功能實現案例一：集羣搭建

你的系統不可以兼容DBA的需求的時候怎麼辦呢？這個時候確實很麻煩，它手動運維在後面搞一搞，頗有可能形成你的CMDB信息缺失等問題，這個就很麻煩。

遇到這種狀況，我就告訴他們：「OK，我整個平臺兼容你全部的操做」。

很簡單，他說了：「我想mysql上面不掛中間件，我想直接掛MGW。」

能夠。可是你得分兩步作：第一步你是在平臺，你先把D套餐給它搭起來，你到咱們MGW和DNS裏面去申請。你在這個管理功能就能夠作。也就是說，作流程化或者是標準化的時候，你把流程制定出來的時候，也要考慮到靈活性，你要兼容它可能存在的全部狀況，咱們把線上相關的全部組件都作了管理，MGW有管理，DNS有管理，包括其餘的日誌都有管理，細分的管理都有，你正常狀況下按個人標準、按個人流程去走，你萬一涉及到特殊狀況的話，你也能夠在各個分組件的管理裏把你想作的事情作完。這樣的話，就把整個DBA或者整個ID用戶都圈到你的整個平臺裏面來了，而不是個人平臺今天只兼容一部分。這樣的話，你們作自動化起來會很費勁。 由於原來也是，原來我線上會有報警校驗線上CMDB的準確性，若是線上CMDB的錯的話，可能很是麻煩。因此說，DBA在應對RD的時候很苦惱，咱們作自動化運維開發在應對DBA的時候，也很苦惱，用這種方式就能夠知足他們了。

構建中的坎坷和思考——2.0版功能實現案例一：集羣搭建

在你們選完套餐以後就能夠到這個界面了，作數據庫運維自動化系統有不少流程性的東西，你接下來須要走哪一步，選完套餐以後讓他選機器，你的監控是什麼，buffer pool多大，下面會給他展現一個實時的拓撲；你要把你的用戶當小白鼠，你得告訴他如今長什麼樣子了，否則的話他提交出錯了，又回來找你。

構建中的坎坷和思考——2.0版功能實現案例一：集羣搭建

第二個咱們去選擇atlas，根據分組選擇atlas，就是數據庫中間件，選擇完以後就能夠造成這樣的圖。

構建中的坎坷和思考——2.0版功能實現案例一：集羣搭建

第三步就是你去申請這個虛IP和域名了，這個虛IP層正常一個機房會有一個。一個虛IP上會掛多個atlas。

構建中的坎坷和思考——2.0版功能實現案例一：集羣搭建

到最後一步可能就是你須要新搭建集羣的時候，須要給RD申請一個DB，申請一個賬號，讓他能夠訪問。

構建中的坎坷和思考——2.0版功能實現案例一：集羣搭建

這樣造成最後一個大的JSON，讓DBA去作確認，你申請的服務名稱、你當前數據庫的機器、中間件的機器、你的虛IP層和域名，包括你的DB，會有一個總體的拓撲圖，這樣的話。而後把整個的參數，全部的須要你完成這個數據庫集羣搭建的參數合成一個大的JSON。發到API層，API層會作參數校驗，你當前搭建的參數是否知足系統的要求，若是知足要求，就會發到後臺的流程引擎中，就是後臺系統去作任務。作任務的時候，你們可能說，我需不須要有什麼高深的語言，這個無所謂了，你能夠是腳本，也能夠是程序。咱們如今線上，搭建的話用的仍是DBA他們一開始寫的搭建腳本，只須要把腳本改造一下，輸入，輸出標準化一下，你可以識別腳本的輸出輸入就好了。

你們說自動化很艱辛，很艱難。其實身邊有不少的資源就是DBA手中平時作的一些腳本，有一些腳本可能DBA本身用，寫的不太好。可是他自己，他是有很是大的價值的，由於他是終年累月改過的，可能初版不行改第二版、第二版不行改第三版，他可能改了一年，他的整個腳本跑起來仍是很是流利的，咱們腳本搭建很穩定得跑了10個月的時間，主要的緣由是由於咱們DBA很靠譜，積累的不少實用的腳本。有些純開發的人去作DBA的自動化系統，他很難理解DBA的需求，有時候DBA也講不清楚，因此經過你作系統，他作腳本的方式去合做，真的很靠譜。由於作出來的系統是很是穩定的。

構建中的坎坷和思考——2.0版功能實現案例二：在線表變動

說完了數據庫集羣搭建這個案例，咱們說第二個案例：在線表變動是怎麼作的。首先批量的DDL或者DML打造咱們的API層，咱們API層會作兩個事情，第一個是語法檢測，語法檢測有兩種方式，一種是測試庫，一種是sqlparser；好比，對於autoddl的create操做，你能夠在測試庫上建一下這個表，你就知道語法對不。或者是說alter操做，你可能先從線上把表結構拉到測試環境，在測試庫上先建上，再把alter語句用到這個表上，你看alter能不能經過，這樣很方便就繞過了sqlparser。

可是，在這個時候，由於在作在線的DML的時候，你是須要給用戶備份的，方便用戶，萬一我誤操做了，能夠去恢復，就必須進行sqlparser。第一步：你必須把update或者delete語句改寫成select，而後會去線上作查詢計劃，看一下explain的結果是否知足個人要求，若是不知足的話，就提示選擇，不是直接拒絕掉，沒有那麼暴力，這個後面會說。因此說這個sqlparser，應該也是一個比較基礎的難題，你們能夠嘗試一下在源碼把這個sqlparser抽離出來，或者你們能夠考慮去找一些已經開源的sqlparser。第二個就是語義的檢測，是什麼呢？也是標準化，就是RD提交的SQL是否知足你的要求，好比命名的要求、必需要有主鍵索引，並且不能有重複的索引，對於DML來講，由於對於互聯網應用來講會有不少的好比說客服給咱們運營人員說，個人什麼什麼錯了，這個時候運營的人都會改這個數據庫，改動通常都是一兩行這種，因此咱們設定一千行基本上可以知足大部分人的需求。而後在語法、語義提交經過之會到後臺的提交任務，剛纔所說的2.0的系統，由後臺的任務執行者去執行，而後作在線的DDL。咱們選擇的是開源的pt-online-schema-change，這個是一個開源工具，它作操做的時候，能夠作到在線改表的時候不鎖表，固然還會有一些其餘的問題，這裏不是咱們今天所說的重點，你們若是之後有遇到這個工具備什麼相關的問題均可以找咱們，美團仍是踩了很是多的坑，有比較多的經驗。

構建中的坎坷和思考——2.0版功能實現案例二：在線表變動

你們能夠看看這是咱們如今的在線表變動的提交頁面。這裏也是先選業務，選完相關的業務，你選庫，選操做類型，咱們這裏會有一個業務高峯的描述，好比對於pt-online-schema-change在作表變動的時候，他會有一個數據拷貝的過程，因此說咱們會有一個業務高峯，在業務高峯的時候RD發起的任務是不能被執行的。還有任務操做時間區間，RD也能夠選，好比我選今天晚上凌晨變動或者何時變動都是OK的，RD把他的SQL批量粘到這裏。對於在線的分表，粘一個母表就好了，下面咱們自動生成帶數字的語句會給他操做。這樣也方便咱們後臺的處理，對於512的分表，咱們只校驗第一個語法語義就好了，否則的話，會產生不少性能問題。

構建中的坎坷和思考——2.0版功能實現案例二：在線表變動

講到這裏你們確定會有疑問，若是你在語法檢測或者語義檢測出問題的時候應該怎麼辦？咱們不是很是暴力的把RD的請求直接拒絕掉。而是在這裏，給了RD一個選擇：也就是說咱們如今，大部分在線的表變動都是自動的，固然有一些不知足語法語義的單子，語法固然不用說了，直接報錯給RD讓修改，對於語義來講，有些RD說，你幫我刪或者幫我改，咱們能夠接受延遲，這個時候咱們讓RD選擇，你能夠點繼續，把這個單子發給DBA，若是DBA說能執行就能夠執行了，咱們的在線表變動是手自一體的。咱們要把RD全部的操做，都得圈到咱們的平臺裏去作，而不是說我語義不支持了，就找DBA手動去作。

構建中的坎坷和思考——2.0版功能實現案例二：在線表變動

這裏能夠看到，遇到了語法或者語義檢測失敗以後，咱們的平臺會給他報錯，並會給他一個詳細緣由的解釋，你不能說錯了，並且你要直白得告訴RD爲何錯了；這樣的話能夠提高RD的DBA能力。好比說這裏長度，SQL語法問題，都會告訴他；這樣的話，他可能用問一次兩次，後面若是用多了，他就不會問了。

構建中的坎坷和思考——2.0版功能實現案例二：在線表變動

這個就是咱們整個任務執行的一個詳情的單子，就是RD在提交完任務以後在這個頁面看到他任務執行的詳細的信息，這上面是一些元信息，包括他提交的時間，他服務的信息，下面會有一個詳細的執行日誌發給他，你在作任務操做的時候，你把你的任務相關的數據實時回填到任務表裏，前端只須要讀這個任務表就好了。

構建中的坎坷和思考——2.0版功能實現案例三：高可用解決方案（MHA）

第三個案例是什麼呢？就是咱們的高可用的解決方案，上面已經列了，美團如今用的是開源的MHA，一個很牛的日本人寫的。我這裏大概介紹一下切換的過程，原理你們能夠回去本身看，左邊是咱們四層的架構，咱們如今整個MHA只運用於這四層的架構，若是你不是這四層的架構切換過程是不知足的。對於主從的結構這裏會有監控的哨兵，好比這個哨兵他發現如今主庫連不上了，這個時候，他不是說我就切換了，他是先聯繫其餘哨兵，不能相信謠言嘛，也要先打聽打聽我本身的判斷是否是對的，他會去聯繫其餘幾個哨兵，大家幫我看看當前主庫是否是掛了，其餘幾個哨兵跑回來跟他說主庫確實掛了，他便開始切換。

到了第2步，調MHA去作主從切換。切換完以後呢，他會經過API去改CMDB的信息，CMDB裏面會描述數據庫的主從的架構，描述完以後，他會去調接口，通知中間件變動主從信息，那麼到3.2爲止服務就恢復了。咱們如今自動和手動作切換，時間都在10秒左右，若是RD程序有數據庫重試的話應該是沒有影響的。切換完以後會到第4步，其實這裏很簡單，就是告訴哨兵主從結構變了，告訴他從新監聽新的主從結構就OK，這是咱們如今平臺去作切換的過程，你們能夠借鑑一下。

構建以後的效果和後期計劃——構建以後的效果

說完咱們總體的1.0版的數據庫自動化運維繫統、2.0版的系統，以及三個案例以後咱們來看一下如今整個線上構建以後的效果，以及咱們後期的計劃。這個統計圖是一個開源組件統計的，他能夠分析天天咱們的一個用戶量，咱們天天在這個平臺上跑的RD的用戶量大概是在三百多。天天會有三百多RD在咱們的平臺上作操做，累計的RD數目大概是1461個，這些是須要跟DB打交道的RD數量。這個是咱們總體平臺跑的效果，你的自動化運維繫統作出來以後作的怎麼樣？不是嘴說的，仍是要有質量運營的數據。咱們作質量運營，包括用戶數，任務的成功率，平臺的接入率，功能的覆蓋率去衡量整個平臺的指標。

構建以後的效果和後期計劃——後期計劃

這個圖，也是咱們，我剛纔前面已經講過了，這個架構。咱們在使用這個架構的過程當中，很好用，很是好。可是也會存在一些問題，存在什麼問題呢？首先這個API層，隨着前端的功能愈來愈多，咱們API會有200多個，不少不少，維護起來比較麻煩。第二個是CMDB，誰均可以去寫。

第三個這個任務執行者如今用不着重，由於他如今須要處理後端的各類各樣的任務，他會愈來愈重，DBA可能想要加一個功能，也只能找我加或者咱們組內的人去加這個功能，這裏能不能讓DBA也參與進來？

構建以後的效果和後期計劃——wew後期計劃

在這個作完以後咱們會有一個後期的計劃，咱們須要把整個的架構改形成這樣的，加入兩個東西，一個是核心功能庫和核心組件庫，這兩個東西包含了API基礎的核心功能，包括日誌，包括統計，包括權限校驗都放在覈心功能裏，核心組件包括一些DNS組件，Atlas組件、監控都放在這裏操做，API層只須要負責他的邏輯就好了。

任務執行者也是隻作通用，我只幫你分發任務，幫你作任務的子進程生成，具體誰去作，去調任務執行平臺去作，這樣的話，我只要任務平臺作的足夠好，DBA或者RD只須要把你的腳本放在這個平臺的下面的目錄裏，就能調用整個系統，這樣的話很是方便，讓更多的人蔘與你整個平臺的建設、開發和改造的過程當中來。