從0到1 | 滴滴DB自動化運維實踐瞭解一下

一．滴滴DB架構介紹

通常來講，自動化運維都會根據本身原有的架構來設計自動化運維平臺，上圖是滴滴DB的架構圖，最上面是TGW LVS，也就是你們所熟悉的VIP，接下來是代理層dbproxy。代理層下面是MySQL的主從關係，通常狀況是一主、一備主和一個從庫，若是讀取操做多，QPS會比較高，從庫也需相應的增多。

同時還要有MySQL高可用的監控來應對主庫掛了等等的異常狀況。運維監控，咱們是使用最多見的ZABBIX來作的。除此以外，咱們還作了備份模塊和性能優化的模塊。

dbproxy至關於一個入口，鏈接應用，它是分佈式的，所以每臺上都會有本身的原始配置，全部的訪問DB的流量都要通過dbproxy層，dbproxy會記錄正常的訪問日誌，還有一些錯誤日誌，例如沒有加白名單或者是SQL語法錯誤等等都會在dbproxy層攔截，產生錯誤日誌。

上圖的架構就是咱們在作自動化運維的初始部署，咱們但願可以完成從業務申請到部署完成的一系列連貫動做。

二．主要工做

咱們平時的工做內容如上圖所示，基本包括部署、工單處理、擴容拆分、監控報警處理以及其它任務。

一週時間，RD申請30—50個實例在咱們的工做中是很常見的，這時若是沒有自動化運維，單純靠本身手工部署的話，是很消耗時間的；工單處理的工做內容基本就是作一些DDL、表結構的變動，白名單以及其它需求；隨着業務的發展，數據量會猛增，因爲單機磁盤的存儲是有限的，這時咱們就要思考擴容、拆分的問題了，還有一種狀況是磁盤可能足夠存儲，可是你的TPS/QPS單機可能撐不住，這時也要去作擴容；監控報警處理指的是咱們前面提到的SQL錯誤，白名單沒有加以及其它一些報警。

其中，部署和工單處理是咱們平常工做的重頭，其佔比大約爲70%。可是這一部分工做很容易自動化，一旦實現自動化，咱們的工做強度會大大下降。