知方号

知方号

DBA会被云淘汰吗?<粉笔会被淘汰吗>

DBA会被云淘汰吗?

微信公众号原文

前天开源漫谈第九期主题《DBA会被云淘汰吗?》,我作为主持人全程克制着自己亲自下场的冲动,因此特此写了这篇文章来聊聊这个问题 : DBA 会被云淘汰吗?

DBA帮助用户用好数据库

很多地方都需要DBA:糟糕的模式设计,奇烂的查询性能,鬼知道有没有用的备份;等等等等。可惜的是,从事软件工作的人中,很少有人了解什么是DBA。成为DBA,意味着与研发人员创造的熵进行永无休止的战斗。

DBA,Database Administrator,数据库管理员,以前也叫做数据库协调员、数据库程序员。DBA是一个横跨于研发团队与运维团队的广博角色,涉及DA、SA、Dev、Ops、以及SRE的多种职责,负责各种与数据与数据库有关的问题:设置管理策略与运维标准,规划软硬件架构,协调管理数据库,验证表模式设计,优化SQL查询,分析执行计划,乃至于处理紧急故障以及抢救数据。

许多公司都会雇用DBA,传统的 DBA 类似 Cobol 程序员,除了科技公司/初创企业外:那些听上去不那么Fancy的制造业,银行保险证券、以及大量运行本地软件的党政军部门,也大量使用了这些关系型数据库。单花在这些商业数据库软件授权上的费用可能就有六七位数,加之相近的硬件成本与服务订阅成本。如果公司已经砸了成百上千万的钱在数据库软硬件上,那么再花一些钱雇佣一些专职专家来照顾这些昂贵且复杂的数据库,就是一件很自然的事情,这些专家就是传统的 DBA。

接下来随着 PostgreSQL / MySQL 这些开源数据库的兴起,这些公司们有了一个新选择:不用软件授权费用即可使用数据库软件,而它们也开始(不理性地)停止为数据库专家付费:维护数据库的工作被隐含在了研发与运维的附属职责中,而这两类人通常:既不擅长、也不喜欢、更不在乎照顾数据库的事情。直到公司的规模足够大,或者吃到足够的苦头之后,一些Dev/Ops才会培养出相应的能力来,成为DBA —— 不过这是相当罕见的事情,而这也是今天我们讨论的主角 —— 开源数据库的 DBA。

用好数据库的能力很稀缺

培养开源数据库 DBA 的核心要素是场景,而有足够复杂度和规模的场景是极其稀缺的,往往只有头部的大甲方才有。就好比国内 MySQL 的 DBA 主要产自重度使用 MySQL 的淘宝等互联网头部公司。而优秀 PostgreSQL DBA 基本上都出自去哪儿网、平安银行、探探这几个大规模使用 PG 的公司。顶级的开源数据库 DBA 的来源极其有限,基本是在顶级甲方用户中精通数据库的运维/研发,靠着真金白银的大故障与复杂场景的建设经验,才能零星砸出来几个。

以中国的 PostgreSQL DBA 为例,根据圈内纯技术文传播阅览量,圈子规模大概在千人左右;但能建设架构超过 RDS 水准的数据库系统的 DBA 就收敛到几十个了;能自己打造更好的 RDS ,甚至做到对外复制输出最佳实践的更是凤毛麟角,一只手就能数过来。

所以,当下数据库领域的主要矛盾,不是缺少更好更强大的新内核,而是极度匮乏用好管好现有数据库内核的能力 —— 数据库太多,而司机太少! 数据库内核已经发展了几十年,在内核上的小修小补边际收益已经很小了。而像 PostgreSQL 这样成熟开源数据库内核引擎出现,让卖商业数据库成为一门糟糕的生意 —— 开源数据库不需要高昂的软件授权费用,那么能用好这些免费的开源数据库的老司机 —— DBA,就成为了最大的瓶颈与成本。

