當(dāng)下泛 DBA 化的趨勢(shì)是非常明顯的，一方面業(yè)務(wù)對(duì)多類型數(shù)據(jù)庫的實(shí)際需求，DBA不能只立足玩轉(zhuǎn)一款數(shù)據(jù)庫產(chǎn)品，關(guān)系型+非關(guān)系型/OLAP+OLTP/圖數(shù)據(jù)庫/消息存儲(chǔ)，但凡跟數(shù)據(jù)有關(guān)的都可能是 DBA 需要去了解的。另一方面上云后 DBA 不用再為過去繁重的基礎(chǔ)設(shè)施穩(wěn)定性保障所拖累，同時(shí)云上提供了運(yùn)維管理相關(guān)的 PaaS 化產(chǎn)品，這很大程度降低了 DBA 管理的復(fù)雜性，因此很多人會(huì)認(rèn)為上云了對(duì) DBA 的依賴就降低了或者干脆就不需要 DBA 了。

從近3年對(duì)云實(shí)際使用經(jīng)驗(yàn)看，在人員與業(yè)務(wù)體量小一點(diǎn)的公司對(duì)開發(fā)&運(yùn)維&安全標(biāo)準(zhǔn)規(guī)范都沒有嚴(yán)格要求跟約束的情況下是適用的，但是體量稍微大一點(diǎn)就玩不轉(zhuǎn)了，尤其混合云的環(huán)境下依靠云商能力是很難解決自身個(gè)性化的需求的。尤其體系化建設(shè)是無法依靠堆“云產(chǎn)品積木”的方式去構(gòu)建。

什么是體系化建設(shè)

提到體系化建設(shè)總給人一種很虛的感覺，到底體系化包含哪些內(nèi)容？主要圍繞著3個(gè)方面的能力建設(shè)上：

接下來簡(jiǎn)單介紹一下貨拉拉圍繞上述三點(diǎn)進(jìn)行的相關(guān)能力建設(shè)。

穩(wěn)定性

貨拉拉 DBA 團(tuán)隊(duì)管理了MySQL（阿里云RDS、華為云RDS、AWS-Aurora RDS）、ES、Kafka、RabbitMQ、Redis-Cluster 以及各種組件 Canal/ZK 等)，同時(shí)在全球有若干個(gè) IDC，每個(gè) IDC 又包含了多環(huán)境（測(cè)試、預(yù)發(fā)、生產(chǎn)），上千人的研發(fā)團(tuán)隊(duì)，這么復(fù)雜的場(chǎng)景跟體量還真的需要一個(gè)專業(yè)的團(tuán)隊(duì)來管理。

數(shù)據(jù)庫上云穩(wěn)定性并不能做到5個(gè)9，云只是解決了基礎(chǔ)設(shè)施的管理問題，過去DBA在基礎(chǔ)設(shè)施上投入大量的精力主要就是保障基礎(chǔ)設(shè)施的穩(wěn)定性，這么看上云確實(shí)能提高基礎(chǔ)設(shè)施的穩(wěn)定性保障水平。但是如何在應(yīng)用層面保障數(shù)據(jù)庫穩(wěn)定性是不在云商保障范疇內(nèi)的。

雖然有的云商提供了數(shù)據(jù)庫自治服務(wù)但是整體看下來還是比較弱的，且不是每家云都具備該能力，而且自治服務(wù)是收費(fèi)的也并不便宜。

MySQL

SQL事前發(fā)現(xiàn)

通過對(duì)預(yù)發(fā)環(huán)境的 SQL 旁路然后將旁路結(jié)果對(duì)歷史記錄進(jìn)行對(duì)比就可以很容易發(fā)現(xiàn)每天DB新增了那些慢、危險(xiǎn)SQL，然后及時(shí)地預(yù)警給測(cè)試跟研發(fā)同學(xué)進(jìn)行優(yōu)化改造。同時(shí)與發(fā)布系統(tǒng)打通進(jìn)行卡口、未優(yōu)化完成的 APPID 禁止發(fā)布，起到攔截作用。

SQL 旁路的前提條件：接入貨拉拉自研的數(shù)據(jù)庫中間件、該中間件覆蓋了所有云 RDS，基于中間件將各個(gè)環(huán)境的全量 SQL 旁路且分發(fā)到 Kafka 供數(shù)據(jù)庫管理系統(tǒng) DMS 進(jìn)行消費(fèi)處理，每天處理消息量達(dá)100億，單純消息分析處理能力對(duì) DBA 就有一定的考驗(yàn)。

