“你怎么还在招聘DBA?” 此文完全是瞎扯

   最近在微信群经常看到有提到瑞典马工，此人也算是云计算老司机了，但十足一个喷子啊，写了很多DiSS DBA的文章。我之前不认识此人，今天很好奇，刚好一个群网友拉我进马工的群了，刚进去，果然火药味十足。

   正在赶往高铁站的路上，迎来一个下马威，虽然这个兄弟是蚂蚁出去的；But 那又如何？似乎大家现在都很BS Oracle DBA，有点南山彭于晏的味道了。那么怎么办？  这是我的观点：

1、 现在toB行业绝大部分核心甚至大部分系统都还是商业数据库，去o进程 还早呢，所以，你说oracle dba有没有事儿干？  

2、 现在数据库百花齐放，都是遥遥领先，甲方怎么选？这不都得dba来干？ 

3、 主流国产都在搞o兼容性增强，你说oracle dba有没有事儿干？

着急赶高铁，就简单回复了上面3点。

接下来重点看看主角 马工的原文： 你怎么还在招聘DBA?

此文先是开头来了一个总结性结论3点：

开门见山   

如果你是IT负责人，是时候停止招聘DBA了。因为

1、DBA能做的日常运维, 普通开发者使用云平台都能做。 

2、开发者用云服务能把很多数据库管理工作做得更高效。 

3、你以为DBA能做的数据架构设计, 其实他们从来都做不了。

然后接下来就是从目前主流招聘网站 BOSS 直聘和猎聘 网 分别找了一个招聘DBA的基本职责要求。这里马工简单总结概括了DBA们的一些工作内容：

安装和部署DB, 让它跑起来(up and running) 

保证DB别挂了(Availability) 

保证DB数据别丢了(Durability) 

防止坏人访问DB(Security). 

别让Dev搞砸数据库(DB Modelling and Performance tuning) 

领导交办的打杂事项

很精简，你看，这不就是DBA们的工作职责么？是不是很简单？

接着就上了2张阿里云RDS和华为云数据库的支持功能list：

你看，你看，前后DBA工作和云平台的功能相匹配，这是多么的有说服力？DBA的日常工作，云平台都基本覆盖了，所以说不需要DBA了。于是就得出来了这样一个荒谬的结论。我想说这是大错特错！无稽之谈！

针对上述的结论，接下来我分别来进行逐一反驳。

# 反驳1    以点带面、且此人根本不懂DBA，更没有实际干过DBA工作 

   我们知道数据调查通常要选取一定规模的样本数据吧，在猎聘和BOSS上分别找了一个JD的描述，这就算是代表了所有的DBA？ 你确定不是在逗我吗？谁告诉你的DBA仅仅是干这些工作的？恕我直言啊，马工，你一定没有干过DBA或者说你根本不了解DBA 这工作。你的3点结论不能说全错，比如第1点大部分云平台确实可以实现了，因为确实有很多dba日常工作都是一些基础运维，比如巡检看看告警、表空间扩扩容，定期做个备份演练，偶尔看个慢SQL诸如此类的。But，DBA的工作范围远不止这些，实际上我知道很多DBA日常还要干类似这样的工作：备份恢复、迁移升级、故障处理、性能优化等。至于说DBA做不了数据库架构设计，你这是有多么看不起DBA？还是说你见过的DBA全都是一些初级DBA？没搞过同城双活，异地多活、两第三种之类的架构设计？

    这是今晚某微信群网友发的甲方DBA的招聘内容请观赏一下：

高级DBA招聘啦！ 

地址：深圳南山区 薪酬：年薪40-55万之间，具体根据面试确定。 

工作职责 

1、负责云及传统环境数据库生产运维重大问题跟进、对外应用服务、部门内部项目、重要任务及重大变更的实施（升级、迁移、合并、转型等）； 

2、数据库新技术、新产品、新架构引入及推广，数据库规范制定等；

3、日常生产运维重要问题跟进及解决，定期分析跟进报表类报警，重要数据库健康检查及主动优化； 

4、重大变更技术方案的制定及跟进，自动化运维工具开发；

