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

從近3年對云實際使用經驗看，在人員與業務體量小一點的公司對開發&運維&安全標準規范都沒有嚴格要求跟約束的情況下是適用的，但是體量稍微大一點就玩不轉了，尤其混合云的環境下依靠云商能力是很難解決自身個性化的需求的。尤其體系化建設是無法依靠堆“云產品積木”的方式去構建。

什么是體系化建設

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

接下來簡單介紹一下貨拉拉圍繞上述三點進行的相關能力建設。

穩定性

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

數據庫上云穩定性并不能做到5個9，云只是解決了基礎設施的管理問題，過去DBA在基礎設施上投入大量的精力主要就是保障基礎設施的穩定性，這么看上云確實能提高基礎設施的穩定性保障水平。但是如何在應用層面保障數據庫穩定性是不在云商保障范疇內的。

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

MySQL

SQL事前發現

通過對預發環境的 SQL 旁路然后將旁路結果對歷史記錄進行對比就可以很容易發現每天DB新增了那些慢、危險SQL，然后及時地預警給測試跟研發同學進行優化改造。同時與發布系統打通進行卡口、未優化完成的 APPID 禁止發布，起到攔截作用。

SQL 旁路的前提條件：接入貨拉拉自研的數據庫中間件、該中間件覆蓋了所有云 RDS，基于中間件將各個環境的全量 SQL 旁路且分發到 Kafka 供數據庫管理系統 DMS 進行消費處理，每天處理消息量達100億，單純消息分析處理能力對 DBA 就有一定的考驗。

SQL事中兜底

如何無差別防范任何 SQL 在任何場景下擊穿數據庫？一方面數據庫中間件會實時感知數據庫RT情況，一但RT整體響應異常則啟動限流功能，或者 DBA 可以主動介入熔斷、限流特定 SQL，甚至可以干擾執行計劃做到走特定索引的功能。

同時 DMS 自愈系統會實時感知數據庫 processlist 列表是否有堆積或者長查詢，自愈系統會根據規則進行查殺動作，比如 CPU/IO 異常、SQL 執行時間超過規定時間、processlist 列表堆積、鎖等待、連接數超警戒水位等。自愈系統要跟監控系統進行配合才能做到實時的感知能力，這也是需要進行個性化建設的。

可以看到該保障能力建設落地后，我們數據庫 thread_running/processlist 列表堆積超過30（云上普遍都是4-8C這樣的小規格活躍SQL數定在30相對合適的）的實例比例都不到1%（監控只要發現一次就視為異常），日常基于該指標就可以比較直觀的評估最近一段時間數據庫穩定情況了。

SQL事后治理

研發可以基于 DMS 系統獲取到對應的慢查詢趨勢跟詳情信息，方便研發進行日常優化治理。當然也需要一些系統外的機制保障研發是在不斷治理的，整個 SQL 防控、兜底、治理就算閉環了。

可以看到高危慢查詢萬分率常態化下都在萬分之一附近波動。

圍繞 SQL 治理我們甚至做了一個類似阿里云的 SQL 洞察的功能，一方面兼容當前所有云產品其次其他云也不具備該功能而且即使有也不便宜！！

SQL發布變更

其次威脅穩定性的來源就是日常數據庫的發布變更了。發布主要解決3個方面的問題。

1、SQL規范

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

2、變更安全

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

3、成功率保障

貨拉拉是家快速成長的公司，每天數據庫變更量日均在600+，因此發布的效率跟成功率是很重要的，效率上我們發布系統會自動識別部署架構比如阿里云我們由于大量使用分庫分表很多集群是沒有 slave 節點的或者有 slave 節點單不參與 online 業務，對 gh-ost修改后會自動優化相關 hook 函數保證 DDL 效率優先。

為應對大規模發布我們發布系統被設計成分布式可以輕松擴容的，當發布能力不足時加幾個 agent 節點就可以了，理論上我們能應對任何突發大量規模發布。

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

Redis

對 Redis 穩定性威脅最大的無非就大key、熱key了。

大key、熱key防御

貨拉拉在發展初期PHP是主流，后續不同團隊又引入了其他開發語言，由于我們目前采用的是統一Cluster架構，很多語言再對Cluster協議上支持的不夠完善，最常見的問題就是集群節點發生調整會導致業務端長時間感知不到底層變化業務持續性故障，還有就是PHP短連接等問題，因此我們設計了一套代理來解決多語言的問題。

對PHP短連接服務實現短鏈變長鏈，由于是 sidecar 部署模式引用到 mesh 層的網絡開銷就比較小，應用RT與Redis節點CPU分別下了40%、60%。