SQL事中兜底

如何無差別防范任何 SQL 在任何場(chǎng)景下?lián)舸?shù)據(jù)庫？一方面數(shù)據(jù)庫中間件會(huì)實(shí)時(shí)感知數(shù)據(jù)庫RT情況，一但RT整體響應(yīng)異常則啟動(dòng)限流功能，或者 DBA 可以主動(dòng)介入熔斷、限流特定 SQL，甚至可以干擾執(zhí)行計(jì)劃做到走特定索引的功能。

同時(shí) DMS 自愈系統(tǒng)會(huì)實(shí)時(shí)感知數(shù)據(jù)庫 processlist 列表是否有堆積或者長查詢，自愈系統(tǒng)會(huì)根據(jù)規(guī)則進(jìn)行查殺動(dòng)作，比如 CPU/IO 異常、SQL 執(zhí)行時(shí)間超過規(guī)定時(shí)間、processlist 列表堆積、鎖等待、連接數(shù)超警戒水位等。自愈系統(tǒng)要跟監(jiān)控系統(tǒng)進(jìn)行配合才能做到實(shí)時(shí)的感知能力，這也是需要進(jìn)行個(gè)性化建設(shè)的。

可以看到該保障能力建設(shè)落地后，我們數(shù)據(jù)庫 thread_running/processlist 列表堆積超過30（云上普遍都是4-8C這樣的小規(guī)格活躍SQL數(shù)定在30相對(duì)合適的）的實(shí)例比例都不到1%（監(jiān)控只要發(fā)現(xiàn)一次就視為異常），日?；谠撝笜?biāo)就可以比較直觀的評(píng)估最近一段時(shí)間數(shù)據(jù)庫穩(wěn)定情況了。

SQL事后治理

研發(fā)可以基于 DMS 系統(tǒng)獲取到對(duì)應(yīng)的慢查詢趨勢(shì)跟詳情信息，方便研發(fā)進(jìn)行日常優(yōu)化治理。當(dāng)然也需要一些系統(tǒng)外的機(jī)制保障研發(fā)是在不斷治理的，整個(gè) SQL 防控、兜底、治理就算閉環(huán)了。

可以看到高危慢查詢?nèi)f分率常態(tài)化下都在萬分之一附近波動(dòng)。

圍繞 SQL 治理我們甚至做了一個(gè)類似阿里云的 SQL 洞察的功能，一方面兼容當(dāng)前所有云產(chǎn)品其次其他云也不具備該功能而且即使有也不便宜?。?/p>

SQL發(fā)布變更

其次威脅穩(wěn)定性的來源就是日常數(shù)據(jù)庫的發(fā)布變更了。發(fā)布主要解決3個(gè)方面的問題。

1、SQL規(guī)范

就是大家通常說的SQL審核，尤其是在具備一定規(guī)模跟體量的業(yè)務(wù)下SQL規(guī)范是很重要的，一些微小的缺陷都可能被大流量、高負(fù)載放大影響。由于開源系統(tǒng)跟我們自研的DMS 系統(tǒng)整合比較困難，索性就重新開發(fā)了一個(gè)，通過數(shù)據(jù)運(yùn)營指標(biāo)發(fā)現(xiàn)其實(shí)研發(fā)是很難遵守規(guī)范的，幾乎每周都有10%做的變更不合規(guī)。所以試圖將云上 DB 直接交給開發(fā)自己維護(hù)這一個(gè)角度看就很不可行。

2、變更安全

保證 DML 安全執(zhí)行避免更新行數(shù)太大，以及能快速回滾數(shù)據(jù)吳跟新，對(duì) DDL 尤其超大表能安全順利變更完成，尤其我們運(yùn)行在多家云上每家云的架構(gòu)及內(nèi)核特點(diǎn)都不一樣對(duì)DDL的友好性也不同。我們最終還是選擇通用 GH-OST 方式，為了降低鎖/高并發(fā)等對(duì)DDL的影響我們也是對(duì) ost 做了很多二次開發(fā)確保 DDL 成功。

3、成功率保障