5、保障数据库稳定运营，提升部门产能，达到主动服务和专业服务的目标，提升用户满意度和部门外部影响力。

   请问马工，上述1,2,3,4,5谁来弄？是不是超出你认知的所谓DBA的工作范围？

   如果大家去马工公众号文章，你会发现几乎没有数据库方面的文章，即使有也是 转载别人的，个人就是专注于云计算而已。俗话说：外行看热闹，内行看门道。果然是看了个热闹！

 反驳2:  开发者用云服务能把很多数据库管理工作做得更高效

    你又是在偷换概念啊，dear 马工。你的标题是DBA，企业不需要招聘DBA。但是你这里提到开发者是什么意思呢？你的认知是 开发者等于DBA？又或者说开发者除了coding还能把运维的事儿一起干了？

     我只能说是你too old  too simple了！

     对于这个观点，我想说的是你这里应该有一个前提：那就是企业的数据库都上云了，然后开发者使用CI/CD等工具，基本上就可以完成数据库日常管理工作，比如导个数据，做个报表之类的。

     我先不说有多少大企业或者说关键行业又或者是涉密行业，不允许上云之外（即使上云也是有一定定制的私有云，毕竟都是自建IDC），其次这类企业几乎均有非常苛刻的安全管控制度，你以为开发人员能能获得sys/dba/super权限？你想多了吧。开发人员大多只能连Dev环境，只能进行CRUD之类的操作，你以为他们还能干别的？我们见过太多误删除了，客户也经历过太多的疼痛。另外你以为用了RDS 就没有误删除？明确的告诉你，我们每年都要接到几起MySQL误删除恢复，都是RDS，云上恢复基本上没戏（或者数据覆盖率较高）。

    其次我认为你太高估程序员的能力了，当然不排除有很多厉害的全栈程序员，我也认识一些，确实非常的厉害。但是术业有专攻，我敢说90%的程序员只知道如何去用代码实现功能，他们也不知道数据库架构，不太会用数据库Index，不知道优化器（比如RBO/CBO），不知道统计信息，不会看SQL执行计划，不知道主流数据库基本运行原理，更不要说利用数据库的一些特性去改善性能了。比如我们几年前经常遇到的开发人员用Oracle 老版本习惯了，客户数据库换到12c之后，还是习惯老套路使用wm_concat函数，而不知这个函数在前后版本的一些变化，处理varchar2会返回Lob，会导致数据库temp表空间爆炸式增长，直接把数据库干废掉。不了解数据库版本变化所带来的一些变化，比如这里提到的函数，你认为他们能用好数据库？

    这里我不是在贬低程序猿们，我说的是国内的现状而已。实际上他们也确实不太需要去关心底层数据库的实现逻辑，毕竟应用有问题就可以甩锅给数据库。这个很好甩的。

    我一直的观点是专业的人做专业的事！或许未来Ai足够强大了，人人都是开发人员或者人人都是DBA又或者不再区分；openAI不是刚发布了GPT store么？如果有一天数据库完全自动驾驶。我想，那真是不太需要什么DBA了。我想这还需要很长一段时间，而不是当下。

 反驳3:  你以为DBA能做的数据架构设计, 其实他们从来都做不了。

     从这话来看，你是真的不懂DBA！我只能送你一句：法海啊 你不懂爱！

     我猜想你的本意是认为DBA在这方面不专业，云厂商的方案更好。

     而我想表达的是，确实有不少刚入门的DBA 不擅长数据库架构设计。但是我们身边还是有很多很多非常不错的DBA，经常为用户提供架构咨询服务。现在不比10年前，我想大部分用户数据库都是两第三中心吧，更有一些不差钱的客户是三地五中心。当然，如果你数据库全部在公有云上，那么确实不需要过多去关注高可用和容灾了。

     But，线下呢？根据Gartner的预测，要到2027年 公有云数据库占比才会到75%，实际上截止到2023年最新的数据大概是59.8%（2019年Gartner预测2023年将有75%的数据库上云，可见高估了），还有大量用户不能上公有云的，通过自建IDC搞私有云。

    甚至我们还见过一些客户为了避免被某个云厂商绑架，而使用了多种云。在toB行业，这也是常见的事儿。而且toB行业很多客户的系统数据都是错综复杂，各种数据接口来回交替；并不遵循互联网的松耦合。在规划数据库高可用的时候，这都是需要特别关注的点，什么时候切主备，影响哪些业务，数据的一致性判断；切换后应用的访问效率是否有影响，这些都是DBA需要考虑的事儿，这就是我们常说的应用级容灾。实际上中高级或者资深DBA经常干这些事儿。

   最后不少行业客户对于高可用和容灾都是明确要求的，需要定期进行各种演练，如果不熟悉架构，DBA们能玩得转？你是在逗我吗？你的意思下次某银行容灾灾后，DBA全部休息，让开发人员上呗？

最后再来反驳你的其他几个看似完美无瑕的观点：

 观点1: 开发者+云服务比DBA高效十倍

    你这部分描述的都是内容只能说是DBA工作范围的非常小的一部分，而且不是高频操作。而且你还是基于公有云这套逻辑。

     我们就说是云DBA吧。云能完成的这部分工作， 你觉得DBA就不能快速完成，就不能写点工具和脚本？云的本质不就是底层调用代码？实际上我见过很多DBA的代码能力非常强，尤其是搞MySQL、PG等开源数据库的DBA，代码能力普遍都不错。