在这个阶段,高级的经验都“垄断”在少数头部专家手中。实际上,这正好是开源真正的“商业模式” —— 创造高薪的技术专家岗位。然而这也出现了一个新的机会 —— 商业数据库产品因为开源替代的出现已经很难形成垄断了,但能用好开源数据库的DBA专家是屈指可数的,而垄断少数几个专家的难度比起干翻开源数据库要简单太多了。垄断不了数据库产品,就垄断用好它的能力!

阶段名称特点“商业模式”阶段1商业数据库商业数据库软件垄断了数据库产品供给。天价软件授权阶段2开源数据库开源打破了商业数据库垄断,但技术垄断在少量头部开源专家手中。高薪专家岗位阶段3云数据库云打破了开源专家技术垄断但在用好数据库的能力上形成垄断管控软件租赁阶段4“云原生?”开源管控软件打破了云管控软件垄断用好数据库的能力普及到千家万户咨询保险兜底

所以,尽可能招揽能用好开源数据库的专家,打造一个共享专家池让稀缺的高级 DBA 得以时分复用,并和 DBA 经验沉淀而成的管控软件一起打包成服务出租,就是一种非常有利可图的商业模式 —— 而云数据库RDS 正是这样做的,并赚的钵满盆翻。

云数据库使用的内核本身是开源免费的,所以云数据库提供的核心能力,正是和 DBA 一样的,帮助用户用好数据库的能力! 它真正的竞品不是其他商业数据库内核,或者开源数据库内核,而是 DBA —— 特别是处于中下游位置的 DBA。这就跟出租车公司要取代的不是汽车厂,而是全职司机一样。

DBA的工作与自动化管控

除了 DBA 人力,还有什么办法可以获得用好数据库的能力?那我们就需要先来看一看 DBA 的工作模式。

DBA的工作在时间上主要分为建设与维护两个阶段。在最初几个月的密集建设阶段会比较幸苦,需要负责搭建成熟的技术架构与管理体系;而当自动化建设完成,进入了维护阶段后 —— DBA的工作就要轻松很多了。

建设阶段维护阶段管理层数据库选型,制度建设数据库建模,查询设计,人员培训,SOP积累,开发规约应用层架构设计,服务接入SQL审核 / SQL变更 / SQL优化 / 分库分表 / 数据恢复数据库层Infra建设,数据库部署备份恢复 / 监控告警 / 安全合规 / 版本升级 / 参数调优操作系统层OS调优,内核调参存储空间管理硬件层测试选型,驱动适配(更换备件)

体系建设并不是一蹴而就的一锤子买卖,而是一个水平随时间对数增长的演化过程。有兴趣研究折腾的DBA会持续致力于更高水平的自动化建设,将建设过程浓缩为可复制的经验、文档、流程、脚本、工具、方案、平台、管控软件。管控软件也许是目前 DBA 经验沉淀的终极形态 —— 用软件代替自己干 DBA 的活儿。

管控系统的自动化水平越高,维护阶段所需的维护人力就越少。但是对于 DBA 水平的要求也就越高,所需的建设投入与时间周期也就越长。所以在某一个平衡点上,或者是自动化程度撞上了 DBA 水平的天花板,或者是高到了威胁DBA 的职业安全,建设演进就会告一段落,DBA 进入“喝茶看报”的持续维护状态。

维护状态的系统,所需的智力带宽会显著下降。在建设完毕的良好系统架构中,如果只是日常性、规范性的工作,水平更低一些的 DBA 也足以维持,对高级 DBA 的时间需求也会戏剧性下降 —— 进入 “养兵千日,用兵一时” 的 “闲置” 状态,只有当出现紧急的故障与疑难杂症时,这些数据库专家老司机才能再次体现出自己的价值。

阶段能力构成普通用户-建设起步100% 专家人力普通用户-维护阶段**30%**管控 + 70% 专家人力顶级用户-维护阶段90% 管控 + 9% 运维人力 + 1% 专家人力

