DBA会被云淘汰吗？

Original 冯若航非法加冯

前天主持了开源漫谈第九期主题《DBA会被云淘汰吗？》，我很后悔当了主持人而不是辩手，全程克制着自己亲自下场的冲动。因此写下了这篇文章，表达一下我自己的观点：

DBA 会被云淘汰吗？

DBA帮助用户用好数据库

用好数据库的能力很稀缺

DBA的工作与自动化管控

云数据库的模式与新挑战

打破云数据库的核心壁垒

如何面对云数据库的冲击

DBA帮助用户用好数据库

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

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

DBA的第一点价值在于安全兜底：他是企业核心数据资产的守护者，也是可以轻易对企业造成致命伤害的人。在蚂蚁金服有个段子，能搞死支付宝的，除了监管就是DBA了。高管们通常也很难意识到 DBA 对于公司的重要性，直到出了数据库事故，一堆CXO紧张地站在DBA背后观看救火修复过程时…。

DBA的第二点价值在于ROI优化。许多公司并不在乎他们的查询是纯狗屎，他们只是觉得“硬件很便宜”，砸钱买硬件就好了。然而问题在于，一个调整不当的查询/SQL或设计不当的数据模型与表结构，可以对性能产生几个数量级的影响。而且总会在某一个规模，堆硬件和用云数据库的成本相比雇佣一个靠谱DBA的成本高得令人望而却步。我认为大多数公司在IT软硬件开销中花费最大的是：开发人员没有正确使用数据库。

在《DBA还是一份好工作吗》一文中，我们已经讨论过了 DBA 的工作职责与价值所在。数据库是信息系统的核心，而 DBA 帮助用户用好数据库。如果说数据库是一辆车，那么 DBA 就是司机与赛车手。

然而，云数据库服务的出现对 DBA 产生了挑战 —— 云数据库的真正的竞品不是其他商业/开源数据库内核，而正是 DBA 本身。这就跟出租车公司要取代的不是汽车厂，而是全职司机一样。云数据库使用的数据库内核本身也主要是基于开源的，因而 RDS 和 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 经过长期建设，也许 90% 的工作内容都高度自动化了 —— 比如连硬件故障都靠高可用管控自愈了。假如 DBA 救火/优化/指导/管理只需要 10% 的时间，那么剩下 90% 的时间就可以自由支配：无论是继续改善管控软件实现利滚利，或者学习内核源码翻译书籍，或者单纯就是像 DBA 的先辈 —— “图书管理员“ 那样在图书馆里喝茶看报都可以，好不惬意。

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

云数据库的模式与新挑战

云数据库为什么会对 DBA 构成威胁？要解释这个问题，我们就需要先来聊一聊云数据库 RDS 的用户价值。云数据库的核心价值是 “敏捷” 与 “兜底”。至于什么 “便宜”，“简单”，“弹性”，“安全“，”可靠” 其实都不是核心，甚至也不一定真的成立。

所谓 “敏捷” —— 翻译过来就是为用户省掉几个月的建设阶段工作，一步到位进入维护阶段。所谓 “兜底”，就是指用户真正出现疑难杂症，真正需要顶级 DBA 的高智力带宽时，云厂商为用户通过工单的方式提供保障 —— 至少你确实能摇到人来管一管。

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

这些沉淀了 DBA 经验的管控软件，就成为了云数据库的核心生产资料与摇钱树。核·月单位成本20块钱的硬件资源，套上管控软件，就能卖出 300～400（Aliyun），甚至 400～ 800（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 看来，这就是不上档次的大锅饭。但是这种大锅饭对于腰部以下的用户来说，已经是珍馐了 —— 他们需要的就是这种大锅饭，而且比起采购天价的商业数据库与聘请稀缺的数据库老司机，RDS 大锅饭确实配得上一句“物美价廉”。

实事求是评价一下数据库服务的水平，并用百分制打分的话。那么顶级DBA的自建水准可以到 95～100 分，优秀 DBA 自建能达到 80 分上下；云数据库的水平大约在 70 分。中级 DBA 土法自建也就大概 50～60 分，初级DBA土法自建也就三四十分，运维兼职搞的土法自建可能只能打个几分。

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

所以，RDS 对 DBA 确实产生了影响与冲击。而这个冲击是结构性的：极度稀缺的顶尖 DBA 不仅不受影响，还更加吃香，一直会是云厂商争相笼络招安拉拢的香饽饽。而胸部以下的 DBA ，或者说自建水平达不到 70 分的 DBA ，就会直接面临云数据库服务的生态位竞争与替代挑战。

对于 DBA 这个行业来说，这不是一件好事 —— 因为高级 DBA 都是从初级，中级 DBA 成长起来的。如果诞生培育这些初中级DBA的土壤 —— 中小公司的数据库应用场景都被云厂商截胡，那么这个行业金字塔就会被腰斩掉，顶级DBA的增量被断掉，存量被蚕食，最终也会成为无根之木。

打破云数据库的核心壁垒

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

DBA 们想要与云数据库竞争，采用路德分子抵制技术进步的方式是没有用的。而应当用 “你强我更强” 的方式提高自己相对于云数据库的竞争力。而要做到这一点，DBA 需要用更低的成本，提供比RDS更高的价值。

要做到这一点，核心在于 “敏捷” 与 “兜底” 这两个问题：首先，把几个月的建设周期缩短到几天甚至几小时，而且能达到七八十分的水平，做到“敏捷”。其次，真的出现疑难杂症问题时，能够摇到顶级DBA来“兜底”。

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

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

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

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

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

如何面对云数据库的冲击

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

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

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

我也不靠 Pigsty 来赚钱，和许多数据库服务公司一样，靠的也是提供专业的咨询与服务，而不是兜售 Pigsty 这个管控软件本身 —— 这不是资本市场喜欢听的那种 “Scale to the Moon” 的故事，但确实可以造福社区，解决用户的痛点需求 —— 但试问，我一个人再牛逼，用 Pigsty 交付能让我这个个体户同时打多少份 PG DBA 的工？也许能服务几十到一两百个客户。但 Pigsty 可以让每一个 PG DBA 老司机都加上这样的杠杆，去为社会提供真正有价值的咨询与服务。星星之火，可以燎原，从而卷翻云数据库！

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

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

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

有很多云厂商内部的数据库老司机都敏锐地洞察到了这个趋势，选择脱离云自己出来单干！从Aliyun出来的就有好几位 —— 唐成老师的乘数科技，曹伟老师的Kubeblocks，叶正盛老师的 NineData，等等，而我某种意义上也算一个。所以即使是云数据库厂商内部的团队，也不是铁板一块。

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