一个公司到底需要几个 DBA

原创
2023/12/27 11:49
阅读数 2.3K

前段时间某家公司透露自家有 1000 人的 DBA 团队,一时成为了数据库圈内讨论的焦点。昨天又读到「DBA 团队的规模应该是什么样的配置」。正好到年底了,不少公司也要做新年的预算,其中就包括 HC 的规划。所以也分享一点想法。

先明确这里讲的 DBA 指的是专职负责数据库管理的人员,不算还身兼其他职责的人员,也不包括数据库内核开发人员。

首先 1000 人的 DBA 团队肯定是言过其实的,这也是当初新闻公布后,引起大家讨论的原因。在我们所居住的蓝色星球上,应该还不存在 1000 人规模的 DBA 天团。那么正常一个公司该养几个 DBA 比较合适呢?下面就按照公司的发展阶段进行阐述。

< 30 人 - 不需要 DBA

公司研发人数在 30 人以下规模时是不需要 DBA 的,通常这个阶段的职责由团队里的后端工程师,DevOps / 平台工程师或者技术负责人来兼职。这个阶段建议无脑选择云数据库托管服务,因为自带开箱即用的运维,监控,备份。至于数据库的日常变更,可以引入工具,也可以选择不引入。如果不引入的话,由技术负责人通过设计评审,代码审核等方式也能应付。

30 人 ~ 50 人 - 第一个 DBA 和工具

数据库相关工作的并发加大,兼职已经很难应付。同时因为业务开始有起色,所以需要为更长期的数据治理做铺垫。所以这个阶段公司就需要考虑引入专门的 DBA 来负责数据库相关事宜,随着引入第一个 DBA,也要同时考虑引入相关的数据库工具,其中最核心的就是涉及研发流程的数据库变更审核工具。至于究竟在哪个节点引入,一个是看之前兼职同学处理 DBA 事务的占比,50% 是一个零界点。另一个是看整个技术团队高优先级工作项里, 是否超过 50% 都是数据库相关。当然还有一个指标,就是故障数,如果已经连续两个月发生过影响业务的数据库故障,那引入 DBA 就是迫在眉睫了。

再说一下引入的第一个 DBA 的定位。通常在这个阶段,公司还很难吸引到比较优秀的 DBA,也没有必要。第一个 DBA 不需要构建体系,只要建立起机制。机制分两部分,一部分是数据库运维的常态化,比如优化监控,巡检以及备份。另一部分则是规范数据库访问和变更上线的流程。这两件事情都需要依托工具来落地。前者通常是围绕云平台提供的能力,通过配置或者少量的二开来实现;后者则基本完全依赖于引入工具,业内比较流行的 Archery, Yearning 便是出自 DBA 之手,解决这块的问题。Bytebase 同样也是由兼具研发和 DBA 背景的团队打造的开源产品。

这个阶段,也需要研发负责人在一旁做策应。因为引入 DBA 和工具,会限制研发的自由度,而 DBA 和研发的诉求点并不一致,DBA 又是新加入的成员。这个时候需要研发负责人从中斡旋,避免双方抵触,产生部门墙。说到底,在这个阶段,仍然是业务绝对优先,所以如果研发以业务优先为理由不愿意配合,DBA 建立的流程工具都能被绕过。

另一方面研发负责人也要着力培养 DBA 去熟悉业务,帮助他能跟随公司成长到下一阶段。

100 人 - 第二个 DBA

通常在研发规模达到百人左右时,就必须引入第二个 DBA。这里最重要的是能有一个互备。至于引入的 DBA 定位,如果第一个 DBA 成长起来的话,那第二个 DBA 可以是相对初级的,老人带新人。但如果第一个 DBA 没有跟上公司的成长,那么这时就需要引入一个相对资深的 DBA。这个阶段要开始构建体系,首先要审视当前使用的数据库种类,之前业务发展,可能对于数据库选型并没有做约束,现在就到了决策数据库选型的时候,尽可能统一。另外也要审视使用的数据库工具链,是否需要进行替换。关健就是这两件事情,选对数据库,选对工具。这也是为什么需要一个更资深的 DBA,所谓观千剑而识器。如果是一个相对经验不足的 DBA,在强势的业务研发面前,很难据理力争。这个阶段之后,无论是要换数据库还是相关工具,那都是浩大的工程,绝对比找一个有经验的 DBA 代价要大。

研发负责人在这个阶段算是基本退出了数据库日常工作,交由这组 DBA 二人转了。

> 200 人 - DBA 团队

极限操作的话,公司也可以维持 2 个 DBA 的配置很长时间。国内上市公司,千人研发团队,2 个 DBA 配置也不是个例。但 DBA 人数还是和风险挂钩的,这里还是建议按照人员配比,尽量 DBA : 研发的配比不要低于 1:200。业务上了规模后,一个 DBA 但凡一年能帮助公司规避掉一次故障,就能收回人力成本。

另一方面,到这个阶段势必会出现一系列定制化需求,标准工具往往无法全部满足,所以这个时候也需要 DBA 亲自下场做深度二开。

不过在公司研发达到 500 人规模前,也要谨慎控制 DBA 团队的扩张。DBA 团队扩充到 5 人后,通常都会走上自研工具链的道路,否则无法支撑团队规模。但这个阶段选择自研道路,往往不会对业务带来增量。因为自研虽然在某些功能点更贴近业务,但从整体的产品体验来说,肯定是远远不如市面上成熟的标品,此消彼长。

那该如何给 DBA 团队尤其是 DBA 团队负责人提供成长空间呢。这里有两条路径,一是培养 DBA 负责人去超越 DBA 的职能,往职责更大的存储负责人/基础设施负责人方向走;另一条路,是鼓励 DBA 负责人走出公司,在行业内建立起影响力。

总之就是避免让 DBA 团队自己往前走的太快。虽然数据库在整个研发链路里是一块基石,但它不是枢纽。自研数据库工具链的时机,是要配合公司整体研发平台的自研规划,而且通常是在整体研发平台自研规划基本确立后,再进行数据库相关的规划。

> 1000 人 - 中央和地方

能走到这步,公司往往已经形成了 BU 编制,这就会牵扯到是否每个 BU 会自建 DBA 团队。这通常就不再是技术问题,而是组织问题了。一个强势的业务 BU 通常都会希望可以有独立的建制,但是往往自己运行一段时间后,又发现招不到/留不住人,然后即使名义上还是独立,实际还是回退到中央集权。国内几家大厂有中央集权的,也有地方自治的。到了这个阶段兵无常势,水无常形。

如何评估 DBA 团队的绩效

两句话:

  • 专业的人做专业的事
  • 善战者无赫赫之功

地铁在既定的轨道上运行,依然也还是要配备 2 名驾驶员。事前预防,事中止血,事后补救,目前围绕数据库的日常工作,无论是云平台还是第三方工具,还只能承担 co-pilot 的角色,最终还需要 DBA 拍板。希望每个研发都具备数据库常识的理想很丰满,但现实很骨感。面试时虽然都考察了 MVCC 原理的八股文,但真的上了前线,往往连最基本的执行计划也看不懂。

总结

file

新的一年也希望 DBA 们稳如泰山,数据库都平平安安。

file


💡 更多资讯,请关注 Bytebase 公号:Bytebase

展开阅读全文
加载中
点击加入讨论🔥(10) 发布并加入讨论🔥
打赏
10 评论
10 收藏
0
分享
返回顶部
顶部