观点2:云厂家的专家服务比DBA专业二十倍

    这个我认为完全就是谬论了。而且这里举的例子我们认为也是有些无力（阿里云DAS服务）。首先我觉得阿里云DAS做的也非常不错，但是我不认为这就比DBA专业20倍了。

    我先不说大厂很多吹牛的居多吧，说太多很容易得罪人。想起很多年前，在某省大客户现场做数据库故障处理时，现场就有3个No 1云的P7+的专家(据说还有个P8);在用户面前说的信誓旦旦，我们的云多么的不得了，这个oracle故障我们快速搞定也不在话下，撂下了很多狠话。然后我在现场说，那既然这样，你们来干吧，我就先撤了，钱我们也不收了。是的，墨迹了1个小时，他们就不是不动手。当然结局最后肯定是我们把问题解决了。

    首先云厂商的专家服务虽然利用了机器学习等一些技术，但是也无非就是综合了大量人员等的经验而已，并非100%正确，也并非100%的最优。

     要说数据库自治，我想目前全球还没有哪家厂商的数据库比Oracle做的更牛B吧。毕竟它是第一家提出Autonomous database的厂商。

 观点3:DBA知识老化，只会滥用关系型数据库

       这又是无稽之谈。其实你这里应用要怪的不是DBA，而且开发人员不懂数据库吧，是开发人员乱用数据库才对。因为很多时候，DBA对于数据库并没有选择权，基本上都是

        应用厂商选择用什么数据库，就用什么数据库。所以我们以前看到一些软件开发商把大量的图片，音频这些非结构化数据库也往Oracle里面存，虽然Oracle在这方面也不错；但实际上并非强项。我要表达是从来都不是DBA说该用什么，否则TiDB 为什么要去迎合开发者？迎合DBA在Github上面能有几万Star？

        其次你觉得DBA都是傻子么，大家只熟悉关系型数据库，大家都不知道学习，不知道进步，大家都在多吃等死？你这话可能在10年前，我可能还认为你的对的，放到现在就大错特错了。现在哪家企业没有2-3种关系型数据库，没有一些MongoDB之类的，没有大数据平台。

       我所知道的一些医院都有Oracle、MySQL、PostgreSQL以及大数据平台了，好吧（是的，医院年收入也就几个亿而已)。

      马工，你真的要与时俱进呀！要怪你只能怪这些年国内厂商太卷了，卷的DBA 们不掌握个3-5种数据库都找不到工作的地步了。

 观点4:DBA带来的损害已经高于其价值

    最后这条也是荒谬绝伦。我们来看下原文（请不要怪我侵犯你的版权）：

    实际上，DBA目前带来的价值有限，带来的损害却很大。和你的开发者谈谈，他们的部署流程如果碰到数据库更改，是不是要慢一个数量级？DBA们往往缺乏基本软件工程训练，对可观测性，immutable infrastructure，infra as code，CICD等现代概念不熟悉，沉迷于摆弄数据库的一些莫名其妙的陈旧配置。

    当个别的DBA走出配置管理，试图开发产品的时候，我们就发现这个群体真的和现代软件技术隔离很远了。以DBA们开发的 Redis Monitor 为例，这个监控工具落后时代起码二十年。随便列举一下：

    不区分监控和告警，把两者混在一起。

    监控部分实际上完全没必要自己开发，开源的prometheus/grafana又好又便宜，实际上它这个项目做个采集器就够了。

    如果一定要自己开发，不应该把监控数据放在关系型数据库MySQL里，而应该选择一个时序数据库。

    第三条尤其讽刺，一群DBA缺乏最基本的数据库选型知识。原因就是我上面说的DBA们对非关系型数据库一无所知，只会滥用关系型数据库。

    如果这个群体宣称自己能指导开发者做数据库架构选型，那基本是个谎言。

    对于开发者而言，我倒是认为DBA有一项工作是应该去帮助开发者更好的使用数据库，用好数据库，让程序更为的为业务服务，创造价值。而不是一套应用，隔三差五就把数据库服务CPU打满了。

    我想请你去看看一些相对权威的数据，对于数据库系统故障而言，有多少是因为应用代码质量问题而产生的。我想，这点你应该比我清楚。还需要我show 出链接不？

    另外DBA的工作是去开发软件？大哥，你前面所列的DBA工作职责似乎没有这一条呢？总的来看，我认为你还是站在一个开发者在看DBA，而不是真的了解DBA。

    就算DBA自己为了保证系统稳定，提高工作效率，开发一些小工具，那也是个人使用而已，我们身边很多同事就用Perl、Java、Go写过不少小工具，但都是个人使用而已，就算代码质量不行或者工具界面很难看，那又如何呢？我认为无伤大雅。

    最后关于数据库架构选型的吐槽，就不再重复了。不过我想补充一点的是：如果DBA都不更了解一种数据库，你认为开发人员会更了解？

    我想我只能说，DBA并非全能，可能熟悉5种数据库类型，但是并非每种都很擅长或者说精通。这条算是我送你的一分！

   好了，到此结束！此文单纯的瞎写，后面也不再更新，不再进一步回复。毕竟我们还是技术人，要回归技术的本质。

说明：

  1、我并不认识马工，也就最近几天在微信群听网友在反复提到此人，有点好奇，随即加入微信群，便有了此文。不存在相互吹捧，相互引流的情况。

   2、快到周末了，就当给大家一个瓜吃吧，全当一个乐！大家笑口常开！