“你怎么还在招聘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、快到周末了,就当给大家一个瓜吃吧,全当一个乐!大家笑口常开!