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专家是屈指可数的，而垄断少数几个专家的难度比起干翻开源数据库要简单太多了。垄断不了数据库产品，就垄断用好它的能力！

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

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

DBA的工作与自动化管控

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

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

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

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

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

所以 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乘数”，可以十个坛子甚至上百个坛子一个盖。充分释(ya)放(zha) DBA 老司机的空闲时间与剩余价值，用较低的人力成本，为更多的客户提供“兜底”服务。解决了 “用好数据库能力” 非常稀缺的问题，并赚的钵满盆翻。

如果让我来实事求是的评价云数据库服务的质量水平，用百分制打分的话。那么顶级DBA的自建水准可以到 95～100 分，优秀 DBA 自建能达到八十分上下；云数据库的水平大约就在 70 分。可是中级 DBA 土法自建也就大概五六十分，初级DBA土法自建也就三四十分，运维兼职的土法自建可能也就十几分。头部的甲方确实看不上云数据库这种大锅饭，但这对于腰部的用户来说这简直太香了 —— 他们要的就是大锅饭，而比起采购天价的商业数据库与聘请稀缺的数据库老司机，RDS确实配得上一句“物美价廉”。

第一：云数据库是预制菜，直接就能吃，不需要建设阶段；第二：云数据库是廉价七成正确的合格品，而相当一部分初中级DBA土法自建几个月，也都达不到 RDS 这样的水平；第三：云数据库是标准件，降低了DBA天马行空自由发挥带来的不确定性与不可替代性；第四：云数据库提供了共享专家，“兜底”了其余一些对 DBA 的需求，也解决了出问题摇不到人或者遇人不淑的担忧。所以对于那些规模偏小，水平一般的甲方用户来说，云数据库比起招聘培养一个初中级 DBA 自建很有吸引力。

云数据库服务对 DBA 的冲击是结构性的。极度稀缺的顶尖 DBA 不受影响，一直会是云厂商争相笼络招安拉拢的香饽饽。而胸部以下的 DBA ，或者说自建水平达不到 70 分的 DBA ，就会直接面临云数据库服务的生态位竞争。对于 DBA 这个行业来说，这不是一件好事 —— 因为高级 DBA 都是从初级，中级DBA 成长起来的。如果诞生培育这些初中级DBA的土壤 —— 中小公司的数据库应用场景都被云厂商垄断截胡，那么这个行业金字塔就会被腰斩掉，顶级DBA的增量被断掉，存量被蚕食，最终也会成为无根之木。

打破云数据库的核心壁垒

云数据库会是未来吗？云数据库会像 “汽车替代马车” 那样革掉 DBA 的命吗？我不这么想，因为有力就会有反作用力。与时俱进的 DBA 们会用工具武装自己，重新回到舞台中央与 RDS 同台竞技。

DBA 们想要与云数据库竞争，采用路德分子抵制技术进步的方式是没有用的。而应当用 “你强我更强” 的方式提高自己相对于云数据库的竞争力。而要做到这一点，DBA 需要用更低的成本，提供比RDS更高的价值。要做到这一点，质量、安全、可靠的部分我都不用担心 DBA 的专业能力，核心在于 “敏捷” 与 “兜底” 这两个问题：

首先，把几个月的建设周期缩短到几天甚至几小时，做到“敏捷”。

其次，真的出现疑难杂症问题时，能够摇到顶级DBA来“兜底”。

解决前者要靠 管控软件，解决后者，要靠DBA老司机。而前者的紧迫性要远远高于后者 —— 建设良好的系统也许跑个几年都不会遇到需要 ”兜底“ 的问题，让普通 DBA 人人都成为老司机也不现实。而如何敏捷、低成本的拉起一套 70 分以上的数据库服务体系，是 DBA 应对 RDS 挑战的核心问题。

而这，正是我发起 Pigsty 这个开源项目的初衷 —— 提供一个完全开源免费，且质量更好的 RDS PG 替代品。让普通的DBA/研发/运维人员都能以同样的敏捷的方式迅速建设交付 80分+ 的本地 RDS 服务！彻底解决掉第一个问题。而我自己的商业模式是咨询与服务，为这些疑难杂症提供商业支持与最后兜底，解决第二个问题。

一个开源且足够好的数据库管控软件，会直接颠覆云数据库的商业模式。举个最简单的例子，你完全可以拿同样具有弹性的云服务器 ECS 和云盘 ESSD，使用开源管控来自建 RDS 服务。在不损失云所鼓吹的“弹性”与“敏捷”以及各种RDS好处的前提下，在不需要额外的人手的情况下，立竿见影的省掉 60% ～ 90% 不等的 “纯RDS溢价”。如果在使用自有服务器纯自建的情况下，能带来的降本增效水平恐怕会超出绝大多数用户的认知。

Pigsty 会重新设置云数据库服务的基线水平，所有质量不及它的PG管控软件价值都会逐渐萎缩归零，这是数据库管理领域的核武器扩散，是站在道德高地上的开源倾销。和当年开源数据库掀翻商业数据库的桌子是一模一样的，只不过这一次发生在了另一个维度 —— 管控软件 上。Pigsty 为所有 PG DBA 立即装备上了瞬间完成高水平数据库服务建设与交付的魔法棒，也让更多的研发/运维可以扮演 PG DBA 的角色，瞬间量产出大量的初级 DBA 来。

