DBA（Database Administrator），即数据库管理员，专门负责管理和维护公司的数据库。然而，随着上云的趋势渐盛，许多企业都把数据库迁到了云平台上。云服务提供商通常会提供自动化工具和标准化服务，这让 DBA 的工作得到了解放，也产生了一丝危机——有人质疑：毕竟最重要的硬件管理和架构管理已经没了需求，而日常的监控和优化工作借助工具就能完成，是否也意味着，DBA 这一岗位要被云淘汰了？
但也有人认为，现在谈 DBA 被云淘汰还为时过早，云服务更多是辅助工具而非生产工具，它并没有完全取代 DBA，只是改变了 DBA 的工作方式和职责，让 DBA 更专注于高级的数据库管理任务，在数据优化、安全管理、成本管理和合规性方面发挥更大的作用。
那么，实际情况是怎样的呢？企业对 DBA 这一岗位的需求减少了吗？云环境对 DBA 的工作产生了哪些新要求？作为个人的我们，又该补充哪些新知识，才能跟上云时代的发展呢？
对此，开源中国邀请了磐吉云数 CEO 冯若航、公众号《瑞典马工》主理人马工、云原生数据库 clapdb 创始人李令辉、云和恩墨的数据库技术负责人李真旭、Oracle ACE-Pro 薛晓刚一起来讨论，希望能给各位同行带来启发。
01 DBA 对于组织的价值是什么？
正方：马工 speaking ——
我没有干过 DBA ，但是跟很多 DBA 打过交道，在我看来，DBA 的工作主要是3点：
第一，安装和部署 database，让它跑起来；
第二，保证它不要挂掉，即保证它的可靠性；
第三，保证它的数据不要丢了，防止数据泄漏。
还有一些小事，比如说不要让开发者搞砸数据库以及性能调优。
不过，据我所见，每一个 DBA 的招聘启示里都会有“领导交办的其他事项”，就是打杂嘛。如果在座有 DBA 的话，对打杂这个事应该感受很深。
以上这几点，我看都被 RDS 做完了，如果是做不了的，剩下的工作也不足以支撑一个专职的岗位了。
正方：李令辉 speaking ——
作为一个 DBA 团队的直属 leader，DBA 在我管理一个中大型公司的 Infra 团队的时候的确是非常重要的，因为专人专事。对于数据库来说，我们最在乎的是它的可靠性，数据不丢、服务不断，从这个角度来说，是需要一个专业团队去维护的。
但是，如果这些事情，自动化就能做到，会怎么样？
如今，在云上，这大部分已经成为现实了。首先，云在 availability 和 durability 上做得比云下系统好得多，云上基本可以避免 SPOF（single point of failure），但是在云下，这件事情成本非常高。在云上，你可以按需购买，按量付费，这本身就让小公司拥有了一些高可用性。
其次，云删减了一些原有的 DBA 工作。例如，原来买了一批新的服务器，或者上架了一个新业务的时候，都需要 DBA 把数据迁移过去测一下。但现在在云上，硬件环境有限，这些事情已经不再需要我们作为甲方去处理了。
还有一件事是业务方面，过去阿里提出过一个词，叫全链路压测，这件事也是数据库团队做得最多的。可是在云上最大的好处是，我很容易就可以用 IAC 的方式把我的服务复制一份。这些事情都可以自动化，都不再特别依赖人去做这件事情，而且 DBA 也不是靠手做这个事情，DBA 也是靠一些工具、脚本或者数据库厂商提供的工具，那么这些工具和硬件、业务之间的适配就需要人去完成。但如果这件事情，已经非常的自动化，那么还需要一个人专职或者一个团队专职去做吗？我表示怀疑。
反方：李真旭 speaking ——
我觉得第一，大家对 DBA 的工作认知有差异，好像 DBA 只做一些基本的安装部署备份工作，虽然这些工作确实是 RDS 具备的功能，但是哪怕是 AWS，限制也是很多的，有很多功能都满足不了。
第二，很多人认为的刷个 MySQL、搭个主从复制、布个监控这些，都是比较初级的 DBA 干的，真正的 DBA 已经不是一个单纯的数据库管理员了，硬件、网络、存储、主机、系统、数据库他都懂一些，你可以把他理解为是一个小企业的 CIO 都可以。他的决策权还是比较大的，至少他对信息点的把控是比较好的，他能够去决策要用什么硬件、用什么数据库、什么型号才能满足业务的要求，而不是单纯的做备份装监控，这个太狭隘了。
第三，就算 RDS 能够满足用户的绝大部分需求了，大家也会发现一个问题：据统计，数据库里面，80%的问题都不是因为你的硬件或者你的网络，而是由于应用本身的代码写得不好导致的，比如说一下子上来就把 CPU 打满了，这时候你觉得 RDS 还能帮你解决这个问题吗？我认为是解决不了的，顶多就帮你评估一下，告诉你怎么加索引，仅此而已。它还没做到那么智能。
除了保证数据库的安全高效、稳定运行，DBA 还可以向外输出，让业务更有价值。比如说赋能研发，给他们培训怎么写 sql，让他们开发变得更高效。
反方：薛晓刚 speaking ——
我认为 DBA 并不仅仅只是懂数据库，还涉及到操作系统中间件，从哪来的到哪去，这些都是要知道的。就像李真旭老师说的，选型还是 DBA 更懂。
此外，DBA 负责的是设计、测试、部署、交付……全生命周期的数据库管理。我现在所在的企业做数据治理、数据标准化，其中就提到了一个事情：建模。业务模型、逻辑模型、物理模型，这些东西都是要参与甚至主导的，而这些，云都不能给你做，更不用说很多企业都用不了公有云了。
我在甲方工作了将近20年，以我的工作经验来说，很多东西是不能优化的，它在设计的时候就已经出问题了。像数据库对象设计，有的数据类型都选错了，视图函数都建错了，在这种情况下，优化要么是没有力度的，要么是收效甚微的。我接触的传统行业就是这样的，如果开发都不知道数据库有什么特性，不管你在云上云下，他都不会用啊。所以，我们带着开发去做、去用这个数据库，才能真的让开发提升效率。
02 DBA 的可替代性有多强？
反方：薛晓刚 speaking ——
说到 DBA 的可替代性，我觉得在国内是很难被替代的，因为这个职位比较关键。像我在公司属于重点对象，因为我掌握着所有数据库的用户密码。有一次我接触支付行业，人行的老师来检查我们牌照的时候说，有些开发你外包就外包了，甚至网络外包就外包了，但你的数据库不能外包，你必须放在自己手里，这是人行的监管要求。
正方：李令辉 speaking ——
我和各位背景不一样，我来讲一下从研发的角度看 DBA。
首先，我们在互联网公司的时候不太可能会让 DBA 去准备业务架构，因为业务是由产品经理根据业务需求定的，别说 DBA 了，研发都没有资格去评价这个业务需求提得合不合理，没有需求是不合理的。DBA 也没这个权限。毕竟，技术是服务于业务的，而不是业务来适配技术。技术如果做不到，最简单的办法就是换一批人，让能做到的人去做。
其次，薛老师刚才讲的这一点，有点偷换概念，那不叫“DBA 不可替代”，那是您二位不可替代。您二位水平已经不能叫简单的 DBA 了，在这种情况下去佐证 DBA 的不可替代性不合适。就好像说一个司机掌握了我们全公司所有门的钥匙，所以这个司机不可替代。可是，所有的司机都能掌握您的钥匙吗？不能。任何行业都能出状元，但你这个状元的发展，和行业的平均水平并不是直接有关的。您不可替代，不等于 DBA 不可替代。这两件事情，不要混淆。
第三，您刚才说您有所有的密码，这在我看来恰恰很危险，谁能保证您的人身没有风险？谁能保证您的可用性足够？谁能保证您的记忆力没有问题？如果一个技术团队的领导容忍这样的事情普遍发生，那么是他的不称职。如果密码一定要交给一个人的话，我宁愿交给一个可靠的服务。这个服务出问题的概率，至少比人低多了。
我们公司以前的运维就是这样，地位确实有，但我们希望他们不要一起吃饭，不要一起出行。虽然我们降低了风险，但是把这件事情强加于纪律去控制人，确实不对。实际上也是，我们怎么知道他们业余生活在不在一起玩，坐不坐一架飞机？根本不知道。所以，既然我们是做技术行业的，我们就应该通过技术来解决这个问题。
正方：马工 speaking ——
刚才反方说 DBA 的配置很简单，不是什么问题，我不这么认为，我认为目前搭建的数据库都有严重的缺陷。刚刚薛老师说掌握了所有数据库的密码，这恰好说明，你们的访问控制是没有做的。对企业来说，安全等级非常低，完全依靠于内网、依靠网络工程师做的网络隔离。
如果我用 telephone 在云上做一个数据库，我可以做到任何一个数据库只被它需要访问的那个 application 去访问。举个例子，如果是分区的话，北京的应用只能访问北京数据库的某一行，或某一个 table。这都不需要 DBA 来配置。
在这个项目里，密码在任何时候都不会以名为形式向任何人公布。比如说我们用 telephone 生成一个密码，然后马上把这个密码直接传到云上的 secret manager，应用需要密码的时候，再用它的 IAM 访问 secret manager 把密码拿过来。全程密码不会在任何一个显示器里面出现，没有人能偷到；它也不落盘，只在内存里使用；最后我会定期去更新。所以在这一点上，我觉得 DBA 做的数据库还没我一个开发用 telephone 做的密码安全。
另外，有了云数据库后，已经不需要 DBA 来恢复数据库状态了，因为所有的数据库默认开启了异地备份，出问题直接把备份拿过来就行了。在这个意义上，我看到的不仅是初级 DBA 被淘汰，高级 DBA 的市场也越来越小。
最后是晓刚说的建模和数据质疑，但是抱歉，那不叫 DBA，人家有专门的岗位，叫 data engineer，数据工程师，跟 DBA 完全不一样，发展路径不一样，来源背景也不一样，这是我的观点。
反方：李真旭 speaking ——
但这个异地备份它不是实时的。万一用户对数据要求很高，怎么办？
正方：马工 speaking ——
这个场景只有万分之一，万分之一的话不需要一个专门的 DBA，全中国可能只需要你一个人就可以了。这个岗位不足以成为一个专职岗位，不需要每个公司都配备，也不需要年轻人去学习去复制去成为你。
反方：薛晓刚 speaking ——
但是目前来说，人行监管就是要求数据库要在自己手里。还有很多不能上云的企业，你们也没有考虑到。掌握密码这个事，很多公司都会有一定的机制保障，今天薛晓刚走了，明天会来一个李晓刚。这个岗位不是因我而设的，它就在那，谁来坐都一样。
李令辉老师说，技术是服务业务的，这我不赞成。技术是要指导业务的。我经历过很多这种事，学员给我的东西，我问起，他就说业务就这么要求的，就像李老师说的“业务就是这样的”，但业务真的是这样吗？开发说，我不知道，反正业务是这么说的。当你把业务拉过来，再一起问一下，业务就说：我没要求，是你理解错了，或者我这个需求也提错了。你们怎么看？这种现象，在我们日常工作中是非常普遍的。
03 云数据库也不是万能的
反方：薛晓刚 speaking ——
我处理过几个朋友的问题，他们是创业公司，用的都是阿里云，跑得比别人快，但是都出现过宕机问题，比方说一周宕机一次，严重影响业务开展。我去看了，基本上都是 SQL 问题，背后是数据库和 SQL 的逻辑问题。阿里云并不能帮他们解决什么，我就告诉他们怎么改，这两家公司按照我的要求改了，业务再也没宕机过。你看，云并不能帮他们弄清楚业务的问题，改逻辑或者改 SQL ，甚至是改设计，这些都是做不了的。当然你可以说这属于高级的 DBA，但是高级的 DBA 也是从初级走过来的。
反方：李真旭 speaking ——
第一，我认同薛老师的观点，如果没有 DBA 这个岗位的话，可能会导致应用和运维脱节。因为开发人员可能并不能很好地使用数据库，并不是说把数据库换成 RDS 之后，开发就能够把 RDS 用好，这个是不一定的。
第二是关于数据的隐私问题，特别是去年，很多大厂出了事故，闹得很大，我就不展开了。
第三，这两年经济下行，我觉得大家可能会更关注成本。比如说，阿里云，我发现它居然也支持 Oracle 在上面跑，RDS for Oracle，假设我要买一个企业级的数据库，比如说64核，成本大概是一年42000多美金，其实并不便宜。国内的话，一年算下来，大概也要70多万，够我买高配的物理机了。
所以综合下来看的话，RDS 优势也并不大。
正方：马工 speaking ——
针对薛老师说的“阿里云不帮用户解决性能问题”这一点，我认为可以用机器学习来解决。这里有一个例子，Amazon for RDS，它把常见的一些数据库问题给喂进去，云上也会有 performance insights，大多数的常见问题都不难，你看了就能定位出问题在哪。如果你会用的话，你需要专家的概率其实是非常低的。当然，我不能保证说这两个工具加起来之后，你就不需要薛老师这种专家了，但是需求量不大，可能全中国有三五个薛老师就够了。所以还是那个问题，三五个薛老师不构成 DBA 这个岗位，不构成一个行业。
反方：薛晓刚 speaking ——
马老师说到的工具我们也有，大部分工具也是自动化的，但是单纯指望工具太理想化了。很多人是“我知道有问题，但我不知道怎么改，你得手把手教我”，我每次告诉他问题在哪给出建议还是不会改，我要写个 demo 给他看，告诉他怎么样改，告诉他你要是实在不会写，我用 java 给你写一段，你照着抄……要这样才行。在我国大部分情况下，你告诉他这个有问题，但不告诉解决方案，他根本不知道怎么改。
正方：李令辉 speaking ——
咱们从技术角度来看这个问题，你说 RDS 好不好？我觉得 RDS 确实不好。打一个现实中的比喻，就像现在大家都用电车了，RDS 它就强行在自己油车的油箱边上加了个电机，所以 RDS 才会显得这么别扭。
RDS，它是一个半成品，它是互联网公司用单机时代的软件去解决云时代问题的一个尝试。这个尝试解决了互联网公司当时的问题，你说这些互联网公司自己有没有 DBA？肯定有，我就在这个 DBA 团队。每个互联网公司包括 AWS、Google，他们都有 DBA。所以 DBA 他们是需要的，只不过没有那么多，可能几十人就不错了。
但是，这是未来吗？我认为不是，纯电车是未来。我小时候去我爸单位，他们有那个手动机床，有些老工人非常的专业，能做出很漂亮的东西，但是现在你看，制造业都已经是数控机床了。只要你把时间给够，该发生的事情一定会发生。
在我看来，云数据库应该是和现在的 RDS 完全不同的，不应该利用 RDS 以前单机数据库利用网络来做网络备份这种方式来做数据冗余，来做高可用，来做什么 IP 切换这种很 low 的办法。云数据库现在的底座就是整个云，在一个对象存储上面有一些算力，这些算力使用临时存储，这就是为什么在云上自建数据库并不好用的原因，因为 EBS 很贵，单机存储它又不可靠，它天生不是为了 durability 设计的，也不是为了性能和 latency。
在云时代，一个云数据库，可以在一个共享的对象存储下。这个对象存储和传统的单机存储最大的不同是它可以随意扩展它的存储量。也就是说，你在传统的机器上一个进程高性能地访问这个磁盘，别的进程就没有 IO 能力了。可是在现代的云上面，对象存储不是这样，它是可以动态扩容的。当我有十台虚拟机去访问的时候，各自的带宽是独立的。云可以在很短的时间内把流量扩过去，存储量横向扩展。这就带来了在传统的单机上绝不可能有的一种体验。以前，我们要担心的是螺丝壳里做道场，怎么有效地利用资源，有效地节省 IO，但现在都不存在这些问题。所以我们要做的是什么？我们要在一个新的基础建设上，做一个新的适配的软件，软件永远是在硬件的基础上服务业务。
04 普通 DBA 该怎样应对 RDS 的挑战？
反方：李真旭 speaking ——
短期来看，从国内来讲，机会还是很多的。现在大批的关系数据库厂商，在未来三到五年会迎来一个考察的过程，这个时候我觉得对 DBA 来讲，是个转型升级的好机会。现在很多客户用的数据库，还在做 Oracle 或 MySQL 兼容，如果你对这个比较了解，去做另外一款数据库也是有优势的。
至于说未来的职业发展，从长远来看，DBA 的需求量是会越来越少的，但是不代表这个行业它会消失。初级的 DBA 可能会被软件自动化取代，我们需要做的是更深入，对数据库至少要比开发人员理解得更深入。
反方：薛晓刚 speaking ——
那些非核心竞争力的基础运作，由自动化工具代劳之后，我们这些从业者能从战术层面走到战略层面，我去管开发，我去管业务，就是技术指导业务嘛。只要有数据库，都会有 DBA，如果哪天真的出现了，不要数据库了，那我们可能去干些别的。现在没有云的，还是按没有云的做法；如果有云，那就可以借云数据库从幕后走向台前。
正方：马工 speaking ——
如果你是个从业者，那你要好好考虑，作为一个职业生涯目标，你要想象它的长期可能性。长期来看，客户是不是会归拢到某几个大型的数据库，会不会大量的使用？如果是这个趋势的话，那 DBA 的岗位需求是会越来越少的。我的建议是，不要把自己固定为一个 DBA，你就是个工程师，只不过以前有点偏好于数据库或者数据建模。你只要把自己当成工程师，所有的工具都只是你工程师工具箱里面的一个，你今天选了个 Oracle DB，明天选个 type-script 都是 ok 的。云也只是一个工具，不是你的敌人，可以拿过来用。最后，作为一个工程师，你一定要对团队有价值。
大家对此怎么看呢？快留言说说你的经验吧~
直播回放如下，错过的赶紧扫码看看回放↓↓↓