貨拉拉是家快速成長的公司，每天數(shù)據(jù)庫變更量日均在600+，因此發(fā)布的效率跟成功率是很重要的，效率上我們發(fā)布系統(tǒng)會(huì)自動(dòng)識(shí)別部署架構(gòu)比如阿里云我們由于大量使用分庫分表很多集群是沒有 slave 節(jié)點(diǎn)的或者有 slave 節(jié)點(diǎn)單不參與 online 業(yè)務(wù)，對(duì) gh-ost修改后會(huì)自動(dòng)優(yōu)化相關(guān) hook 函數(shù)保證 DDL 效率優(yōu)先。

為應(yīng)對(duì)大規(guī)模發(fā)布我們發(fā)布系統(tǒng)被設(shè)計(jì)成分布式可以輕松擴(kuò)容的，當(dāng)發(fā)布能力不足時(shí)加幾個(gè) agent 節(jié)點(diǎn)就可以了，理論上我們能應(yīng)對(duì)任何突發(fā)大量規(guī)模發(fā)布。

可以看到我們發(fā)布成功率還是非常高的，同時(shí)發(fā)布時(shí)長整體也都在10分鐘左右就可以結(jié)束。

Redis

對(duì) Redis 穩(wěn)定性威脅最大的無非就大key、熱key了。

大key、熱key防御

貨拉拉在發(fā)展初期PHP是主流，后續(xù)不同團(tuán)隊(duì)又引入了其他開發(fā)語言，由于我們目前采用的是統(tǒng)一Cluster架構(gòu)，很多語言再對(duì)Cluster協(xié)議上支持的不夠完善，最常見的問題就是集群節(jié)點(diǎn)發(fā)生調(diào)整會(huì)導(dǎo)致業(yè)務(wù)端長時(shí)間感知不到底層變化業(yè)務(wù)持續(xù)性故障，還有就是PHP短連接等問題，因此我們?cè)O(shè)計(jì)了一套代理來解決多語言的問題。

對(duì)PHP短連接服務(wù)實(shí)現(xiàn)短鏈變長鏈，由于是 sidecar 部署模式引用到 mesh 層的網(wǎng)絡(luò)開銷就比較小，應(yīng)用RT與Redis節(jié)點(diǎn)CPU分別下了40%、60%。

對(duì)大key、熱key也有了更好的應(yīng)對(duì)方案，比如對(duì)大key限流/block訪問，大key導(dǎo)致的危害一下就解決了，比如下圖因大key導(dǎo)致的網(wǎng)絡(luò)流量異常限流效果立竿見影。

對(duì)熱key進(jìn)行本地化緩存+低粒度更新，rt增高問題迅速得到緩解。

Kafka

Kafka 本身其實(shí)是比較穩(wěn)定的，但是對(duì)業(yè)務(wù)而言穩(wěn)定性風(fēng)險(xiǎn)主要來自自身消費(fèi)延遲感知問題，過去研發(fā)普遍會(huì)在消費(fèi)系統(tǒng)里面埋點(diǎn)以此來感知消費(fèi)延遲情況，但是實(shí)際效果上效果不是太理想，主要原因在于現(xiàn)在的延遲度量方式都是以 lags 這維度的，是比較抽象的。

延遲發(fā)現(xiàn)

基于時(shí)間維度的延遲度量是更直觀的，對(duì)研發(fā)更加友好。我們?cè)O(shè)計(jì)了兩個(gè)獨(dú)立方式：

該方式比較簡(jiǎn)單由于要消費(fèi)消息取時(shí)間戳因此效率非常低，但是比較準(zhǔn)確。

該方式不需要消費(fèi)消息效率非常高，準(zhǔn)確度略差。

新的延遲度量有效解決研發(fā)對(duì)延遲度量上的焦慮，研發(fā)可以通過系統(tǒng)比較簡(jiǎn)單的配置就可以訂閱消費(fèi)延遲告警，也不需要再系統(tǒng)內(nèi)進(jìn)行埋點(diǎn)。

資源/故障隔離

實(shí)際運(yùn)維過程中來自 Kafka 本身的故障非常少，日常穩(wěn)定性問題主要集中在諸如網(wǎng)絡(luò)、磁盤異常導(dǎo)致的整體業(yè)務(wù)抖動(dòng)，以及在防范一些 topic 生產(chǎn)或者消費(fèi)導(dǎo)致的資源嚴(yán)重占用造成的相互響應(yīng)問題。針對(duì)這個(gè)問題 DMS 系統(tǒng)設(shè)計(jì)了一個(gè)租戶的概念，DMS 對(duì)集群broker 節(jié)點(diǎn)進(jìn)行編組構(gòu)成一個(gè) Zone，創(chuàng)建 topic 時(shí)將 topic 指定到特定 Zone，實(shí)際創(chuàng)建時(shí)通過 go-sarama 接口將 topic 指定到特定機(jī)器（Zone），如下圖：

