再论为什么你不应该招DBA
摘要
过去十几年，数据库和云计算得到了极大的发展，云数据库的维护变得非常简便；分库分表不再需要；DBA实际上威胁了数据安全，因此本文呼吁企业重新思考DBA岗位的必要性，也建议广大DBA从业者早日转型。本文附有Demo代码，欢迎上Github提交issue。
问题背景
我之前的一篇文章《你怎么还在招聘DBA？》，受到了DBA的广泛批评。坦率的批评是行业进步的动力，也是相互学习的机会，但是我很失望的看到大多数批评质量不高。
有些DBA朋友甚至大声宣布，现代企业数据越来越多，越来越重要，是企业的命脉线，因此DBA不可或缺。这是在有意无意的打造“数据 === 数据库 === 数据库管理员”三位一体的神话。数据确实很重要，但是关系型数据库可不等于数据，DBA也不等于关系型数据库，因此这个论证是有严重逻辑缺陷的。
也有一类朋友一方面说云数据库确实在革命，一方面又主张“有个DBA也挺好的，有一个总是比没有好嘛”， 听起来好像有道理，实际上，一个CTO的重要职责就是设置岗位。如果不加审视的乱设岗位，团队的生产力是会被限制的。
DBA的价值空间
对于DBA岗位价值的评估， 其实有一个更好的办法：
假设有个完美的DBA团队，整个软件开发团队会达成一个绩效，称为绩效上限。
假设完全没有DBA团队，整个软件开发团队也会达成一个绩效，称为绩效下限。
绩效上限减去绩效下限，得到的就是DBA团队的价值。
对于DBA来说，如果上限变高并且下限变低，那么DBA价值就会变得更大，行业地位就越重要。
但是可惜的是，过去十几年来，行业趋势是反的：DBA能达到的上限在下降，而没有DBA的下限显著地提高了。
下限提升：免DBA得到更快的DB交付速度
DB Admin 的重点从来不是技术（实际上DBA也不太了解数据库技术），DB Admin的重点一直是合规：
确保数据库有正确的配置了HA。
确保数据库定时的备份。
确保开发者/App有合适的权限。
确保App使用的SQL对数据库是安全的。
在古代（比如25年前），没有DBA的话，开发者只能让数据库在单机上up and running，可能把数据库置于一种“坏了一块磁盘就丢失整个企业的数据”的危险状态。因此没有DBA的下限很低很低，我们认为是企业破产。
但是在云上，数据库的可维护性得到了数量级的提升。
假设贵司一个新上线的App对数据库有如下要求：
要求Postgres 14.6，并且要能轻松升级小版本。
要求数据库两地三中心，同城HA，异地灾备。
要求备份的数据被加密。
要求备份是自动进行的，避免出现人员遗忘备份的故障。
要求提供数据库性能观测工具。
要求App和DB在一个独立的网络中。
要求在网络层，该App只能访问该DB，该DB只能被该App访问。
由于数据重要，老板希望你能证明即使你自己也没法删除备份文件。
我在一个DBA高手群抛出了这个问题，希望得知DBA们平均需要多少时间能完成这个数据库的配置。很可惜，大多数DBA们没法回答这个问题，甚至无法估计需要的时间。DBA们第一个反应是：
能想到的人，app负责人，硬件负责人，网络负责人，数据库负责人，都要拉来开会。
即使最激进的冯老板给的答案也是：
只要机器到位，网络打通，我觉得一天够了。当然说肯定要给自己留十几天提前量为宜。
实际上，我用云服务+Terraform，只需要二十八钟就可以完成满足需要的配置。具体请参见GitHub的代码：https://github.com/lipingtababa/cloud-native-best-practices/tree/main/dba。
这个数量级的时间差，来自于一个事实：在云上，包括用户/网络/虚拟机/数据库软件/密钥在内的所有资源都可以通过代码（Terraform）来配置，你不再需要拉通各色人等去拉通，开会，争吵，排期，扯皮和甩锅。鉴于代码运行速度比人的运行速度高出成千上万倍，因此用Terraform搭建数据库比拉人搭建数据库快几个数量级，也丝毫不应该让人惊讶。
在IT和业务越来越紧密的今天，软件交付速度决定了企业的竞争力，而在DB管理节省的每一天时间，都可以直接转换成业务团队在市场上的竞争优势。与之相比，节省的人力成本反而是小头了。
下限提升：远离DBA，远离分库分表
由于历史原因，DBA们只懂单机关系型数据库。关系型数据库是很伟大的发明，这一点毋庸置疑，但是在Edgar F. Codd博士发表他著名的《A Relational Model of Data for Large Shared Data Banks》论文53年之后的今天，现代数据库的种类得到了极大地扩充，在很多场景下，有更专业的数据库可以选择。但是可惜的是，在很多应该用时序数据库/图数据库/NoSQL数据库的系统中，开发者被DBA们有意无意的引到单机RDBMS去，付出了没必要的开发成本和运行成本。
在这些误导中，最严重的莫过于分库分表（Sharding）。
分库分表的核心原因是传统RDBMS吞吐量有限，开发者不得不在应用层work around，这实际上是数据库开发者把其产品能力缺陷造成的额外成本，转嫁到数据库的用户，也就是App开发者。在15年前，鉴于没有其他更好的选择，分库分表是一个无奈的选择。
但是在今天，数据库的能力已经得到了极大的发展，给应用开发者带来巨大管理成本的分库分表已经没必要了。凡是在用分库分表的系统， 都可以用分布式数据库或者NoSQL数据库替换掉。几乎可以说，分库分表不过是DBA自抬身价的一种工具。
上限下降：不断出现的删库跑路
中国技术管理者特别喜欢管人，如果一个问题可以用代码解决也可以用加人解决，90%的技术管理者会问HR要一个编制加个人，以增加自己训话时候能折磨的听众人数。
但是在数据库管理上，依赖DBA而不是代码，有可能给自己带来致命危险。就像《SaaS服务商微盟遭员工“删库跑路”，300万商户哭了》描述的，一个恶意的DBA可以彻底的毁坏所有的数据库组件，使得数据彻底无法恢复。作为对比，一个恶意的开发者，就像《百度“95后”大厂程序员被判刑》描述的，对数据库只能造成有限的损害。
这巨大的破坏力差别来源于一个事实：绝大多数DBA具备root权限，一方面是DBA可以审查App开发者SQL，一方面是没有人能审查甚至制约DBA的行为。举例来说，99%的DBA有能力删除单机数据库上的访问日志，彻底架空审计团队对DBA的审计。
又举例来说，微盟那个案例里，我相信他们是有数据库备份的，但是DBA把备份文件删了之后，微盟就失去了他们以为他们拥有的数据库备份，只能对着硬盘“白了少年头空，空悲切”。
尽管绝大多数DBA人品正直，但是技术上而言，每个DBA都是一个爆破手，可以一夜之间炸掉整个公司的数据，让公司破产。要消除这种风险，只能限制DBA的能力。
比如在腾讯云有一个规则
自动备份无法手动删除，可设置备份保留时间，到期后会自动删除。
同时还腾讯云规定
数据和日志备份是否可以关闭？
不可以关闭。但可以通过 MySQL 控制台 减少备份频率和删除不再使用的手动备份数据来降低备份空间的占用量（单节点云盘实例手动备份暂不支持删除）。
当一些决策者担心云厂家会偷窥他数据的时候，云厂家实际上已经主动扮演了数据守卫者的角色。
DBA确实应该退出历史舞台了
综上所述，云计算使得高质量的DB管理变得非常容易，解决了DBA带来的开发周期延长问题。而DBA的存在，实际上是对企业数据安全的一个威胁。如果设置DBA不是弊大于利的话，至少也是利弊相抵了。而对广大DBA来说，转型也是必然的。我在《云计算：好的，坏的和ChatGPT的》群中讨论的时候，就有四个公司说没有设置DBA岗位，其员工数分别从两百人到六千人，市值则从十亿人民币到67亿美金。DBA们印象中“只有微型公司才没有DBA”并不符合事实。
DBA大转型
当很多初级DBA还在幻想“要淘汰的都是菜鸟DBA，我修炼成挽救大厦于将倾的高级DBA，就不会被淘汰了”，然而真相很残酷，很多经验丰富的DBA实际上早已经转型了。
相关阅读
《云用户在用什么高阶服务》提到约50%的云用户使用了云数据库，云数据库是采用率最高的高阶云服务之一。
《你怎么还在招聘DBA?》提出了本文的问题，并且做了第一次的探讨。