一個公司到底需要幾個 DBA

前段時間某家公司透露自家有 1000 人的 DBA 團隊，一時成為了資料庫圈內討論的焦點。昨天又讀到「DBA團隊的規模應該是什麼樣的配置」。正好到年底了，不少公司也要做新年的預算，其中就包括 HC 的規劃。所以也分享一點想法。

先明確這裡講的 DBA 指的是專職負責資料庫管理的人員，不算還身兼其他職責的人員，也不包括資料庫核心開發人員。

首先 1000 人的 DBA 團隊肯定是言過其實的，這也是當初新聞公佈後，引起大家討論的原因。在我們所居住的藍色星球上，應該還不存在 1000 人規模的 DBA 天團。那麼正常一個公司該養幾個 DBA 比較合適呢?下面就按照公司的發展階段進行闡述。

01、< 30 人 - 不需要 DBA

公司研發人數在 30 人以下規模時是不需要 DBA 的，通常這個階段的職責由團隊裡的後端工程師，DevOps / 平臺工程師或者技術負責人來兼職。這個階段建議無腦選擇雲資料庫託管服務，因為自帶開箱即用的運維，監控，備份。至於資料庫的日常變更，可以引入工具，也可以選擇不引入。如果不引入的話，由技術負責人透過設計評審，程式碼稽核等方式也能應付。

02、30 人 ～ 50 人 - 第一個 DBA 和工具

資料庫相關工作的併發加大，兼職已經很難應付。同時因為業務開始有起色，所以需要為更長期的資料治理做鋪墊。所以這個階段公司就需要考慮引入專門的 DBA 來負責資料庫相關事宜，隨著引入第一個 DBA，也要同時考慮引入相關的資料庫工具，其中最核心的就是涉及研發流程的資料庫變更稽核工具。至於究竟在哪個節點引入，一個是看之前兼職同學處理 DBA 事務的佔比，50% 是一個零界點。另一個是看整個技術團隊高優先順序工作項裡， 是否超過 50% 都是資料庫相關。當然還有一個指標，就是故障數，如果已經連續兩個月發生過影響業務的資料庫故障，那引入 DBA 就是迫在眉睫了。

再說一下引入的第一個 DBA 的定位。通常在這個階段，公司還很難吸引到比較優秀的 DBA，也沒有必要。第一個 DBA 不需要構建體系，只要建立起機制。機制分兩部分，一部分是資料庫運維的常態化，比如最佳化監控，巡檢以及備份。另一部分則是規範資料庫訪問和變更上線的流程。這兩件事情都需要依託工具來落地。前者通常是圍繞雲平臺提供的能力，透過配置或者少量的二開來實現;後者則基本完全依賴於引入工具，業內比較流行的 Archery, Yearning 便是出自 DBA 之手，解決這塊的問題。Bytebase 同樣也是由兼具研發和 DBA 背景的團隊打造的開源產品。

這個階段，也需要研發負責人在一旁做策應。因為引入 DBA 和工具，會限制研發的自由度，而 DBA 和研發的訴求點並不一致，DBA 又是新加入的成員。這個時候需要研發負責人從中斡旋，避免雙方牴觸，產生部門牆。說到底，在這個階段，仍然是業務絕對優先，所以如果研發以業務優先為理由不願意配合，DBA 建立的流程工具都能被繞過。

另一方面研發負責人也要著力培養 DBA 去熟悉業務，幫助他能跟隨公司成長到下一階段。

03、100 人 - 第二個 DBA

通常在研發規模達到百人左右時，就必須引入第二個 DBA。這裡最重要的是能有一個互備。至於引入的 DBA 定位，如果第一個 DBA 成長起來的話，那第二個 DBA 可以是相對初級的，老人帶新人。但如果第一個 DBA 沒有跟上公司的成長，那麼這時就需要引入一個相對資深的 DBA。這個階段要開始構建體系，首先要審視當前使用的資料庫種類，之前業務發展，可能對於資料庫選型並沒有做約束，現在就到了決策資料庫選型的時候，儘可能統一。另外也要審視使用的資料庫工具鏈，是否需要進行替換。關健就是這兩件事情，選對資料庫，選對工具。這也是為什麼需要一個更資深的 DBA，所謂觀千劍而識器。如果是一個相對經驗不足的 DBA，在強勢的業務研發面前，很難據理力爭。這個階段之後，無論是要換資料庫還是相關工具，那都是浩大的工程，絕對比找一個有經驗的 DBA 代價要大。

研發負責人在這個階段算是基本退出了資料庫日常工作，交由這組 DBA 二人轉了。

04、> 200 人 - DBA 團隊

極限操作的話，公司也可以維持 2 個 DBA 的配置很長時間。國內上市公司，千人研發團隊，2 個 DBA 配置也不是個例。但 DBA 人數還是和風險掛鉤的，這裡還是建議按照人員配比，儘量 DBA : 研發的配比不要低於 1:200。業務上了規模後，一個 DBA 但凡一年能幫助公司規避掉一次故障，就能收回人力成本。

另一方面，到這個階段勢必會出現一系列定製化需求，標準工具往往無法全部滿足，所以這個時候也需要 DBA 親自下場做深度二開。

不過在公司研發達到 500 人規模前，也要謹慎控制 DBA 團隊的擴張。DBA 團隊擴充到 5 人後，通常都會走上自研工具鏈的道路，否則無法支撐團隊規模。但這個階段選擇自研道路，往往不會對業務帶來增量。因為自研雖然在某些功能點更貼近業務，但從整體的產品體驗來說，肯定是遠遠不如市面上成熟的標品，此消彼長。

那該如何給 DBA 團隊尤其是 DBA 團隊負責人提供成長空間呢。這裡有兩條路徑，一是培養 DBA 負責人去超越 DBA 的職能，往職責更大的儲存負責人/基礎設施負責人方向走;另一條路，是鼓勵 DBA 負責人走出公司，在行業內建立起影響力。

總之就是避免讓 DBA 團隊自己往前走的太快。雖然資料庫在整個研發鏈路裡是一塊基石，但它不是樞紐。自研資料庫工具鏈的時機，是要配合公司整體研發平臺的自研規劃，而且通常是在整體研發平臺自研規劃基本確立後，再進行資料庫相關的規劃。

05、> 1000 人 - 中央和地方

能走到這步，公司往往已經形成了 BU 編制，這就會牽扯到是否每個 BU 會自建 DBA 團隊。這通常就不再是技術問題，而是組織問題了。一個強勢的業務 BU 通常都會希望可以有獨立的建制，但是往往自己執行一段時間後，又發現招不到/留不住人，然後即使名義上還是獨立，實際還是回退到中央集權。國內幾家大廠有中央集權的，也有地方自治的。到了這個階段兵無常勢，水無常形。

06、如何評估 DBA 團隊的績效

兩句話：

• 專業的人做專業的事

• 善戰者無赫赫之功

地鐵在既定的軌道上執行，依然也還是要配備 2 名駕駛員。事前預防，事中止血，事後補救，目前圍繞資料庫的日常工作，無論是雲平臺還是第三方工具，還只能承擔 co-pilot 的角色，最終還需要 DBA 拍板。希望每個研發都具備資料庫常識的理想很豐滿，但現實很骨感。面試時雖然都考察了 MVCC 原理的八股文，但真的上了前線，往往連最基本的執行計劃也看不懂。

07、總結

新的一年也希望 DBA 們穩如泰山，資料庫都平平安安。

作者：陳天舟，Bytebase聯合創始人&CEO。