駁《再論為什麼你不應該招DBA》

郭德綱有一段相聲：比如我和火箭專家說，你那火箭不行，燃料不好，我認為得燒柴，最好是燒煤，煤還得精選煤，水洗煤不行。如果那科學家拿正眼看我一眼，那他就輸了。

但不管怎麼說，馬工也還是一位體面的瑞典研發工程師。沒有做過DBA就敢大放厥詞，開地圖炮拉仇恨，實在勇氣可嘉。之前在《你怎麼還在招聘DBA》，以及回應文《雲資料庫是不是智商稅》中，我們便已交鋒過。

當別人把屎盆子扣在這個行業所有人頭上時，還是需要人來站出來說幾句的。因此今天特此撰文以駁斥馬工的謬論：《再論為什麼你不應該招DBA》。

馬工的論點有三：

1. DBA妨礙了研發交付新特性

1. DBA威脅了企業資料安全

1. 人工DBA需要被基於程式碼的軟體所取代

我的看法是：

第一點屬於無效輸出，DBA本來就是在穩定性側制衡研發的存在。

第二點則是完全扯淡，DBA本來就是類似於財務的關健崗位，需要信任。

第三點屬於部分事實，但嚴重高估了短期變化，且雲資料庫並非唯一的路。

且聽我一一道來：

DBA 對穩定性負責

關於資訊系統的一個基本原理是：安全性與活性相互牴觸，過於強調安全穩定，則活性受損；過於強調活性，則難以穩定。任何組織都要在兩者中間找到一個平衡點。而研發與運維，就是兩者的職能化身。

研發對新功負責，而 SRE/DBA 對穩定性負責，一個開創，一個守成，兩者相互協作，但也是相互制衡。馬工作為研發，特別還是創業公司的研發，主張功能活性很重要，從立場上來說是無可厚非的。但在更廣大的組織中，穩定性的地位往往是高於新功能的，成熟的組織如銀行，大型網際網路平臺，從來都是穩定性壓倒一切。畢竟，新功能的收益是不確定的，而大故障的損失是肉眼可見的。每天發10個新版本不見得能帶來多少增長，但一次大故障也許就能讓幾個月的努力付之東流。

“在高速上開兩百邁的阻礙從來都不是車的效能，而是司機的膽量”。站在更高位的管理者角度來說，馬工強調的 “開掉DBA得到更快的DB交付速度”，純粹屬於研發者的一廂情願：用雲把運維職能外包出去， 無人制衡，我想怎樣就怎樣。這樣的想法如果落地，最終必將在某個時刻以慘痛的教訓收場。

筆者曾是 DBA，但也沒少幹  Dev。關於研發和 DBA 的心態，都有親身的體會。我在剛入行當研發的時候，在“PostgreSQL資料庫裡”跑神經網路，推薦系統，Web伺服器和爬蟲，用FDW接了 MongoDB 和 HBase以及一堆外部系統，什麼穩定性？跑的不是挺好嗎？直到沒有運維與DBA願意接手維護，我不得不親自幹起了 DBA 的活自己狗食背起鍋來，才能設身處地的對DBA / 運維有同理心，謹慎選擇有所為有所不為。

交付速度誰在乎？

評價一款資料庫需要從許多維度出發：穩定性，可靠性，安全性，簡單性，可伸縮性，可擴充套件性，可觀測性，可維護性，成本價效比，等等等等。交付速度這件事勉強屬於“可伸縮性”裡一個比較次要的附屬維度，在資料庫系統需要關注的屬性中，壓根排不上號。

更重要的是，價效比才是第一產品力，對比方案卻對成本閉而不提，是一種耍流氓的行為。筆者對研發人員的這種心理非常瞭解：花的是公司的錢，省的是自己事兒，自然沒有幾個人會有動機為公司去省錢。你的資料庫花半個小時交付，還是花三四天交付，老闆與領導不會 Care 這些。但是，你的老闆會很在乎你花30分鐘拉起了一個資料庫，然後每個月賬單多出來幾十萬元。

以 AWS 上 64核256GB的 db.m5.16xlarge RDS 為例，用一個月價格 $25,817 / 月，摺合約 18 萬元人民幣，一個月的租金，夠你把兩臺效能比這還要好的多得多的伺服器直接買下來了，任何理智的企業使用者都看得明白這裡面的道理：如果採購這種服務不是為了短期的，臨時性的需求，那麼絕對算得上是重大的財務失當行為。

比交付速度也不怵

但即使我們退一萬步講，交付速度真的重要，馬工的論證用例也是破綻百出。

馬工假想了一個資料庫上線的案例：PG新版本，兩地三中心，同城HA，異地災備，資料加密，自動備份，自帶監控，App與DB獨立網段，DBA也無法刪庫。然後得意洋洋的宣稱：”使用 Terraform，我只要28分鐘就可以完成滿足需要的配置！比拉DBA搭建資料庫快幾個數量級！“