這樣設(shè)計(jì)的好處是實(shí)現(xiàn)資源隔離的目的、故障隔離的目的。比如某個(gè)Zone的機(jī)器異常不會(huì)影響其整體，同時(shí)對(duì)于單個(gè)Topic讀寫過大導(dǎo)致的資源占用也能很好的應(yīng)對(duì)，同時(shí)還解決了Topic自由調(diào)度的問題，比如可以將一個(gè)小規(guī)格Topic遷移到大的Zone內(nèi)，過程是對(duì)業(yè)務(wù)無感的也不用換鏈接地址。最后對(duì)提高資源利用率有很好的作用，因?yàn)椴煌琙one用的機(jī)器規(guī)格可能是不同的，日常擴(kuò)縮容可以精確到Zone，避免集群整體擴(kuò)容造成的浪費(fèi)及業(yè)務(wù)影響。

ES、MQ

篇幅原因不一一介紹了。

賦能運(yùn)維&研發(fā)效率

1、賦能 DBA

前面介紹過了貨拉拉的基礎(chǔ)環(huán)境其實(shí)是非常復(fù)雜的，DB選型多種類多，分布在幾朵云上，每朵云都有獨(dú)立運(yùn)行的環(huán)境，DBA其實(shí)是很難通過云產(chǎn)品進(jìn)行有效管理，如果只用單一云服務(wù)且體量有比較小依靠云 PaaS 產(chǎn)品也能解決一些日常問題，這顯然不適合我們。

站在DBA跟研發(fā)的角度看都有共同的訴求：通過一個(gè)入口一個(gè)平臺(tái)搞定所有日常運(yùn)維需求+研發(fā)所有需求，因?yàn)檎军c(diǎn)、環(huán)境、選型太多了，先不論云上是否提供了類似能力，即使有對(duì)于一個(gè)上千人的研發(fā)團(tuán)隊(duì)也是極其低效的。因此一套大一統(tǒng)的系統(tǒng)架構(gòu)是必要的。

對(duì)DBA而言無非就是通過系統(tǒng)將日常工作自動(dòng)化掉，且在一套系統(tǒng)上完成。

整體對(duì)DBA而言日常90%以上的工作可以借助平臺(tái)完成。

2、賦能研發(fā)

對(duì)研發(fā)而言無外乎就是資源申請(qǐng)、發(fā)布、告警訂閱、變更、安全等自助化服務(wù)，這些由于內(nèi)嵌了公司的很多流程、SOP 這一點(diǎn)云商 PaaS 是很難解決的。

DBA日常維護(hù)了MySQL、Redis、Kafka、ES、MQ等中間件，支持上千人的研發(fā)團(tuán)隊(duì)，日常咨詢量減去知識(shí)庫攔截率實(shí)際需要DBA人工支持的Case每天不足20個(gè)，研發(fā)日常大部分需求都可以通過DMS自主解決。

科學(xué)合理的資源使用

成本治理大致兩個(gè)手段：運(yùn)維手段進(jìn)行資源治理、技術(shù)手段進(jìn)行資源合理利用。

以我們成本占用比較高的MySQL、Kafka為例。運(yùn)維上通過縮容、將配我們很快榨干了明顯使用不合理的資源。在需要有所突破就很難了，因此需要在技術(shù)上找到新的增長點(diǎn)。

MySQL

由于云是規(guī)格整體是偏小的應(yīng)對(duì)突發(fā)異常的情況是比較弱的，我們將數(shù)據(jù)庫拆分的比較細(xì)因此我們下掉了大部分slave節(jié)點(diǎn)。

