开门见山

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

DBA能做的日常运维, 普通开发者使用云平台都能做。开发者用云服务能把很多数据库管理工作做得更高效。你以为DBA能做的数据架构设计, 其实他们从来都做不了。

DBA究竟在做些什么工作?

下面这个高级DBA工程师的岗位来自直聘网,其工作内容包括：

负责数据库架构设计.方案制定.数据存放选型和落地（包括数据库读写分离.数据库备份.数据库容灾.集群扩展.分库分表策略）；2.负责支持研发在数据和缓存方面的方案探讨，并沟通引导使用合适的技术；3.负责优化运维.排障.监控数据库，提高服务质量，提升系统稳定性；4.负责挖掘及发现现有框架存在的问题和不足，提出改进的意见与方案，并推广；5.负责数据库自动化运维工具的开发与优化。

下面这个数据库高级DBA的岗位来自猎聘网, 其工作内容包括:

1、管理内部业务库，清楚应用的架构逻辑，保证数据库的安全与性能；2、负责数据库的线上稳定工作，确保达到业界领先的SLA水平；3、负责对数据库进行日常的建设部署、配置管理、监控报警及故障处理等工作；4、对数据库内部实现的深入探索

总结下, DBA不论高级低级或者黄金级, 就是干几个事情:

安装和部署DB, 让它跑起来(up and running)保证DB别挂了(Availability)保证DB数据别丢了(Durability)防止坏人访问DB(Security).别让Dev搞砸数据库(DB Modelling and Performance tuning)领导交办的打杂事项云服务把DBA的工作都给做了

那么一个程序员, 用云厂家的数据库服务, 能不能完成上述任务呢?

除了数据库建模以外, 阿里云RDS基本覆盖了DBA的所有工作.

华为云的成长地图页面给出了更详细的列表:

当然, RDS服务提供这些功能并不代表它们就自动启用了, 你还需要一个员工去依据需求开启或者关闭这些特性. 有的朋友就问了“那不就还是要一个DBA吗?”

实际上, 一个普通程序员, 在文档的帮助下, 已经可以轻松启用这些功能了. 在Infra as Code的帮助下, 他/她还能把这些配置代码化, 做到版本管理和可审计。

开发者+云服务比DBA高效十倍

开发者+云服务不仅能取代DBA，他们还能把工作做得更高效。

就以DBA们最头疼的配置一致性为例，使用terraform，你可以保证你单位90%的数据库实例都有一致的配置。github上有大量的example， 比如这个

如果剩下10%的数据库实例不使用terraform来产生，而开发者又想确认这些实例开启了某一个功能，比如多AZ高可用。那也很简单，AWS Config内置了一个检查规则，可以轻松的找到你组织里任意一个没有开启多AZ高可用的数据库实例。除此之外，还有rds-logging-enabled，rds-in-backup-plan，ec2-security-group-attached-to-eni等等规则，开发者需要做的只是指定这些规则，AWS Config会自动检查每一个实例是否满足这些规则。

云厂家的专家服务比DBA专业二十倍

高级DBA相对初级DBA的差距之一就在对开发者的影响力, 也就是上述招聘启事里提到的

2.负责支持研发在数据和缓存方面的方案探讨，并沟通引导使用合适的技术；

这一部分工作主要是利用专家知识, 实际上也被云厂家做成了服务. 比如阿里云的数据库自治服务 DAS

数据库自治服务（Database Autonomy Service，简称DAS）是一种基于机器学习和专家经验实现数据库自感知、自修复、自优化、自运维及自安全的云服务，帮助用户消除数据库管理的复杂性及人工操作引发的服务故障，有效保障数据库服务的稳定、安全及高效。

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

DBA虽然顶着数据库管理员的头衔, 但是长久以来一直只专注于关系型数据库(Oracle, SQL Server, MysQL和PG), 缺乏管理非关系型数据库的能力, 所以更贴切的名字应该是RDBA.

这种错位在以前是无关紧要的, 因为大多数系统只用关系型数据库. 比如著名的Zabbix使用MySQL来存储时序数据. 我还见过用MySQL存大量图片的案例.

但是现在2022年了, 越来越多的团队意识到关系型数据库不能滥用. 时序数据应该存到时序数据库里, 文档数据库在很多情况下可以替代关系型数据库, Redis在很多情况下可以当作数据库用, 在延时要求不高的场景, 对象存储也可以用作数据库. KafKa作为一个消息队列, 从应用层offload了状态, 也是一种数据库. 更不用说Hadoop那一系列套件.

而所有这些系统, 都不在DBA的技能覆盖范围, 甚至不被DBA视作自己的职责.

更进一步, 即使关系型数据库中的分析型数据库, 比如Teradata, Greenplum和Redshift, 也超出了绝大多数DBA的能力范围.

这就给CTO们带来了一个新问题: 在DBA之外, 你还要招聘Kafka管理员, Redis管理员, TSDB管理员, Hadoop 管理小组, 对象文件管理员吗?

我的建议是, 你不需要这么多专职管理员. 80%的程序员, 认真阅读云厂家的文档, 就能比80%的管理员做的更好.

DBA带来的损害已经高于其价值

数据库归根结底是一个软件产品，过去由于数据库厂商的技术缺陷，产品的可维护性非常差，以至于甲方不得不投入专职管理员。但是云时代，数据库从一个交付软件变成了一个服务，极大的降低了甲方的管理成本。甲方确实没有必要再投入专人去维护一个自己已经付费的产品了。

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

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

不区分监控和告警，把两者混在一起。监控部分实际上完全没必要自己开发，开源的prometheus/grafana又好又便宜，实际上它这个项目做个采集器就够了。如果一定要自己开发，不应该把监控数据放在关系型数据库MySQL里，而应该选择一个时序数据库。

第三条尤其讽刺，一群DBA缺乏最基本的数据库选型知识。原因就是我上面说的DBA们对非关系型数据库一无所知，只会滥用关系型数据库。如果这个群体宣称自己能指导开发者做数据库架构选型，那基本是个谎言。

DBA们不要骂我

美国入侵伊拉克的时候，每个伊拉克官员都只给萨达姆好消息，没有人胆敢给他报坏消息，使得萨达姆严重高估了其军事实力，决定和英美联军打一场持久战。结果大家都知道，伊拉克军队抵抗了两个多礼拜就放弃了。这个故事告诉我们：如果有人告诉你坏消息，他不一定是坏人，你骂他不会让坏消息消失，只会让你和现实生活更隔离。祝大家好运！