瑞典马工是个什么玩意？他凭什么来说 DBA ？

我的朋友冯若航是个专业 DBA，非常关注数据库行业的发展，经常发一些业内进展新闻，同时他自己也维护了一个 PostgreSQL 的发行版 Pigsty，打包了一些常用的数据库管理工具。

我从来没有管理过数据库，不知道 MySQL 5.7和 MySQL 8.0版本有哪些区别，甚至也不太会写复杂的 SQL。

冯老板认为他是一个数据库专家，我是一个数据库外行，这也是大多数朋友的意见。我本人不认同他这个定位，实际上我认为在数据库的发展趋势上，相对于冯老板，整个 DBA 圈子，和依赖于 DBA 反馈的数据库厂商们，瑞典马工更有发言权。

DBA 这个群体很有意思，他们自认为是数据库的用户，经常会代表甲方给数据库厂商提意见。

但是恕我直言，DBA 不是 DB 的用户，从来都不是，现在不是，以后也不是。

DBA 是 DB 解决方案的一部分

DBA 是 DB 解决方案的一部分个。这个说法可能让一些朋友觉得很突兀。我们可以先绕开一下。

假设贵司要组织年度优秀员工出行，需要租一个大巴车。租车公司会给一个巴士，提供停靠点，加好汽油，提供矿泉水，然后有个拿 A1 驾照的司机会开着大巴从停靠点出发，一路消耗汽油，在你们喝完两瓶哇哈哈之前，就抵达深圳大梅沙，让你们在海滩愉快的看一下午人头，晚上再把你们送回市区。这是一个完整的运输解决方案。在这个方案里，很明显，大巴司机不是大巴的用户，他是运输解决方案的一部分。真正的用户是乘客你，我们亲爱的年度优秀员工。

同样的道理，DBA 也是 DB 解决方案的一部分，和二进制文件，虚拟机，存储阵列，磁带，交换机，用户手册一起，构成一个数据管理方案，交付给客户，服务于真正的用户：应用软件开发者。

我们行业有个笑话，把一些低水平 Java 程序员叫做 CRUD 工程师，讽刺他们只会写点初级代码在数据库里 Create，Read， Update 和 Delete。这个笑话虽然尖刻，但是无意中也揭示了一个事实：开发者围绕 DB 写代码，把 DB 的功能发挥出来，他们才是真正的用户。

有的 DBA 朋友读到这里，忍不住要骂我了：“狗屁，你那些增删改查工程师对数据库狗屁不通，他们写的每一行 SQL，我都要过一边才让他们上线。你们也配看不起 DBA！？” 我赞成这位朋友说的可能是事实，但是抱歉，优化开发者代码的除了你，还有query optimizer^[1]，所以你其实就是个前置的，运行速度特别慢的，碳基 SQL 优化器。  还是 DB 解决方案的一部分。

DBA 是厂商 DB 解决方案的一部分

一个非常有趣的事实是：运维工程师不会说自己是红帽子运维工程师，大巴司机不会说自己是宇通司机，手机维修师傅不会说自己是华为手机维修师傅。但是 99%的 DBA 会很具体的说自己是 PostgreSQL DBA， MySQL DBA 或者 Oracle DBA。他们对厂商有一种很强的归属感。去年 PostgreSQL DBA 冯工就和一个 MySQL DBA网上约架，后者甚至很不体面的翻冯工的简历，对他实施人身攻击，让人恍惚间似乎在围观宗教战争。

对这种特殊现象，我是这样解释的：SQL Server  DBA 作为微软 DB 解决方案的一个组件，如果移植到 Oracle 解决方案就不适用了。 MySQL DBA作为 MySQL 解决方案的一部分，也嵌入不进 PostgreSQL 方案中。因此他们最首要的工作，就是维护自己所在解决方案的声誉，不惜要开启宗教战争。

作为对比，我用了十几年 C，一点不在乎别人说 C 落伍了，我甚至还比批评者更快的放弃 C， 转投 Typescript 和 Python。原因也很简单：开发者从来不是计算机编程语言解决方案的一部分，开发者是计算机编程语言的用户。

DBA是 DB 厂商的免费组件

有朋友挑战我：“你说 Oracle DBA 是 Oracle DB 解决方案的一部分，那我就是甲骨文的成本，你找甲骨文把我的薪水拿回来。” 这位朋友认为他机智的问倒我了。

实际上，强势软件厂商设计的解决方案中，让甲方自行承担一部分费用，是非常常见的。瑞典马工干的 platform engineer 或者 cloud engineer 岗位，本质上就是AWS/Azure/GCP云解决方案的一部分。但是，总所周知，这几个厂都很强势，所以甲方必须自行承担瑞典马工的薪水，就像 Oracle 客户自行承担 DBA 的薪水一样。