實際上只要你的機器就緒，網路打通，規劃完畢：使用 Pigsty 部署一套滿足這些需求的資料庫系統，執行耗時也就是十幾分鍾。自建機房且不提，Pigsty 完全可以使用同樣的邏輯：基於Terraform 一鍵拉起EC2、儲存、網路，然後在這個基礎上額外執行一條命令部署資料庫。（），耗費的時間說不定比 Terraform 還短一點，更重要的是，還能省掉百分之八九十的天價 RDS 智商稅。

能想出這種定價的雲資料庫產品經理腦袋一定被門夾了

分庫分表的稻草人靶子

馬工提出，分庫分表是DBA自抬身價的一種工具。

在今天，資料庫的能力已經得到了極大的發展，給應用開發者帶來巨大管理成本的分庫分表已經沒必要了。凡是在用分庫分表的系統， 都可以用分散式資料庫或者NoSQL資料庫替換掉。幾乎可以說，分庫分表不過是DBA自抬身價的一種工具。

時至今日，硬體儲存技術的發展已經讓很多老同志跟不上新形勢了。家用 PCI-E NVME SSD 2TB的價格已經進入了三位數，常用的企業級 3.2TB MLC NVME SSD也不過六七千，最大幾十TB的單卡容量，已經完爆了很多中大型企業的所有 TB 資料量，七位數的IOPS讓幾千/幾萬IOPS還賣天價的 雲 EBS 恨不得找個地縫鑽進去。

軟體方面，以 PostgreSQL 為例，使用堆表儲存的單表容量十幾TB千億量級資料一點兒不成問題，還有 Citus 外掛可以原地改造為分散式資料庫。各種分散式資料庫的賣點也是 “不用分庫分表”。這都已經是老黃曆問題了。除了極個別場景，恐怕也只有原教旨 MySQL 使用者還守著 “單表不能超過 2000w 記錄” 去玩分表了。

當然，分散式資料庫對於 DBA 的水平要求不會更低只會更高；所以這裡馬工主要想說的還是 NoSQL ，更具體的講，就是 DynamoDB 這種所謂“不需要” DBA運維的資料庫直接幹翻 DBA。不過，一個平均延遲在 10ms 的資料庫，一個抽象程度只是等同於檔案系統的扁平 KV 儲存的資料庫，光是殺豬程度要比 RDS 還要狠毒的 RCU / WCU 計費方式，就足夠使用者喝上一壺，有何德何能敢標榜自己能替掉 DBA ？

指望用NoSQL替代DBA是做夢

網際網路應用大多屬於資料密集型應用，對於真實世界的資料密集型應用而言，除非你準備從基礎元件的輪子造起，不然根本沒那麼多機會去擺弄花哨的資料結構和演算法。實際生產中，資料表就是資料結構，索引與查詢就是演算法。而應用研發寫的程式碼往往扮演的是膠水的角色，處理IO與業務邏輯，其他大部分工作都是在資料系統之間搬運資料。

在最寬泛的意義上，有狀態的地方就有資料庫。它無所不在，網站的背後、應用的內部，單機軟體，區塊鏈裡。有。關係型資料庫只是資料系統的冰山一角（或者說冰山之巔），實際上存在著各種各樣的資料系統元件：

• 資料庫：儲存資料，以便自己或其他應用程式之後能再次找到（PostgreSQL，MySQL，Oracle）

• 快取：記住開銷昂貴操作的結果，加快讀取速度（Redis，Memcached）

• 搜尋索引：允許使用者按關鍵字搜尋資料，或以各種方式對資料進行過濾（ElasticSearch）

• 流處理：向其他程式傳送訊息，進行非同步處理（Kafka，Flink，Storm）

• 批處理：定期處理累積的大批次資料（Hadoop）

狀態管理是資訊系統的永恆問題，馬工以為的 DBA 是抱著祖傳 Oracle 手冊的打字員，實際上網際網路公司的 DBA 已經是十八班武藝樣樣精通的 資料架構師 了。架構師最重要的能力之一，就是了解這些元件的效能特點與應用場景，能夠靈活地權衡取捨、整合拼接這些資料系統。 他們上要 Push 業務落地最佳實踐指導模式設計，下要深入作業系統與硬體排查問題最佳化效能，中間要掌握無數種資料元件的使用方式。君子不器，關係型資料庫的知識，只是其中最為核心重要的一種。

正如我在《為什麼要學習資料庫原理和設計》所說， 只會寫程式碼的是碼農；學好資料庫，基本能混口飯吃；在此基礎上再學好作業系統和計算機網路，就能當一個不錯的程式設計師。可惜的是，資料建模和SQL幾乎快成為一門失傳的藝術：這類基礎知識逐漸為新一代工程師遺忘，他們設計出離譜的模式，不懂得正確地建立索引，然後草率得出結論：關係型資料庫和SQL都是垃圾，我們必須使用糙猛快的NoSQL來省時間。然而人們總是需要可靠的系統來處理關鍵業務資料：在許多企業中，核心資料仍然是一個常規關係型資料庫作為Source of Truth，NoSQL資料庫僅用於非關鍵資料。某個研發跳出來說 DynamoDB / Redis / MongoDB / HBase 太牛逼了，我所有的狀態都能放在這裡，而且再也不需要 DBA 了，毫無疑問是滑稽可笑的。

