前阵子和一个朋友谈到套装软件悖论，他引用一位大佬的观点，认为套装软件的易用性和成本的博弈最终会导致软件越来越复杂，最终导致易用性无法实现，最终必须引入顾问团队才能玩得转，ERP就是典型代表。数据库是一种典型的套装软件，从数据库的角度来观察一下这个悖论，好像还是有点道理的。

很多朋友提起国产数据库，认为大多数国产数据库厂商是在做数据项目，而不是在给客户交付数据库产品。这种感觉是对的，数据库就是一种特殊的套装软件，因此数据库也逃不出商用套装软件的客观规律。数据库交付像项目交付说明了目前大多数国产数据库目前还处于软件成熟的前期。

干过复杂的套装软件的朋友都会有这样的经历。你的第一个项目是完全在客户现场才真正完成的，你需要投入巨大的研发成本才能满足客户的要求并完成验收。这种项目注定是不赚钱的，大型套装软件的前几个项目都不大可能赚钱，因为定制化改造需求太多了。随后你的产品基本上成型了，交付客户的时候轻松多了，你的项目也逐渐开始盈利了。不过客户依然有很多个性化的需求，为了降低成本，你必须严格控制版本，因此你需要在系统中增加很多配置项，以便于在现场通过配置满足客户需求，尽可能减少二开。在这种模式下，你的版本软件产品化程度越来越高，不过随着客户越来越多，配置的复杂度逐步超出了客户的能力范围。因此客户需要你提供大量的现场服务来完成这些配置工作。你可能很高兴，很多客户愿意为这个服务付费，你又获得了一个额外的收入。

不过好景不长，你突然发现，客户的这种需求几乎是无止境的，你很快发现面对客户千奇百怪的应用场景，并没有那么多高水平的现场工程师来填这个似乎永远也填不满的坑。你意识到到必须让客户或者第三方顾问公司来帮你接这个雷，但是环顾四周，好像没有谁能接这个活。

数据库的产品与交付其实和同样为复杂套装软件的ERP有些类似，很多工作必须在专业的团队帮助下才能完成这些配置项的优化。在ERP领域，干这个活的人叫顾问，而数据库领域，干类似工作的被称为似乎低了几等的DBA。这是因为ERP是领导直接关注的，而数据库在企业领导心里的地位要低多了。

以前和一个数据库厂商的研发人员交流的时候，他说我们不像ORACLE那么难用，我们的产品不需要那么复杂的调优，一切都是自动化调整的。

实际上他还是没有真正理解数据库这种复杂的套装软件的本质。他引以为豪的自动化驾驶并非他们的数据库产品更为优秀，在自治数据领域，Oracle其实要比任何一款国产数据库要优秀得多。连Oracle都没有做好的事情，他们同样也不大可能做得到。因为他们的产品还没有面对过像ORACLE那么丰富的场景，因此他们还没有开始大规模引入应对这些复杂的，超出他们最初设计配置项。随着他们需要支撑的场景的逐步丰富，有一天他们引以为豪的自动化驾驶将会不复存在，而这时候他们的产品才真正会有脱胎换骨的进步。基于上面的分析，随着国产数据库在更为广泛的应用领域普及应用，只会变得越来越复杂，想要用好也只会越来越难。开箱即用，小白也能用，这些观点，也就听听吧，千万别当真。

好像有点跑题了，我们再回到DBA这个职位会不会消亡的问题上来。不过从前面的讨论中，可能已经有些朋友意识到了，因为数据库要面对成千上万不同的应用场景，必然会变得越来越复杂。哪怕数据库产品做得再牛逼，最终的归宿也是越来越复杂，作为实施顾问角色的DBA还是少不了的。

虽然DBA这个行当还会继续存在，不过现在的DBA也还是要有危机感的，经过国产化替代，中国的数据库市场完全变化了，多了很多种大家都不熟悉的数据库。不仅仅是数据库的种类变了，数据库应用环境也发生了巨大的变化。首先是各个企业在数据库应用上更加依赖开发团队和开发商了，应用开发商的数据库应用水平也有了很大的进步。DBA在数据库技术上的垄断地位受到了一定的冲击，因此DBA也需要通过自我提升来寻找自己新的定位。DBA必须在新的IT技术生态中找到自己新的站位点，重新塑造自我价值，才能在新的时代中不被淘汰。

对于套装软件悖论，一些专家认为解决方法是低代码。作为一种特殊的套装软件，解决数据库复杂度的方法是什么?ORACLE时代是依靠DBA的个人能力的，因为ORACLE已经十分成熟，并且被DBA研究透了，因此个人获得能力成为专家的路径是很清晰的。在未来数年内，国产数据库尚处于成熟过程中，另外现在的数据库复杂度也在不断增加，因此个体学习国产数据库的成本会高得多，很多知识还需要自己去积累和整理。这也需要年轻的DBA付出更多的心血和精力投身其中。

积累套装软件所需要的低代码能力也是十分关键点。在DBA领域，“低代码工具”就是运维工具、DBA自己自己积累的脚本集和自己写的小工具，也包含现在火到炸裂的大语言模型。在运维国产数据库的时候，趁手的工具肯定很难找到，因此积累自己的运维脚本，自己编写运维工具，提高自身的工作效率也是一种特别重要的能力。这也和我在最近的几次沙龙中提出DBA要掌握一两门脚本语言的观点是吻合的。