为什么DBA不是一个好的职业选择

编者按

本文作者是在硅谷工作的工程师，他十多年来在不同程度上设计，使用以及管理过多种存储方案，从不同的岗位角度审视了数据管理系统。他来说说为什么不要选DBA做自己的职业，希望对一些年轻同行有帮助。

工程师不应该被工具定义

有同事曾经问我，你猜印度的年轻码农和美国的有啥主要区别？

答案就在「你是做什么的」这个问题的答案中。

美国码农会说自己从事的行业或者产品，比如搜索/音乐/云计算/新闻/地图/等等，而印度年轻人的回答会是「我是做Java的」，「我是做Python的」。

如果你也认同码农不应该只学只用一门语言，那我们继续。

通往资深DBA的路途狭隘

DBA作为一个独立工种诞生于非关系型数据库流行之前，但是同学，时代变了，今天各种类型数据库以及可用于数据存储的系统层出不穷，在这个存储系统的选择都变成面试必考环节的背景下，如果被问及自己是做什么的，回答一个「DBA」，或者「PostgreSQL DBA」是不是显得自己年纪太senior了。

有人会反驳说某某大中小厂的谁谁谁非常资深，就是专门做MySQL DBA的，年薪百万$。

这种例子一定是存在的，但有两个问题：

第一是这种职业方向的可持续细分发生在职业生涯的中后期，比如Meta有generalist, specialist, coding machine, fixer, tech lead等等不同的archetype，DBA算是specialist，但这些方向只针对IC6+的级别才有，初入职场的要先走过前期的8-10年才可能有选择的机会。

第二个问题是，哪怕真的有一个资深的specialist，面试相关职位也会被问及跟自己的专业方向完全不相关的问题，比如做底层网络协议的被要求设计股票交易系统；做DBA的被要求设计YouTube，你可以质疑这种面试有啥用，但技能的广度在某种意义上决定了一个Infra工程师的工作能否成功落地，喜欢不喜欢，市场就是这个样子。

Markets are never wrong, only opinions are. —— Jesse Livermore

DBA的工作谁来做呢？

如果没有DBA的岗位，DB应该由谁来管理呢？尤其是那些还没搬到云上的。

如果你们还有运维，更合理的方式是让开发和运维来共同负责，没见过什么公司会针对Cassandra/Redis/InfluxDB/Druid/Snowflake等等招聘专门的管理员，而且PostgreSQL也并不比Druid更高贵，很多时候线上问题的诊断需要双方的共同参与，比如当运维们准备针对流量的突发增长开始规划扩容的时候，开发们知道这只是一个被配错了流量的A/B测试。

数据库创业的热潮

最后，也许有人问为什么DBA作为工种越来越少了，但各种数据库管理平台的创业项目却越来越多？那么请这些创业者多想想主流企业的需求。同样是做文字工作的，你们看看只做小微企业客户的37signals，再看看憋了个大招的OpenAI，还请创业者们引领时代风口，而不是去帮小微企业节省一点点RDS的费用。