鍾建輝，YY基礎運維經理，負責數據庫及服務器基礎運維工作，在數據庫領域有超過10年的工作經驗，見證了YY數據庫平臺化從”0”到”1”的整個歷程，目前主要致力於推動YY數據庫、服務器平臺化建設。
以下為鍾建輝老師演講實錄：
我的側重點主要在運維DBA的角度介紹我們數據庫系統。前面周老師就是研發的角度怎麼看我們數據庫平臺系統。
一、YY數據庫團隊面臨問題
我們早期有哪些問題？
第一是質量。早期我們經常會有質量事故發生，嚴重影響了我們一些服務對外的“口碑”
效率來說我們對於資源需求的響應遠遠達不到業務方的要求。
另外就是安全的角度來看，我們可能事後救火的東西比較多。
另外成本的角度來說我們資源利用率比較低的，就是說成本比較高。
這是我總結的YY平臺發展的幾個階段。在座大多數都是DBA，可能的話這三個階段，我想都有一個經歷。
首先第一個階段純手工運維，可能早期只有三五個實例。大家通過人肉的方式做部署、配置白名單的管理。
然後陸陸續續引進到可能我們有類似於上百個實例或者是幾百個實例的時候，我們可能會想辦法做一些工具和腳本。也就是說我們可能會做部署，我們可能會有部署的工具和腳本。我們做白名單的添加有白名單工具。
隨著我們數據庫規模的一個增加，像YY有將近上萬個實例，怎麼管理呢？光工具和腳本就達不到目標。就是面向業務整合工具嵌入到流程管理實現自動化管理，數據庫流程自動化運維。
未來下一個階段我們要討論哪個方向發展呢？大家可能也有不同的聲音，我理解後續我們可能的方向還是在智能化的階段。類似我們做智能化的收容、擴容。
二、數據庫平臺目標
這是我們做平臺化的目標第一是效率。效率我們當初定的目標，我們這個平臺一定要立足於一站式對外提供服務。
我們業務上限就是實現分鐘級的上線，老業務基本實現自動化，變更操作基本實現自動化的操作，質量緯度監控告警實現分鐘級，故障可以快速切換，DBA能快速實現故障診斷，提供開發可參考的質量數據供業務參考。
安全的緯度，安全級變更問題可追溯。我們出了問題一定要追溯，數據庫操作可審計。成本的緯度就是可度量，會計升降級優化我們的成本。
這是我們平臺的一個總覽。
分三層，業務服務、基礎平臺、資源管理。最上面是面向業務的基於下面提出的申請、擴容、數據庫的權限管理、下線以及數據庫質量等等種種服務。
但是我認為，最基礎的一層就是資源這一層，所以我認為資源池的管理非常重要。
下面會講一下資源池的管理。
三、資源池管理現狀及目標
我們目前的現狀就是我們有多個IDC，有物流和公有云的機房，支持多種存儲，我們有Sas和sata的存儲以及ssd的存儲，還有Pcie的存儲，還有我們多組件、多版本的存儲。
支持MySQL、Mongo和Redis的多個版本，還有支持一臺機器部署多個實例。這是我們的現狀以及目標。如何對業務進行服務呢？
左邊的圖每個IDC都提供資源池，MySQL、Redis和Mongodb，業務到對應的平臺選擇數據庫的類型和套餐的大小以及配置的信息，在左邊資源來對應我們的套餐，總共來說就是四份資源，我們要實現分鐘級的交互為什麼可以做到呢？
業務只是在的資源池做一個理論和配置的操作，僅此而已。所以這種效率是非常高的。
基礎組件首先是高可用這一塊。為什麼要做高可用？DBA或者是業務方，平常遇到的故障分三種類型的故障。
第一種是實例故障，第二是主機故障，第三是機房故障。但是第三類話說的很響，好像上午有人在群裡面討論，剛好有一個機房的故障，我們碰到很少。
但是遇到這些問題傳統方式怎麼解決呢？傳統方式就是我故障了，DBA就是去手工切換主庫，然後業務方更改配置文件指向新的MySQL主庫，重新啟動應用，讓更改配置生效，流量切換到新機房，但是在這種情況下DBA或者是開發抱怨非常多，很苦逼。
基於這些我們每個公司都有高可用Proxy系統架構。就是應用程序通過MySQL協議、統一入口到OSPF/VIP，然後下面是一個代理層，代理層有三個，橫向可以擴展的，代理層再到真實的存儲。
就是它實時探測我這個MySQL的存活狀態然後再切換故障的切換。ZOOKEEPER就是不同的業務對應的真實的IP的Proxy就是GK裡面記錄的。這個是高可用Proxy特性。
我畫了三個示意圖，就是北上廣三個機房，所有機房的寫操作都會路由到IDC1機房，讀是每個機房都可以讀，但是寫操作會幫你路由到IDC節點，不需要關心主節點、從節點在哪裡？
但是大家可以看出一個問題，可能對於一些寫量非常大業務來講，它的寫是有延遲的，這是一個缺點。
它有幾個特性，一個是高可用，第二是負載均衡，第三是讀寫分離，第四是BigSQL特殊處理。
有一些業務經常會有一些統計性的操作，那種怎麼辦呢？可以通過其他的方式，不一定通過MySQL去滿足，但是必須要有，我們的技術方案什麼？我們的技術方案就是我們會自動判斷它的大SQL，然後路由到一個節點來規避這個問題。
然後到多租戶，多租戶對於我們來說太重要了。就是我不太可能來一個業務我們就部署整個一套集群，那樣對於我們來說成本太高了。就是對於我們來說，一個新業務，只能在我們的GK裡面做一些配置基本上就OK了。
這是我們性能測試報告，整體大家可以看到，畢竟中間加了一層，性能會有一點點損耗，但是整體的話還不是那麼明顯。基本上還是可以接受的。剛才講到的是高頻的一個方案，那個對於我們大多數業務場景數據量並不是那麼大，可能就是三五百的寫請求，跨機房寫都可以接受。
恰恰這種業務寫量幾千上萬。或者我不知道大家有沒有類似的經歷，類似有很多公司都在出海，有可能類似於你不可能讓人家歐洲的用戶的一個數據，類似於寫到亞太來。那怎麼辦？
我們也會有一個相應的配套解決方案提供給業務方。我們內部的項目叫MyShard，MyShard解決了什麼？MyShard解決了一個多寫的問題。
MyShard的原理是什麼？它的原理實際上就是最終一致性。然後實際上最終一致性怎麼解決的呢？就是可能的話，在每個表上會加版本號的概念。
以最大版本號覆蓋小版本號。大概原理是這樣的。但是還有一個優勢就是代理分支可以去做分片，可以映射到不同的層面，對於業務來說會透明很多。
這個也會有一點點缺陷就是相應比較重一點。當然這個還沒有上限，右邊這個會基於5.7019去做了一個改造的版本。
就是利用多源複製的特性，實現多寫。大概原理實際上也是說在每個表上可能會加一些版本號的概念。然後我們複製的話就自動給他帶一個版本號。
另外一個是同步平臺數據庫基礎組件。DBA經常會遇到這樣的問題，有這樣的需求，把AB庫的某一些表同步到C庫甚至更加變態的需求就是我要把AB庫某幾個字段同步到C庫。
或者說我的MySQL要同步到異構的庫，類似於我要切到Manager或者是緩衝，類似這樣我們會給到一些基礎服務給到業務方。
它有幾個功能。第一就是特性，同步性能會提升。大家做DBA都知道，我要同步不同的數據庫到C庫，目前MySQL都會有全面的Redis，會同步一次，效率很難做到。
第二我們會做到緩存更新和清除。還有我們會將Manager同步到RabbitMQ做到應用通知，最後是異構數據同步。
四、數據庫質量平臺
講完基礎組件來聊聊我們對於質量的看法。
第一就是我們的告警。出了問題我們能快速發現，發現了可以快速找到原因，就是快速的診斷，包括實例級別的故障。另外還有一個業務級別的診斷。
我們針對一個數據庫的事件跟問題能夠有效的管理起來，並用於我們的追蹤。
-
我們能把我們數據庫的質量能夠透明的就提供給領導或者是提供給我們的業務方，讓大家都知道我的數據庫在運維數據庫平臺上它的質量情況怎麼樣？
我們要定期對數據庫的一個故障做覆盤。還有做一些故障的演練。這個是非常重要的，有可能我們平常比較穩定，突然來一個故障不至於比較慌
我們可以檢驗我們平常的數據庫平臺，提供基礎服務是否可以達到我們的預期。
這是我們數據庫質量分析平臺技術架構。上面這一部分的指標類型通過Kafka到我們的這些數據庫上面。然後下面是我們截圖的一些我們平臺上系統的功能，左邊這部分就是我們全局看板，全局看板做什麼？
就是我要全局知道，我在我們數據庫平臺上，就是在DBS上跑的情況怎麼樣？有沒有預警？有沒有告警？紅色可能有告警，黃色區域有預警。
第二張圖是我們的一個實例級別的分析跟診斷的一個圖片。就是我們能夠對MySQL的指標項做一些分析和診斷。
第三張圖就是我們一些事件管理，就是我們診斷出故障原因能夠把問題修復了。我們要記錄一個事件，方面追溯，就是下次出現同樣問題的一個處理方式。
五、數據庫成本
談談我們對於數據庫成本自己小的一些看法。我覺得可能數據庫MySQL是幾十實例或者是上百的實例對於成本的概念不會有那麼多，數據庫的規模有幾千甚至是上萬，成本這一塊，是一個很大的問題。
做好成本，我覺得有幾點，第一點最重要的就是我們能夠量化成本。把成本能夠量化出來，你首先管控成本要知道成本，右邊這一張圖我們申請了一個頁面，每個申請都會給到業務方相應申請的套餐，未來一年的一個成本。
讓他知道，有一些業務方看到類似於說，我可能評估不想那麼仔細，隨便就選一個套餐。他看到這個成本可能就會去仔細評估它的實際上的需求，這裡面非常重要。
另外做了一些成本上的一些報表，能夠彙總某一個團隊或者是某一個人下面所有的業務，他對應存儲的成本。
有三個緯度統計，一個是實例緯度、業務緯度和組織結構的緯度，哪個部門在存儲花了多少錢？它的利用率是怎麼樣的？另外知道我們的成本和利用率了，下一步就是本的優化，自然而然就是這樣的。
成本的優化這是一個根本，成本優化有技術手段和非技術手段。下面我列舉一個做成本優化的時候，在技術的手段做了哪些事情？
首先我們會有一個類似於一鍵升降級套餐的功能，這個功能基於什麼去產生的呢？業務方評估需求的時候可能往往不會那麼精細，可能有時候也沒有辦法精細。可能原來申請了一個獨裝的套餐，隨著業務的發展遠遠沒有達到預期，這個時候怎麼辦？我們要給他降套餐。
有可能他申請了很小的套餐，業務超預期發展要給他升級套餐。基於這個我們做了一些技術手段的保障，幫他一鍵升降級套餐。
原理很簡單，首先我們原來是一個類似於大套餐掌握小套餐，我們會新建一個小套餐，然後的話我們會把小套餐的一個DB指向原來的指向同步，做到上面是老的，下面是新的，做到數據一致，這個是前提。
後面的話，我們會再把它的主角色改為新的主，然後我們把所有的DB都會配置為一個帶下線的狀態，這個時候我們的老的DV，都會去到新的DV。老的做隔離下線操作就完成了套餐降級的功能，實際上升級是一樣的事情。
六、數據庫安全
我認為安全這幾部分非常重要。
第一是基礎安全，這一塊做好這一部分事半功倍。就這一塊是一個基礎的保障，網絡上或者是OS基礎的安全。
然後就是DV，DV就是存儲上的安全。類似於一定要做好跨區域的容災，或者說備份上跨區域的容災，這方面非常重要。
實際上很重要的一塊就是內容上的安全，這裡面非常重要。就是我們怎麼保障？我可能有跨區域的容災了，我怎麼保證它的數據是一致的？這裡面非常重要的，雖然有一個主庫和從庫，可能切過來一邊是100多個數據，一邊200多數據，數據內容的安全一定要保證的。
操作層面的安全也是非常重要的，減少誤操作，儘量規避誤操作。另外的話，出了安全問題，類似於說數據的一些洩露或者是種種的安全問題，能夠審計和追溯，這一點也是尤為重要。
首先講一下數據存儲的安全。就是DBMS很大的一部分工作就是備份，這是我們備份的一個總的架構圖，就是一個簡圖，我們在本地叫一級備份，就是我們在跨區域的話，會有兩個備份中心，我們從一級備份會傳到二級備份。
然後右邊是我們的一個備份的總覽圖，我們可以在系統查出備份的某一個業務備份是否成功還是失敗？能夠統計到我們有多少個業務是成功的？有多少個業務是失敗的？它目前的備份狀態是怎麼樣的？都可以查到。
然後的話這個就涉及到數據內容上的安全。例舉了一個數據一致性。剛才我也舉了一個曾經發生的事情，這個非常重要。目前我們內容上的一致性怎麼保證的呢？我們定期會去通過PP去做一些對於原庫和目標做對比。
然後通過BD做一些自動化修復，然後第二天可以看到我們對比的報告。我們的數據有沒有不一致？不一致是哪些地方？我們修復的成功與否？這部分是我們數據庫操作的安全，就是我列舉了一個我們的數據庫的一個下線的操作。
我不知道大家有沒有一些體會。就是我們很早期也會發生我們可能會有一些已經有跑業務的殘留的東西被我們下線掉了比如說用戶提單根據重要級別去進行DBA審批，然後DBA執行，類似於下線第一步需要做隔離。我防止我誤下線了？怎麼樣可以快速解除隔離，儘快恢復服務。我們怎麼做的呢？
技術上比較手段，我們就是通過某一個端口的一個MySQL，我要隔離，我可能會把所有的端口把它禁掉。另外的話就是隔離完成了我們可能就會發起一個下線，下線其實就是後臺做的東西也挺多的，我類似於要關掉實例，關掉實例我可能要做備份。可能要查到實例的節點。整個流程DBA做的事情挺多，但是通過流程化管控的方式方法去走。做完就可能是一個通知的流程。
這是我們的一個SQL發佈系統。為什麼講這個呢？我想就平常大家DBA日常的工作，這一塊也會非常多。就是說，故障一定是有故障幾率的，我操作多幾率一定會大。在這一塊我們也做了一些風險上的控制。
比如說我們可能在類似於說我要DROP table，不會直接操作這個table，我肯定有一個加Db，Drop table語句會轉換一個RENAME的語句。TRUNCATE table語句會轉換成RENAME和CREATE table的語句。
大家都是DBA，都是沒有特別的，可能就是用DP的方式執行的。整個步驟第一就是需求申請，整個平臺會基於這些步驟會去進行審核，另外可能就會分不同的級別。有一些可能不需要審批，類似非重要這些東西我們不需要審批，直接就SQL執行了。
未來和理想
我總結了四塊。效率層面的東西，我剛才總結了我們三個發展階段，我覺得未來的話，我們會朝著更加智能化的方向去發展，類似於說我們的一些監控，監控我不知道隨著量越來越大，大家有沒有發現，我們可能DBA收到的現象級的告警會非常多，但是它只是一個表象，類似於流量高，就是我們要通過各種各樣的現象去分析它的原因或者是對應的影響。
這是我們未來要考慮的東西。我們做擴容，我們做擴容實際上剛才也講過，我們能夠一鍵擴容，我們是否未來可以就朝著自動化擴容，就是智能化擴容去發展？隨著我們數據越來越多，我們的系統之間的關聯性越來越建立這種關聯關係，我覺得這個是可期的。
質量這一塊，我們提供更加可靠的，就是更加透明的SLA的服務保障給到業務方。另外我們的安全：加強SQL方面的審計，這一塊實際上我們做的不太好，等一下會有圓桌的討論，希望可以更多討論這一塊。
成本這一塊，未來我們會優化隔離方案，類似於增加目前的機器使用率，降低整體的運維成本。
注：本文經高效運維社區 2018 數據庫專場沙龍活動演講整理而成。
AIOps 風向標！ 2018 GOPS 全球運維大會 上海站即將來襲！
網易考拉和網易音樂基於數據庫的 AIOps 探索怎麼做的？
第十屆 GOPS上海站，和你聊聊。
閱讀更多 高效運維 的文章
