作者介绍
梁敬彬，担任过福富研究院副理事长、中国电信数据库专家、中盾安信研究院副院长、宁德时代数据专家等职位，著有《收获，不止Oracle》《收获，不止SQL优化》等多本畅销技术书籍，新书《超融合数据库》即将出版。本文内容来源其个人公众号：收获不止数据库（ID：ldbast）
引言
老马是某大公司的资深DBA，某天公司忽然通知裁员，他和徒弟阿牛双双被解雇。半年过去，老马仍未找到工作，而阿牛虽说找到新东家，却只能接受薪资减半的现实。
阿牛的同学大黄，同为DBA，虽未经历裁员风波，却因繁重的工作任务倍感压力，老板不但不肯再招人，还对他的表现颇有不满。
新人小羊，则因在工作中频频犯错，被公司以低绩效为由辞退。
他们都对自己的未来感到迷茫、慌张。
一、不幸的DBA各有各的不幸
老马：我现在真的很慌，在上有老下有小的年纪没了工作，这日子可咋办啊？
阿牛：马哥，要不您试试降低薪资预期，像我这样？
大黄：阿牛，你这话说得轻巧。马哥家里开销那么大，哪能说降薪就降薪？不过我也惨，虽然没被裁也没降薪，但天天加班累成狗，真是快撑不住了。
小羊：有一次，我因为误操作导致产线停产，给公司造成了上千万元的损失，最后直接被辞退了。
老马：哎，看来大家都不容易。我干DBA二十年了，今年真是最难的一年。从工作方向迷茫到彻底失业，现在真不知道该怎么办了。L老师，您有什么建议吗？
L：既然老马提到DBA，那咱们就聊聊DBA是啥含义吧。
小羊：DBA？不就是Database Administrator吗？也就是数据库管理员，负责数据库运维工作，如安装、部署、备份、恢复、诊断、优化、监控、体检、迁移、同步、升级、变更、扩容、缩容等吧？
阿牛：在我们公司，DBA的职责不仅是数据库运维，还包括数据库开发，比如写SQL、存储过程、包、函数、触发器等等。最初运维和开发是分属不同小组的，后来合并了。现在我既要负责运维，又要做开发，忙得团团转。
大黄：我们这边DBA的职责只有运维部分，数据库开发归研发团队负责。但工作量依然很大。生产系统里有上百个数据库，还涉及数十种不同的技术栈，团队成员每个月只能休息一天，实在是吃不消。
老马：我经历过的DBA岗位也都是纯运维，不过却和大黄的忙碌完全不同。公司数据库上云后，运维工作被云端服务商接管，DBA能做的事一下子少了许多。紧接着，公司就把我裁了。都说DBA越老越吃香，我才刚满40岁，就已经找不到工作了。
二、DBA的'DB'非'数据库'而是'数据'与'业务'
L：各位，数智化时代已来，人工智能的崛起也正从根本上改变技术与人类协作的方式。DBA的角色和价值必须重新定位，才能跟上时代的步伐。
老马：怎么重新定义？DBA不是Database Administrator吗？还能是什么？
L：从第一性原理出发，数据库的本质是一个存储和查询数据的工具。它的存在价值在于管理数据，而不是数据库本身。换句话说，数据库的核心在于数据。
进一步从数据的第一性原理来看，数据的存在并不是孤立的，其终极价值在于为业务服务。数据只有在连接业务、解决实际问题时，才能体现出真实的意义。数据和业务是共生体，业务运行产生数据，数据反过来赋能业务，驱动业务优化和发展。
随着数据规模的爆炸式增长和业务复杂度的持续提升，许多问题已经超出了数据库本身的范畴。单纯优化数据库的方式越来越难奏效，因为问题的本质往往与数据的组织方式、流动效率以及业务需求的变化息息相关。当你跳出数据库，聚焦数据和业务时，往往会得到全新的视角，从而快速发现解决问题的根本之道。
因此，我认为，新时代DBA的“DB”不再是Database，而应该是Data和Business。
大黄：听起来很有道理，老师您能展开说说吗？
L：好，我先给大家分享第一个案例。
A企业某套Oracle RAC 双节点数据库，刚上线时运行良好，但一段时间后，实例间GC数据频繁交换，严重影响了性能。Oracle原厂工程师尝试打补丁、调参数，但收效甚微，最后他们建议升级到最新版本来解决问题。可惜从测试环境最新版数据库的运行模拟情况来看，似乎并未有明显的改善。
了解情况后，我提出既然问题源于节点间数据频繁交换，那为何不让两个节点独立处理各自的业务，尽量避免数据交换？不过，这需要满足两个前提，其一是在业务层能确认两节点各进程的独立性，其二是在数据层能确保两节点数据处理量大体相当。
经过技术团队和业务团队的调研分析，证实这一思路可行。于是我们动手改造，一周后问题彻底解决。
阿牛：很受启发，不过您这运气真好，万一场景不符合预想怎么办？
L：不是运气好，而是聚焦数据和业务时带来的新视角，让你思路泉涌，不拘一格，手段层出不穷，从而更易取得成功。
小羊：手段层出不穷？
L：是的。我再分享第二个案例，让你感受一下手段的丰富性。
B企业也是Oracle RAC，依然是GC争用问题，导致数据库偶发宕机。此次原厂工程师建议升级网卡，有提升却无法应对峰值压力。更不幸的是，此次手工指定两节点的模式也不适合，因为在业务层无法保障节点间的数据均衡性，就是你说的“不符合预想”。就在团队一筹莫展时，我抛出一个问题，最终扭转了局面。
小羊：什么问题？
L：我的问题是——能不用RAC架构吗？
老马：啊？
L：经过技术和业务专家们的深入分析，权衡利弊之后，我们果断放弃RAC，改单机+DG。调整后，问题迎刃而解，系统恢复了稳定。
阿牛：您这案例可谓石破天惊，佩服！不过，如果单机支撑不住怎么办？您怎么总是这么好运？
L：这是新视角带来的好运，实则为“强者运强”。
后来，随着业务的发展，单机果然撑不住了。这时怎么办呢？我们从数据和业务需求出发，重新审视现有方案，发现Oracle RAC的高并发及容灾能力并非唯一选择，不少其他数据库产品同样具备类似能力，且在我们的场景中更加契合。
最终，我们选择了某国产分布式数据库。完成迁移后，系统运行平稳，性能大幅提升，问题得以彻底解决。
三、DBA的'A'是'管理员'也是'架构师'
大黄：厉害，我只会就事论事解决问题，时常陷入死胡同。不过，这还和您的影响力有关吧？我就算提出这些建议，大概率也不会被采纳。
L：只会埋头苦干，如何产生影响力？要习惯去思考、去创新、去突破，比如重构DBA含义。
老马：L老师对DBA含义的重构确实很绝妙。对了，DBA的“A”还有没有其他特别的含义？
L：当然有！这个“A”不止是Administrator，还有Architect的含义，不仅是管理员，还应该是架构师。这包含数据架构，业务架构和技术架构。
大黄：老师，您对DBA的要求也未免太高了吧，我能干好自己的一亩三分地就不错。我都快累死了，哪还有精力去接触架构啊。
L：时代来了，这几亩几分地该怎么分，已经由不得你了。你担心地太多会累死，而老马却因为无地可分被裁，不是吗？
老马：哎，伤心事，别提了。
L：“管理”和“架构”的核心，始终是围绕数据和业务，而非数据库。差别在于，管理是运用现有业务框架下已形成的数据，而架构则是规划并实现业务及数据的形成。DBA常常会认为架构与自己无关，但其实，深入架构才是拯救自己的唯一出路。大黄，你就是做事太单一，缺乏视野，才越做越累。
大黄：啊？
L：我再说第三个案例，C企业有Oracle、MySQL、Postgresql、SQLServer、Greenplum等数十种数据库，还包括时序库、GIS库、向量库、图库、内存库等专用数据库，以及一套基于Hadoop生态的大数据平台。在这种技术栈复杂，数据孤岛林立的环境下，DBA手忙脚乱，天天加班，苦不堪言。更糟糕的是，数据间低效的流转与交付严重拖累了企业业务。最终，公司决定开展专项改造。
大黄：哇，这和我的困境一摸一样！接下来怎么改造的？
L：核心在于跳出数据库，站在架构的角度，聚焦业务和数据的形成逻辑，从源头解决问题。
首先，建立全局性的业务拓扑关系和全局数据流向图，在此基础上，实现相似业务合并、多余业务取消、无效业务删减。专用数据通用化、数据集市建设等，具体细节这里不展开。
改造完成后，大量数据库实例实现基于业务规则的整合归并，Hadoop架构被完全淘汰，专用数据库全部迁移到通用数据库中。最终，技术栈简化为原来的一半，数据库套数减少为原来的三分之一。DBA们开心了，因为精简后总体工作量减少了一半以上。老板更开心，因为开发周期缩减了60%，应用平均响应时间缩减了40%。更难得的是，数据库软硬件和人力成本也大幅缩减，这些节省的预算被投入到更有价值的数据挖掘中。
大黄：哇，好羡慕他们啊！我们每天都有处理不完的变更，优化不完的SQL，解决不完的故障。不过现在我看到希望了！我们团队也争取站在架构层面，从源头入手，实现自我救赎。
L：没错。可不能只想着自己的一亩三分地，要做新时代DBA。
四、从DBA到DBA²，似乎一切都变简单了
大黄：嗯，Data、Business、Administrator和Architect组成新时代DBA的定义，太精彩了！对了，Administrator和Architect两者的结合是A+A。要不，咱们把新时代DBA称之为DB2A如何。
L：两者的结合不是简单的能力叠加，而是会产生质的飞跃，尤其是在人工智能大模型技术飞速发展的当下，更是如此。所以不应该是A+A，而是A×A，即A²。其实，我早就为新时代DBA想了一个新名词，叫DBA²。这些概念我做了解释，如下表所示。
阿牛：DBA²，这个称谓好，又形象又霸气！对了，L老师，您表格中展示的数据和数据架构，业务和业务架构，听起来有些相似，您能否给我们解释一下。
L：数据与业务是内容，架构是为内容服务的设计，二者相辅相成。
数据是广泛的内容来源，包括业务数据、系统日志和外部数据。数据架构是存储和管理数据的设计，如压缩节省空间、分区优化查询性能、分布式存储提升并发及容错、数据湖存储原始数据、数据仓库清洗后用于分析等。架构根据数据特性优化数据使用效率。
业务是具体操作，比如下单、支付、发货；业务架构则是对这些操作的规划，比如模块化管理订单、库存、物流，或通过服务化设计让模块独立又协作。业务架构还依赖数据架构支持决策。
阿牛：我明白了。对了，咱们系统尚未规划从源头大幅精简优化，所以技术栈繁杂这事短期内无法改变，DBA根本就忙不过来也学不进去。您说如果能从DBA到DBA²，是不是就能有所改观。
L：会的！因为看待问题的角度不同结果自然不同。接下来，我给大家分享第四个案例，关于深入数据架构带来的好处。
D企业由于历史原因，数据库技术栈极为复杂，DBA团队需要掌握多种数据库的操作命令，学不过来也极易混淆出错。对此，我建议他们暂时忘掉数据库，只关注业务和数据。不管是什么数据库，都以业务逻辑为单元，将操作封装成脚本，并形成清单在团队内推广。操作时原则上只允许执行脚本，而非直接输入命令。
阿牛：只执行脚本，不用记操作命令？那确实轻松多了！
L：没错，这样做有几个好处。首先，操作与具体的数据库技术实现脱钩，让团队更顺畅地完成任务。其次，这些脚本通常是团队集体智慧的结晶，质量高、可靠性强。
接下来进入第二阶段，将这些封装脚本迁移到界面上，逐步实现操作的可视化。经过一段时间努力，几乎所有常见的数据库操作都可以在界面上完成，并且增加了许多细节功能，比如操作权限控制、日志记录、申请和审批过程的透明化等。
最终，虽然技术栈没有减少，但是DBA团队的压力却大幅缓解。团队成员变得更加了解数据规律，理解业务逻辑，熟悉架构，整个团队已经从DBA迈向了DBA²。对纷繁复杂的数据库技术栈，他们轻松应对，一笑置之，再也没人说学不过来了。
阿牛：如果团队有人牵头，大家拧成一股绳，确实可以这样啊，很受启发！这是非常巧妙的思路，让团队从琐碎的技术细节中解放出来，去做更有效率、更有意义的事。
L：是的，你总结得很好。既然你提到效率，我继续分享第五个案例，关于熟悉业务架构带来的好处。
还是D企业，在运营中发现类似count(*)这种针对大表的SQL执行频繁极高且性能耗性能巨大。这种情况在各个数据库都普遍存在。如果是以前的做法，DBA们会进各个数据库，查看执行计划，优化表、索引等，逐一解决。
但这次，团队已经升级为DBA²，他们迅速理解了这些SQL的业务含义。原来只是通过记录数判断表中是否有记录——如果有，执行逻辑A；如果没有，执行逻辑B。
了解业务逻辑后，大家意识到，如果只是判断表中是否有记录，根本不需要统计总记录数。只要找到表中的第一条记录即可。如果有记录，值为1；如果没有记录，值为空。通过这种方式，只需定位第一行记录，无需扫描全表，开销自然大幅下降。
大家订下方案后，从SQL测试到上线申请到SQL上线到上线验证，整个过程都在界面上一气呵成。操作者甚至感觉不到不同技术栈数据库的存在，就顺利完成了优化，而最终效果也非常理想。
阿牛：叹为观止！老师，我也悟了！
五、DBA²+人工智能（大模型）=无限可能
L：除了数据架构和业务架构，还有技术架构。作为数据库从业者，我们必须关注大模型技术与数据的高效结合。
老马：感觉这是不可阻挡的趋势。
L：没错，接下来分享的第六个案例与之相关。
继续D企业的故事，话说从最初的单元封装发展到可视化操作后，大家的工作效率得到了明显提升，团队也因此非常开心。不过，负责人老K深知，尽管封装+可视化+业务驱动极大缓解了复杂技术栈带来的压力，但对各技术栈的理解仍然越多越好。
举个简单例子，不同数据库的参数差异很大，而这些参数的设定往往会直接影响系统性能，所以必须弄清楚每个参数的含义和用途。再比如，每种数据库都有各自的长板和短板，只有充分掌握这些特点，才能避免踩坑。像这样的问题还有很多，这里就不赘述了。
阿牛：是啊，有些基础工作是偷不了懒的。
L：正巧，该企业已经通过与大模型厂商的合作，打造了专属企业大模型。我建议老K尝试将把数据库与大模型结合。先从小功能入手，比如让大模型解释各数据库关键参数的含义和用途。最终的结果是，谁想了解哪个参数的含义和用途，只需鼠标一移动就能显示，非常方便。难得的是，这完全是调用大模型本身的能力，团队并未额外投入新的工作量。
初尝甜头后，团队干劲十足。我建议他们进一步尝试，将SQL审核的工作也交给大模型处理。不久后，SQL编写的界面上增加了一个“审核”按钮，点击即可调用大模型，获取优化建议。这对于新人尤其有帮助，系统的SQL整体质量因此有了显著提升。
接下来，团队将更多功能逐步与大模型融合，包括数据库上线评审、变更审核、故障分析等，团队对大模型的依赖也越来越少，逐渐离不开它了。
老马：L老师，这大模型的能力靠谱吗？会不会胡言建议，误导人？
L：你问的好！大模型确实还有很多问题，不注意是会出乱子的。但我们之所以敢迈出
这一步，是基于以下几点考虑的。
不可逆的效率提升一旦使用大模型，工作效率会显著提升，甚至成倍增长，这种优化对企业和个人来说都极具吸引力，难以割舍；
惊人的发展潜力大模型在解决某些具体问题时，能力已超越80%的人类，并且还在持续快速进步，未来的可能性不可估量；
循序渐进的应用方式大模型的应用是分阶段推进的，初期以辅助为主，逐步过渡到主导，团队有足够时间适应；
多层次的质量保障我们采取了多种手段来确保大模型的问答质量，包括多模型协作、高质量提示词、小模型微调，以及专家介入核实。
老马：时代变化太快！大家都这么玩了。我感觉自己更没用了，再难找到工作了...
L：老马，别灰心！刚才我说过，确保问答质量离不开专家的介入。这家企业觉得你非常适合这个角色，特意想邀请你加入他们的团队，你怎么看？
老马：啊？不会吧！幸福来的太突然了！
L：越是人工智能时代，越需要专业技术强的人来验证大模型的准确性。你这么多年的技术积累，正是这个时代最需要的。
老马：真想不到！太感谢了，L老师！
L：小羊，你也有机会。这家企业的数据库团队效率提升后，对人才的需求不减反增。他们觉得你学习能力强，很有潜力，也向你抛出了橄榄枝。愿意加入吗？
小羊：哇，我没听错吧？感谢老师推荐！
L：两位别谢我了，应该感谢这个时代。
结语
1、什么是DBA²
DBA²=Data × Business × Administrator × Architect。这里D表示Data，B表示Business， A表示Administrator和Architect。其中Administrator包含数据库运维、数据库开发、数据建模、数据安全、数据治理、数据分析等。而Architect则又包含数据架构、业务架构、技术架构等。如下图所示。
注：图中列出Database并用虚框展示，表示与Data相比Database不是重点；balance并用虚框展示，表明业务（Business）要权衡考量的，是很不容易的。
2、案例回顾
将文中六个案例整理成表，方便大家对比传统DBA和DBA²的差异。通过案例看到，传统DBA和DBA²的视野不同，解决问题的手段就截然不同，效果也有天壤之别。
注：花数小时调整表格中文字，力求工整。不知多少人和我一样是强迫症患者
3、数据库从业人员该如何成长
意识比技能更重要紧跟时代，与时俱进，不要固化思维，不要计较一亩三分地，不要迷茫，不要慌张，站在第一性原理上去思考。未来已来，把握机会，从DBA到DBA²，你的潜力超乎你的想象！
圈子比苦学更重要参加数据库相关大会活动，可以广交朋友，拓宽视野。要学会抬起头，走出去！
选择比努力更重要积极投身国产原创数据库阵营。国产化是大趋势，原创才有未来！
经验比知识更重要投身实践，学习行业专家们的实战经验。
作者丨梁敬彬 梁敬弘
来源丨公众号：收获不止数据库（ID：ldbast）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