DBA 是企業資料庫的守護者

馬工的最後一炮，直指 DBA 的職業道德 ：DBA想刪庫，誰也攔不住。

這話倒是沒有錯，DBA和財務一樣，都屬於能對企業造成致命殺傷的關鍵崗位：用人不疑，疑人不用。但這句話同樣也繞開了一個重要事實：沒有DBA守門，人人都能刪庫。在馬工舉的微盟和百度刪庫跑路的兩個例子中，主犯都是普通的研發與運維人員，正是因為沒有稱職的 DBA 把關，才有刪庫跑路的可趁之機。

合格的 DBA 可以有效減少有能力對企業進行致命一擊的人群範圍，從所有的研發與運維收斂到DBA本身。至於 DBA 本身如何制衡，要麼是兩個 DBA 互為備份，要麼是由運維/安全團隊管理冷備份的刪除許可權。馬工舉的，騰訊雲不讓手工刪例行備份的例子，實屬對業內實踐少見多怪。

對於給 DBA 群體潑髒水的行為，本人表示鄙視憤慨 ?。按照這個邏輯，我也完全可以認為馬工喜愛的公有云廠商，才是對資料安全最大的威脅：用雲不過是把運維和DBA外包給了雲廠商，而你完全阻礙不了某個雲廠商中有許可權的研發/運維/DBA，在心血來潮的情況下來你的庫裡裡逛逛。或者乾脆脫個備份褲子賞玩一下，你壓根不可能追索，不可能取證，當然核心原因是你壓根沒有能力知道這一點。而這樣的人許許多多，一個運維的指令碼出岔子就會爆破一大片，你能指望的賠償也只有不痛不癢的時長代金券。

參考閱讀：《雲RDS：從刪庫到跑路》

DBA要退出歷史舞臺？

作為一個整體行業， DBA 確實在走下坡路， 但人們總是會過高估短期影響而低估長期趨勢。許多大型組織都僱用DBA，DBA類似於 Cobol 程式設計師，那些聽上去不那麼Fancy的製造業，銀行保險證券、以及大量執行本地軟體的黨政軍部門，大量使用了關係型資料庫。在可預見的未來，DBA在某個地方找工作是不會有什麼問題的。

但大的趨勢是，資料庫本身會越來越智慧，易用性越來越好，而各式各樣的工具、SaaS、PaaS不斷湧出，也會進一步壓低資料庫的使用門檻。公有云/私有云DBasS的出現更是讓資料庫的管理門檻進一步下降。資料庫的專業技術門檻降低，將導致DBA的不可替代性降低：安裝一套軟體收費十幾萬，做一次資料恢復上百萬的好日子肯定是一去不復返了。但在另一種意義上講，這也將 DBA 從運維性的瑣事中解放出來，他們可以把更多時間投身於更有價值的效能最佳化，隱患排查，制度建設工作之中。

無論是公有云廠商，還是以Kubernetes為代表的雲原生/私有云，其核心價值都在於儘可能多地使用軟體，而不是人來應對系統複雜度。但是不要指望這些能完全替代 DBA：雲並不是什麼都不用管的運維外包魔法。根據複雜度守恆定律，無論是系統管理員還是資料庫管理員，管理員這個崗位消失的唯一方式是，它們被重新命名為“DevOps Engineer”或SRE/DRE。好的雲軟體可以幫你遮蔽運維雜活，解決70%的日常高頻問題，然而總是會有那麼一些複雜問題只有人才能處理。你可能需要更少的人手來打理這些雲軟體，但總歸還是需要人來管理。畢竟：

你也需要懂行的人來協調處理，才不至於被雲廠商嘎嘎割韭菜當傻逼。

題外話：有那麼一些研發，總想著透過雲這種運維外包外援，用雲資料庫，雲XX砸掉 DBA 的飯碗。我們做了一個開箱即用的 雲資料庫 RDS PostgreSQL 本地開源替代 Pigsty ，最近剛釋出了 2.0，監控/資料庫開箱即用 HA/PITR/IaC一應俱全。允許您在缺乏資料庫專家的情況下，用接近硬體的成本執行企業級資料庫服務，省掉50%～90%上貢給RDS的“無專家稅”，讓 RDS 除了它引以為傲的彈性，在各個方面都像是一個大笑話。對於廣大 DBA 來說，這就是一件懟回去的武器。我們們明人不說暗話，就是要砸了雲資料庫的飯碗，並斷了研發的這種痴念。

最後，讓我們用某個 Notion AI 生成的無版權提詞小笑話結束今天的主題。