读《你怎么还在招聘DBA》有感
最近有一篇文章《你怎么还在招聘DBA》很火，里面的观点我非常不认同。
阅读本文之前建议您先阅读《你怎么还在招聘DBA》。
原文链接: https://mp.weixin.qq.com/s/DtRFnh8LgtfesCNMNl3eNw
原本我是不打算专门写一篇文章辩论的，并且也没啥好辩论。《你怎么还在招聘DBA》文章观点一派胡言，根本没有人相信，也就没有必要辩论反驳了，但我作为营销号新人(没错，本公众号是营销号
题外话: 以前我想过要开一个专栏叫《芬达辣评》，怕得罪人就放弃了。
1. 反驳“开门见山”
IT 负责人招聘 DBA，那是因为有需要。小公司当然不需要 DBA。每家上点规模的公司都会招聘 DBA，IT 负责人不需要您教，他们知道他们在做什么。
DBA能做的日常运维, 普通开发者使用云平台都能做。
反驳: 确实像 RDS 等云平台，能完成绝大多数的运维工作，但依然存在云平台不能做或者做得不好的地方。因为云平台不是你们公司开发的，不可能百分百契合你们公司的运维框架或业务需求，这部分不能用云平台直接完成，仍然需要人来做，至于是不是普通开发者能轻易做好，那就不得而知了。
开发者用云服务能把很多数据库管理工作做得更高效。
反驳: 这个观点是我感觉最懵逼的，说开发者用云服务能把很多数据库管理工作做得更高效，职业 DBA 用云服务不应该才是更高效吗。大家都是点鼠标 web 界面管理，DBA 就点不赢开发了？如果作者的观点是 "一样高效"，我勉强能接受，"更高效" 我只能说呵呵了。此外，除了效率方面，DBA 还会做得更好，因为 DBA 专门研究数据库，是懂原理的，我怀疑开发者去做个简单的 DDL 操作，数据库发生了 SQL 堵塞了，都不知道是自己犯了错，而职业 DBA 是不会犯数据库原理方面的低级错误的。
你以为DBA能做的数据架构设计, 其实他们从来都做不了
反驳: 小公司会让 DBA 也做数据架构设计，那他必须需要懂业务的，反正公司小业务单一，这是可行的。大公司的 DBA 管理成千上万套数据库，不能腾出时间参与设计和理解业务，数据架构设计一般是开发来做，没毛病。当然了，如果要求 DBA 参与，作为专业人士必须能给出很好的设计意见。
2. 反驳“DBA究竟在做些什么工作”
反驳: 作者完全不懂 DBA，还需要去招聘网站查 DBA 要做什么事。这个总结分类不够细，下面是我的总结:
DBA 负责数据库的运维管理工作，包括安全加固、生产值班、工单处理、账号审计、例行巡检、容量管理、监控告警、部署交付、数据迁移、切换演练、上线变更、系统优化、备份恢复、系统集成、故障排除、定制标准规范、编写技术文档、数据库资产管理等等。除此之外，还会开展一些技术交流和培训工作。高级一些的 DBA 还要研究新技术，容灾架构设计，参与平台工具开发等等。
先不说程序员能不能干上述工作，能的话，这些活他都接下来了，还有空全职开发代码吗？显然是不能了。他一旦接下了这些活儿，他已经同时是 DBA 了。那作者为什么说不用招聘 DBA？哦，原来他们已经有 DBA 了。
显然云数据库能给 DBA 减轻诸如“部署交付”、“备份恢复”等工作量，但是这活儿还是要人干，需要人去点鼠标吧？
当然, RDS服务提供这些功能并不代表它们就自动启用了, 你还需要一个员工去依据需求开启或者关闭这些特性. 有的朋友就问了“那不就还是要一个DBA吗?” 实际上, 一个普通程序员, 在文档的帮助下, 已经可以轻松启用这些功能了. 在Infra as Code的帮助下, 他/她还能把这些配置代码化, 做到版本管理和可审计。
反驳: 前面我已经讲过我的观点了，这个普通程序员，专门去维护 DB，那么他就同时是 DBA 了。所以不需要 DBA 是个伪命题。那有没有一个可能？不专门定一个程序员去维护 DB，每个人都可以维护 DB？那我想贵公司的数据库权限应该是乱的，然后每个人都可能 drop database 和跑路，或者下载隐私数据。
所以我的观点是，无论工作量多少，至少需要一名 DBA，上面的案例里，我可以理解为这个普通程序员主要的 title 是 DBA，其次才是程序员。如果工作量足够大，他就是全职的 DBA。如果这个公司有专职做服务器或应用运维的人员，DBA 这个角色也轮不到普通程序员兼任，而是运维工程师兼任。
3.反驳“开发者+云服务比DBA高效十倍”
反驳: 由于我并不使用云数据库，所以不太懂他说的这个工具是什么。要掌握一个工具，普通开发者和 DBA 都是一个普通人，为啥开发者就高效一些呢？没看懂。如何证明作者说的方法就是最高效的方法。而实际上很多 DBA 本身也会编程，写 shell、python、go 甚至 java 不在话下。DBA 只是一个角色，不代表 DBA 是笨蛋好吗？
4.反驳“云厂家的专家服务比DBA专业二十倍”
反驳: 二十倍不知道怎么算出来的。作者举的例子是"数据库自治服务" 是阿里云利用专家经验和机器学习的杰作，他已经超越了人的运维水平了。我相信自愈和性能优化这两个技能上是 Yes 的。但就像自动驾驶一样，不是银弹，完全的自动驾驶可能还有 50 年的路要走。司机就是自动驾驶汽车上的 backup，随时准备在机器或软件失灵时救命。DBA 也一样，阿里云的 DBA 也是在有需要的时候要救火，这就是职业 DBA 的价值。但他们的 DBA 再专业，也比不上自家的 DBA，原因如下：
找阿里云的 DBA 支撑要走工单，回复很慢，除非你是大客户。而自家 DBA 回复总是很快的，有时候程序员可能只是忘记了一个命令怎么敲，微信问 DBA 那就很方便。 阿里云的 DBA 不会比自家的 DBA 熟悉业务或架构，解决问题的沟通成本是很高的。
总之，远水救不了近火，真发生事情时，老板都很着急，你当时可能会后悔上云，为什么阿里云服务那么慢，想下云的心都有了。
5.反驳“DBA知识老化，只会滥用关系型数据库”
反驳: 绝对没有的事。DBA 会告诉你什么情况可以用 MySQL，什么情况可以用 PG，什么情况用 mongodb，什么情况使用时序数据库。在 MySQL 里存图片的行为只有开发会干。
反驳: 这个是否招聘专家，完全看公司。在从前，如果我每天都要邮寄 1000 封信，那我为何不请一名员工专门寄信，冠名为"邮寄工程师"呢？公司里的技术栈本身就不应该那么多那么杂，如果已经是现状了，那么就应该在招聘里写明要招一名专职的 DBA，要求懂关系数据库的同时，略懂 kafka、redis、hadoop 等等。您猜 DBA 学这些快还是程序员呢？
6.反驳“DBA带来的损害已经高于其价值”
反驳: 作者主要说的是弱鸡 DBA 带来的损害，实际上同样地，弱鸡程序员带来的损害也不容忽视。所以问题不是因为 DBA，"菜"才是原罪。
结尾
DBA 是很专业的工作，我专职做 DBA 七年有余，一开始只能专注于 MySQL 等开源数据库，这几年才往广度学习，redis、TiDB、PG、openGauss 等等，作者说的普通程序员应该是单纯使用 MySQL 或 PG 云数据库的，这只是众多数据库里的冰山一角。数据库知识很专业，并且数据是企业的核心资产(数据在则企业在，数据亡则企业亡)，前段时间新加坡 shopee 裁员时裁了一整个业务线，所有人都被裁了，只留下 DBA SRE 去管理数据。没有人会相信一个业余选手能维护好数据库。作者说了很多云的好处，实际上云的坏处只字不提，已经有其他同学发文章回应了，例如云比 DBA 要贵很多，云有供应商绑定的问题(上云容易下云难)，这些我就不提了，相关反驳可以看这篇文章《云数据库是不是智商税？》。一开始以为作者是阿里云 RDS 的营销号，实际上不是，作者只是单纯的无知的认为程序员可以替代 DBA 而已，但他没弄明白 DBA 只是个角色，一个伟大的数学家，可以同时是程序员、甚至厨师，他当然也可以是一名 DBA 了，这没冲突。