對大key、熱key也有了更好的應對方案，比如對大key限流/block訪問，大key導致的危害一下就解決了，比如下圖因大key導致的網絡流量異常限流效果立竿見影。

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

Kafka

Kafka 本身其實是比較穩定的，但是對業務而言穩定性風險主要來自自身消費延遲感知問題，過去研發普遍會在消費系統里面埋點以此來感知消費延遲情況，但是實際效果上效果不是太理想，主要原因在于現在的延遲度量方式都是以 lags 這維度的，是比較抽象的。

延遲發現

基于時間維度的延遲度量是更直觀的，對研發更加友好。我們設計了兩個獨立方式：

該方式比較簡單由于要消費消息取時間戳因此效率非常低，但是比較準確。

該方式不需要消費消息效率非常高，準確度略差。

新的延遲度量有效解決研發對延遲度量上的焦慮，研發可以通過系統比較簡單的配置就可以訂閱消費延遲告警，也不需要再系統內進行埋點。

資源/故障隔離

實際運維過程中來自 Kafka 本身的故障非常少，日常穩定性問題主要集中在諸如網絡、磁盤異常導致的整體業務抖動，以及在防范一些 topic 生產或者消費導致的資源嚴重占用造成的相互響應問題。針對這個問題 DMS 系統設計了一個租戶的概念，DMS 對集群broker 節點進行編組構成一個 Zone，創建 topic 時將 topic 指定到特定 Zone，實際創建時通過 go-sarama 接口將 topic 指定到特定機器（Zone），如下圖：

這樣設計的好處是實現資源隔離的目的、故障隔離的目的。比如某個Zone的機器異常不會影響其整體，同時對于單個Topic讀寫過大導致的資源占用也能很好的應對，同時還解決了Topic自由調度的問題，比如可以將一個小規格Topic遷移到大的Zone內，過程是對業務無感的也不用換鏈接地址。最后對提高資源利用率有很好的作用，因為不同Zone用的機器規格可能是不同的，日常擴縮容可以精確到Zone，避免集群整體擴容造成的浪費及業務影響。

ES、MQ

篇幅原因不一一介紹了。

賦能運維&研發效率

1、賦能 DBA

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

站在DBA跟研發的角度看都有共同的訴求：通過一個入口一個平臺搞定所有日常運維需求+研發所有需求，因為站點、環境、選型太多了，先不論云上是否提供了類似能力，即使有對于一個上千人的研發團隊也是極其低效的。因此一套大一統的系統架構是必要的。

對DBA而言無非就是通過系統將日常工作自動化掉，且在一套系統上完成。

整體對DBA而言日常90%以上的工作可以借助平臺完成。

2、賦能研發

對研發而言無外乎就是資源申請、發布、告警訂閱、變更、安全等自助化服務，這些由于內嵌了公司的很多流程、SOP 這一點云商 PaaS 是很難解決的。

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

科學合理的資源使用

成本治理大致兩個手段：運維手段進行資源治理、技術手段進行資源合理利用。

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

MySQL

由于云是規格整體是偏小的應對突發異常的情況是比較弱的，我們將數據庫拆分的比較細因此我們下掉了大部分slave節點。

經典存算一體架構下存儲與計算是存在綁定關系的，不管是云上還是自建都會存在這樣的關系，比如在云上你要買3T的存儲你的CPU都不能低于8C，或者你要買一個16C算力你的存儲不能少于3TB，這就會出現算力與存儲不匹配的問題，造成算力跟存儲的浪費。自建IDC下尤其如此 因為方便統一運維與硬件采購可能所有數據庫服務器的規格配置是一致的這個浪費更加明，搞過自建的同學應該深有體會。今天我們可以充分利用云的能力來最大程度的提升我們的資源利用率加上我們自建能力及云的能力實現既便宜又好用。后續ServerLess架構成熟后相信成本控制上會有更豐富的手段。

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

Kafka

基于前面介紹的多租戶的方式、不同場景使用不同配置的租戶，不同租戶內實現定向擴縮容，能有效的避免Topic間資源分布不均導致的資源浪費。

Kafka歷史上為應對突發消息暴漲我們規定了存儲使用超過50%可能就要擴容了，當前的磁盤、CPU平均使用率還是比較高的。

我對DBA的理解

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

個人覺得上云后 DBA 的分布也應該是橄欖型的，大量的開發型 DBA 承擔基建工作，很少量的運維型 DBA 仍舊承擔傳統 DBA 的部分工作，DBA 架構師來掌控全局。

作者簡介：

蔡朋@貨拉拉

10年+DBA工作經歷曾就職餓了么、螞蟻，現任貨拉拉數據庫部門負責人，負責數據庫、緩存，消息隊列的管理與平臺研發工作。