經(jīng)典存算一體架構(gòu)下存儲(chǔ)與計(jì)算是存在綁定關(guān)系的，不管是云上還是自建都會(huì)存在這樣的關(guān)系，比如在云上你要買3T的存儲(chǔ)你的CPU都不能低于8C，或者你要買一個(gè)16C算力你的存儲(chǔ)不能少于3TB，這就會(huì)出現(xiàn)算力與存儲(chǔ)不匹配的問題，造成算力跟存儲(chǔ)的浪費(fèi)。自建IDC下尤其如此 因?yàn)榉奖憬y(tǒng)一運(yùn)維與硬件采購可能所有數(shù)據(jù)庫服務(wù)器的規(guī)格配置是一致的這個(gè)浪費(fèi)更加明，搞過自建的同學(xué)應(yīng)該深有體會(huì)。今天我們可以充分利用云的能力來最大程度的提升我們的資源利用率加上我們自建能力及云的能力實(shí)現(xiàn)既便宜又好用。后續(xù)ServerLess架構(gòu)成熟后相信成本控制上會(huì)有更豐富的手段。

自建環(huán)境下是很難將平均存儲(chǔ)使用率做到這么高的，在2023H1結(jié)束前我們預(yù)計(jì)存儲(chǔ)平均使用率能做到75%以上。CPU平均使用率15%左右，做到這一點(diǎn)是非常困難的，要兼顧成本跟容量安全，這塊我們前面在穩(wěn)定性介紹里提到了我們是具備比較強(qiáng)的應(yīng)急處理能力的，確保我們具備探索更多的可能。

Kafka

基于前面介紹的多租戶的方式、不同場(chǎng)景使用不同配置的租戶，不同租戶內(nèi)實(shí)現(xiàn)定向擴(kuò)縮容，能有效的避免Topic間資源分布不均導(dǎo)致的資源浪費(fèi)。

Kafka歷史上為應(yīng)對(duì)突發(fā)消息暴漲我們規(guī)定了存儲(chǔ)使用超過50%可能就要擴(kuò)容了，當(dāng)前的磁盤、CPU平均使用率還是比較高的。

我對(duì)DBA的理解

1. 運(yùn)維型 DBA：這是偏常見DBA的工作，能很好的在當(dāng)下管理體系下按照標(biāo)準(zhǔn)完成日常工作，比如基本問題的處理、研發(fā)對(duì)接等。
   
   
2. 開發(fā)型 DBA：懂開發(fā)似乎是今天 DBA 的標(biāo)配能力了，這類嚴(yán)格來說不是DBA了，我們今天一直說的泛化 DBA 其實(shí)就指的這類型的 DBA，而不是說你可以維護(hù)幾款數(shù)據(jù)庫產(chǎn)品，對(duì)他們的要求是很高的，一方面懂?dāng)?shù)據(jù)庫，懂?dāng)?shù)據(jù)運(yùn)維，懂開發(fā)(前端+后端)，懂?dāng)?shù)據(jù)庫周邊生態(tài)工具，以及快速的學(xué)習(xí)能力，因?yàn)樯显频拇筅厔?shì)下 DBA 不在為基礎(chǔ)設(shè)施所拖累 DBA 承載的面就要擴(kuò)展，最后可能還是自己的產(chǎn)品經(jīng)理，因?yàn)闆]有人給你畫原型圖也沒有人告訴你頁面該長成什么樣子，什么地方該放什么按鈕以及他是什么顏色的…，這些都要建立在上述復(fù)雜的要求之上。
3. DBA 架構(gòu)師：這類 DBA 是經(jīng)驗(yàn)+意識(shí)型的 DBA，對(duì)數(shù)據(jù)庫有深度的理解、綜合技術(shù)全面、對(duì)內(nèi)知道什么階段做什么事有清晰的規(guī)劃，對(duì)外能搞定研發(fā)并建立良好的團(tuán)隊(duì)協(xié)作關(guān)系、能扛事也能搞事(推動(dòng)做事)、建立個(gè)人及團(tuán)隊(duì)整體影響力。

個(gè)人覺得上云后 DBA 的分布也應(yīng)該是橄欖型的，大量的開發(fā)型 DBA 承擔(dān)基建工作，很少量的運(yùn)維型 DBA 仍舊承擔(dān)傳統(tǒng) DBA 的部分工作，DBA 架構(gòu)師來掌控全局。

作者簡(jiǎn)介：

蔡朋@貨拉拉

10年+DBA工作經(jīng)歷曾就職餓了么、螞蟻，現(xiàn)任貨拉拉數(shù)據(jù)庫部門負(fù)責(zé)人，負(fù)責(zé)數(shù)據(jù)庫、緩存，消息隊(duì)列的管理與平臺(tái)研發(fā)工作。