一个技术团队应该配几个 DBA ？

数据与人 2024-04-01

412

将 "数据与人" 设为 "星标⭐"

第一时间收到文章更新

又听到了开发小哥抱怨 DBA 不够，应该一人配一个...

借此，我想分享一些关于数据库管理员（DBA）配置的想法。

事先说明：这里所指的DBA是专门负责数据库管理的人员，不包括那些同时承担其他职责的人员，以及数据库内核开发人员。

那么，一个公司应该配置多少 DBA 呢？这实际上取决于公司的发展阶段。

< 30人 - 或许不需要 DBA

公司研发人数在 30 人以下规模时或许是不需要 DBA 的，开发工程师，后端工程师，DevOps 平台工程师或者技术负责人都会懂一些数据库相关的维护。

云数据库技术也很成熟，可以选择数据库托管服务，自带开箱即用的运维，监控，备份等功能。

至于数据库的日常变更，体量预计不会太大，可以引入工具，也可以选择不引入。如果不引入的话，由技术负责人通过设计评审，代码审核等方式也能应付。

< 30 ~ 50 人 - DBA 1 人

随着公司业务的发展，数据库的并发处理需求日益加大，兼职DBA已难以应对。为确保数据库的长期稳定运行，公司应考虑引入专职DBA来全面负责数据库管理。

在决定引入的第一个阶段，应综合考虑多个因素：若兼职DBA处理的事务中，有超过50%与数据库相关，或技术团队的高优先级任务中，数据库工作占比超过50%，或连续两个月发生影响业务的数据库故障，那么引入专职DBA便显得尤为迫切。

对于这位即将加入的DBA，其角色定位至关重要。在此阶段，公司可能难以吸引顶尖的DBA人才，因此，首要的并非构建完整的数据库管理体系，而是确立一套行之有效的工作机制。

这包括两个方面：

一是实现数据库运维的常态化，如优化监控、定期巡检以及确保数据备份的可靠性；
二是规范数据库的访问权限和变更上线流程。

这两大任务的实施，均需要借助专业工具来完成。

前者可以借助云平台提供的功能，通过配置或简单的二次开发来实现；后者则更依赖于引入的专门工具，这些工具能够帮助解决数据库变更审核等核心问题。

在此过程中，研发团队的配合与支持至关重要。由于引入DBA和相应工具可能会对研发工作产生一定的限制，而DBA与研发团队的诉求并不总是完全一致，因此，研发团队负责人需要发挥桥梁作用，确保双方之间的顺畅沟通，避免产生不必要的摩擦和部门壁垒。

最终，业务始终是公司的核心，如果研发团队以业务优先为由拒绝配合，那么DBA建立的流程和工具可能会受到挑战。同时，研发团队负责人也需积极培养DBA对业务的了解，助力其与公司共同成长，迈向下一阶段。

100 ~ 150 人 - DBA 2 ~ 3 人

当研发团队规模扩张至约百名成员时，为了保障系统的稳定运营和高效维护，应当引入第二位数据库管理员（DBA）。

这一举措的核心在于构建互为备份的工作模式。关于新引入的DBA的角色定位，若首位DBA已具备丰富的经验，那么第二位可以是初级水平的，形成“以老带新”的协作模式。反之，若首位DBA未能跟上公司的发展步伐，则需引进具备更高资历的DBA。

在这一阶段，构建稳固的数据库管理体系至关重要。首先，要对当前使用的数据库类型进行全面审视，随着业务的不断扩展，过去对数据库的选择可能并未经过深思熟虑，此时便需做出明智的决策，力求实现数据库的统一管理。同时，对现有数据库工具链的评估也不可或缺，考虑是否需要进行替换或升级。

选择适合的数据库和工具是这一阶段的关键任务，这需要具备丰富经验和深厚专业知识的DBA来把关。缺乏经验的DBA在面对复杂多变的业务需求时，可能难以做出明智的决策。而一旦决定了数据库和工具的更换，所需投入的人力、物力和时间成本将极为庞大，远超过引进一位资深DBA的代价。

在这一阶段完成后，研发负责人可以逐渐从数据库的日常管理工作中解脱出来，将重任交给这组DBA团队来承担。

> 150 人 - DBA 团队

在极限情况下，即便公司规模持续扩大，维持两到三名DBA的配置也是可行的，这在国内上市的千人研发团队中并不罕见。

然而，DBA的人数与风险是息息相关的，因此建议按照人员配比，尽量使DBA与研发人员的比例不低于1:200。

当业务规模扩大后，只要一个DBA每年能成功避免一次重大故障，其所创造的价值就能完全覆盖其人力成本。

随着业务的发展，定制化的需求会越来越多，这时标准的数据库工具可能无法满足所有需求，DBA需要亲自参与深度二次开发。

但在公司研发团队达到500人之前，DBA团队的扩张应当谨慎。一旦DBA团队规模达到5人，通常会考虑自研工具链以支撑更大的团队规模。

然而，在这个阶段选择自研往往不会给业务带来明显的增量，因为尽管自研在某些功能点上可能更符合业务需求，但从整体产品体验来看，通常不如市场上成熟的标准产品。

对于DBA团队，尤其是团队负责人，提供成长空间是关键。一方面，可以培养DBA负责人超越传统的DBA职能，向更大的职责范围如存储负责人或基础设施负责人发展；另一方面，鼓励DBA负责人在行业内建立自己的影响力也是一条可行的路径。

总的来说，要避免让DBA团队过于冒进。尽管数据库在研发链路中扮演着基石的角色，但它并不是枢纽。自研数据库工具链的时机应当与公司的整体研发平台的自研规划相配合，通常是在整体研发平台自研规划基本确立后，再进行相关的数据库规划。

> 800 人 - 多个DBA 团队

当公司发展到一定阶段，通常会形成业务单元的编制。这时，一个核心议题便是每个业务单元是否应自建数据库管理员（DBA）团队。

这已不再单纯是技术问题，更多地涉及到组织结构和管理的层面。

强势的业务单元往往期望拥有独立的建制以更好地满足其需求，但在实际操作中，他们可能会遇到招聘难、人才流失等问题。因此，尽管名义上保持独立，但实际上他们可能还是需要依赖中央集权来支持。

在国内的大型企业中，既有采取中央集权模式的，也有实行地方自治的。在这个阶段，随着环境和需求的变化，公司的组织结构和管理模式也需要灵活调整，没有固定的模式可循。

最后，愿天下没有难维护的数据库。



更多精彩内容，关注我们▼▼

dba 数据库

文章转载自数据与人，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。