昨天读到「DBA团队的规模应该是什么样的配置」的一些相关文章，正好到年底了，不少公司也要做新年的预算，其中就包括 HC 的规划。所以也分享一点想法。

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

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

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

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

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

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

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

通常在研发规模达到百人左右时，就必须引入第二个 DBA。这里最重要的是能有一个互备。至于引入的 DBA 定位，如果第一个 DBA 成长起来的话，那第二个 DBA 可以是相对初级的，老人带新人。但如果第一个 DBA 没有跟上公司的成长，那么这时就需要引入一个相对资深的 DBA。这个阶段要开始构建体系，首先要审视当前使用的数据库种类，之前业务发展，可能对于数据库选型并没有做约束，现在就到了决策数据库选型的时候，尽可能统一。

另外也要审视使用的数据库工具链，是否需要进行替换。关键就是这两件事情，选对数据库，选对工具。这也是为什么需要一个更资深的 DBA，所谓观千剑而识器。如果是一个相对经验不足的 DBA，在强势的业务研发面前，很难据理力争。这个阶段之后，无论是要换数据库还是相关工具，那都是浩大的工程，绝对比找一个有经验的 DBA 代价要大。

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

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

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

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

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

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

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

两句话：

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

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