当然作为开源的管控软件，Pigsty 确实和云数据库管控一样，替代了很大一部分的 DBA 工作内容，特别是运维性的部分。但和云数据库不一样的是，它掌握在 DBA 自己的手中，由DBA所拥有，控制，使用，而不是只能向云计算领主去租赁并”替代“DBA。更强生产力带来的闲暇时间红利与DBA乘数杠杆，会直接普及到每一个从业者手中。而这，就是我作为一个顶尖DBA对于 RDS 挑战的回复。

如何面对云数据库的冲击

对于广大初中级 DBA 来说，我认为应对云数据库挑战的最佳办法就是立即放弃周期长，效果良莠不齐的土法自建尝试，直接拥抱成熟的开源管控软件，快速放大自己相对于云数据库的竞争力 —— 这一部分是完全开源免费，掌握在你自己手中的生产资料与能力。如果需要疑难杂症兜底，我非常乐意以一个相比于云数据库极有竞争力的价格提供支持、咨询与答疑。

请不要再来问我：PostgreSQL 高可用如何做？PITR 备份恢复怎么搞？可观测性与监控系统如何搭建？如何用配置IaC管理几百套数据库集群？连接池如何配置管理？负载均衡与服务接入怎么做？上百个扩展插件如何编译分发打包？主机参数怎么调优？上线/下线/扩容/缩容/滚动升级/数据迁移这些怎么做？这些你真正会遇到的问题，也是我曾经遇到的问题，而我已经在 Pigsty 中我都给出了工具化的最佳实践与版本答案，并配有 DBA SOP 手册，让小白也能快速上手玩起 DBA Cosplay。

对于顶级DBA与同侪们，我倡议合力打造开源共有的管控软件，并基于此提供专业数据库服务。与其你搞一套云管，我搞一套云管，投入大量的研发人力搞低水平、重复性的建设，倒不如凝聚起来打造公有的开源管控，打造中国社区里真正有世界影响力的开源项目品牌。Pigsty 是一个很不错的候选开源项目 —— 在当下，它已经成为中国人主导的 PostgreSQL 生态开源项目中排名最前的项目了。它也许有机会成为 PostgreSQL 世界中的 Debian 与 Ubuntu，但这取决于所有每一个贡献者与每一个用户。

我也不靠 Pigsty 来赚钱，和许多数据库服务公司一样，靠的也是提供专业的咨询与服务。这也许不是资本市场喜欢听的那种 “Scale to the Moon” 的故事，但确实可以解决用户的痛点需求。我一个人即使再牛逼，能打 200 份 PG DBA 的工吗？不能！但 Pigsty 这个管控工具可以让每一个 PG DBA 老司机都加上这样的杠杆，去为社会提供真正有价值的咨询与服务，从而卷翻云数据库！

例如提供 MySQL 专家服务的 Percona ，负责 PostgreSQL 部门的头 Umair Shahid 就很敏锐地看到了这个趋势。他从 Percona 出来，成立了自己的创业公司 Stormatics 来提供专业 PostgreSQL 服务。他没有自己再 “研发” 一套什么 PG云数据库管控平台之类的东西，而是直接使用 Pigsty 进行系统交付。同样也有一些意大利，美国，国内的数据库公司在使用 Pigsty 交付 PostgreSQL 服务。我对此表示热烈欢迎、并愿意提供支持与帮助。

数据库产品的模式正在消亡，而数据库咨询与专家服务的模式方兴未已。用好数据库是一个门槛很高的领域，即使强如下云先锋 DHH，抠门大王也依然会有一笔采购 Percona MySQL 专家服务的开销来请专业的人解决专业的问题。比起出卖尊严去包装换皮套壳吹牛撒谎打造使用价值微乎其微的（Minor PG fork） “新数据库内核产品” ，倒不如堂堂正正地去为用户提供真正有价值的数据库专家咨询与服务 。

在当下，服务器硬件资源非常便宜，数据库内核软件开源免费且足够牛逼，现在，如果管控软件不再被云厂商垄断，那么提供完整数据库服务的核心要素，就只剩下了用于兜底的专家能力！AI 与 GPT 的出现更是让单个数据库专家的杠杆乘数放大到一个惊人的地步。

所以，有很多云厂商内部的数据库老司机都敏锐地洞察到了这个趋势，选择脱离云厂商自己出来单干！比如从阿里云出来的就有，唐成老师的乘数科技，曹伟老师的Kubeblocks，叶正盛老师的 NineData，等等等等。所以即使是云数据库厂商内部的团队，也不是铁板一块。团队也在剧烈变动，凋零失血，人心思变中。

我相信未来的世界，不会是一个云数据库垄断的世界。各家 RDS 管控的质量水平长期止步不前，已经达到了场景土壤所容许的能力天花板。而顶尖 DBA 的经验沉淀下来的生产力工具则更进一步，让许多腰部 DBA 面对 RDS 都能重新有一战之力。与时俱进的 DBA 们会用工具武装自己，与 RDS 同台竞技。而我愿意替天行道，扛起下云与自建替代的大旗，开发这些管控软件与工具并普及到每一个DBA手中，帮助 DBA 打赢反抗云数据库的战斗！