作为对比，国内云厂商，经常派自己的工程师去客户现场免费驻场，甚至现场开发，甚至顺手帮客户做了个微信小程序。究其原因，就是他们产品不过关，只能通过派人驻场来弥补产品缺陷，最终凑成了一个勉强工作的解决方案。但是，显然，客户不会为他们的主场工程师付一毛钱，顶多中秋节发两个月饼鼓励下。

DBA是解决方案中会被删除的组件

我的朋友李令辉最近发了一篇文章《数据库的“萝卜快跑”时刻已到，DBA 请下车》，大意就是他的 DB 解决方案 ClapDB^[2] 里，没有 DBA 这个组件了。他提出的理由是，他的拍手数据库把整个云当做一个操作系统，利用 infra as code 能够动态的申请/释放资源，极大的降低了维护负担，使得 DBA 这个组件不再必要。

我去年写过一篇文章，《为什么云数据库有更高的可用性》，和令辉的观点基本一致。不过我主要从数据库的用户角度出发，指出云上数据库配备专职的 DBA，已经没有必要了。这个结论主要来自于我的实际经验。我上一个单位，开发团队有四千多人，没有一个专职 DBA。 只有两个 DBRE 负责编写合格的terraform modules，以及写脚本审计数据库。我现在任职单位，也没有专职 DBA，但是我们的 DBA配置得可能比绝大多数 DBA 看管的 DB 更安全更可靠。举个例子，我们所有的 DB 都开启了 TLS，即使有人入侵了内网，也无法嗅探我们的数据库数据。各位可以问下自己的 DBA，他们有没有开启TLS。

就连发明 DBA 这个岗位的甲骨文公司，也在抛弃 DBA。 虽然他们宣称的Autonomous DB^[3]没有取得预期的进展， 但是看他们的 Automatic Indexing 特性和托管服务，就是奔着 DBA-free DB Admin去的。

围绕 DBA 开发的数据库死路一条

我国有一百多家数据库厂商。他们有的把开源软件包一层皮，有的自研代码，有的通过奇怪的渠道获取商业数据库代码。手段虽然不同，但是最终目的都是：做出一个兼容 Oracle 的数据库，争取做到无痛迁移，求 DBA 老爷们早点把 Oracle 替换掉，把甲方给甲骨文的钱给到我。

我认为这是一条不归路。

如上所言，DBA 们是厂商解决方案的一个模块。Oracle DBA 们对甲骨文的种种细节津津乐道，也靠这些长年累积的小知识吃饭。迁移到你的牛逼一号数据库，他90%知识的价值就归零了，他怎么会开心？

我们看到，绝大多数国产数据库替换项目，都不是工程驱动的，而是合规驱动的。然而，总所周知，合规驱动有一个很大的缺陷：造假。有的客户合同上用你的国产牛逼一号数据库，但是实际在线的可能还是个盗版 Oracle，或者开源的 PostgreSQL。

目前，我几乎没有看到一个国产数据库是产品驱动的增长。当领导们穿着西装给他们在大会站台的时候，工程师们私下里在微信群互相提醒：“牛逼一号和牛逼二号数据库，一堆的坑，我建议你不要接这个活。”

我个人认为，新生数据库厂商应该迎合数据库真正的用户：开发者。服务开发者，推动他们更好的增删改查，自然就会组织有了更高的价值。至于 DBA，是需要克服的障碍。但这是另外一篇文章了。

马工你屁放完了没？

去年一月份，我依据个人经验写了《你怎么还在招聘 DBA》，广大 DBA 们就很不开心了。后来我又写了《再论为什么你不应该招 DBA》，试图用一个简单的模型证明其合理性，广大 DBA 朋友们更生气了。有些特别激动的朋友甚至跑去我微信骂人，还对着我的头像吐口水，说我长得不好看（我本人不同意该观点）。我的朋友向宇写了一篇《为什么DBA不是一个好的职业选择》也被骂了。

但是杀死一个信使并不能让坏消息变成好消息。随着云计算的成熟，应用系统已经抛弃了传统的 LAMP 架构，数据库本身也在向着云原生方向进化。在这双重冲击下，没有道理相信 DBA 这个组件不会变化。

当然，作为工程师的一员，我绝对不是在主张雇主们粗暴的把 DBA 裁员，这是违反中华人民共和国劳动合同法的。

同样，我并不是在主张 DBA-free DB Admin 就完美无缺。合格 DBA 的缺位确实会带来一些新的问题。如何从软件开发生命周期 SDLC 视角弥补这些问题带来的损伤，是我在接下来一两年会持续探索的问题。我会持续和各位讨论，也欢迎各位提供坦率的反馈。

参考资料