所以 DBA 以前其实是一个非常不错的岗位,经过创业打江山的建设阶段之后,就可以躺在功劳簿上,享受建设成果带来的效率红利。 比如顶级甲方中的 DBA 经过长期建设,也许 90% 的工作内容都高度自动化了 —— 比如连硬件故障都靠高可用管控自愈了。DBA 只需要 10% 的救火/优化/指导/管理时间,那么剩下 90% 的时间就可以自由支配:继续改善管控软件实现利滚利,或者学习内核源码翻译书籍,或者单纯就是像 DBA 的先辈 —— ‘图书管理员“ 那样在图书馆里喝茶看报,好不惬意。

然而 DBA 的这种舒适的生活被云数据库的模式打破了。首先,云厂商拿着已经建设好的管控软件批量复制分发,消灭了数据库建设阶段的重复性工作。其次,如果没有建设阶段,只有维护阶段,而维护工作只需要 DBA 10% 的时间,那么与其用 90% 的时间摸鱼,总会有卷王选择当时间管理大师同时去打 10 份工。云厂商的数据库专家通过管控和共享 DBA,让这个IT领域难得的清闲岗位也卷翻了起来。

云数据库的模式与新挑战

云数据库为什么会对 DBA 构成威胁?要解释这个问题,我们就需要先来聊一聊云数据库 RDS 的用户价值。

云数据库的核心价值是 “敏捷” 与 “兜底”。至于什么 “便宜”,“简单”,“弹性”,“安全“,”可靠” 其实都不是核心,甚至也都不一定真的成立。所谓 “敏捷” —— 翻译过来就是为用户省掉几个月的建设阶段工作,一步到位进入维护阶段 。所谓 “兜底”,就是指用户真正出现疑难杂症,真正需要顶级 DBA 的高智力带宽时,云厂商为用户通过工单的方式提供保障 —— 至少你确实能摇到人来管一管。

云数据库在技术上的核心壁垒,是沉淀了高级DBA经验的管控软件。大部分DBA,包括不少顶级 DBA —— 尽管其本身是数据库管理领域的专家,但却并没有研发能力 —— 可以自己将自己的领域知识与经验沉淀为可复制软件产品的能力。因此通常需要一个研发团队的辅助,来将高级DBA的领域知识转变为业务软件。

这些沉淀了 DBA 经验的管控软件,就成为了云数据库的核心生产资料与摇钱树。核·月单位成本20块钱的硬件资源,套上管控软件,就能卖出 300~400(Aliyun),甚至 800~1300(AWS)这样几十倍的天价来。不过也正是RDS这样线性绑定硬件资源的定价策略,让一部分中级 DBA 现在还能有喘息空间 —— 当 RDS 规模达到 100核以上,招聘一个 DBA 自建维护就会达到 ROI 的转折点了。

管控软件替代 DBA 工作的另一个好处是, DBA 可以加杠杆了!举个例子,如果你的管控软件可以自动化掉 DBA 90% 的工作,那么 同样的活就只需要一个DBA 10% 的时间,可以把一个 DBA 当十个用,所以 DBA 乘数就是10。如果你的管控软件简单易用,门槛很低,让普通运维/开发也能玩 DBA Cosplay,自助完成这 10% 工作中的 9%,那么就只需要专家 1% 的时间了,1个DBA可以当100个用!当然如果未来出现个 DBA 大模型,再把这 1% 的剩余工作替代 0.9% ,DBA 乘数就可以放大到 1000 倍了!

管控软件DBA乘数普通用户-建设起步阶段100% DBA人力1普通用户-维护阶段30%管控 + 70% DBA人力1.43云数据库60% 管控 + 38% 人力 + 2% DBA人力50顶级用户-维护阶段90% 管控 + 9% 人力 + 1% DBA人力100未来状态想象95% 管控 + 4% 大模型 + 0.9% 人力 + 0.1% DBA人力1000

所以,云厂商的模式和 银行很像。有所谓的 “存款准备金率” 和 “DBA乘数”,可以十个坛子甚至上百个坛子一个盖。充分释(ya)放(zha) DBA 老司机的空闲时间与剩余价值,用较低的人力成本,为

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至lizi9903@foxmail.com举报,一经查实,本站将立刻删除。