前段时间有网友在群里讨论，把数据库代码工作者比做是造车的，业务应用开发人员是开车的，而数据库管理员(DBA)则是擦车的。有网友评论这句话，“伤害性不大，侮辱性极强”。说实在的，个人觉得这个说法虽然有些偏激（DBA起码也能算个修车的），但在当前XC背景下来看还算是中肯。

但是这是一件值得称道或者说值得自豪的事情吗？个人觉得未必。我们从市场和技术这两个维度来看这件事。

首先是市场生态

Oracle之所以能够称霸数据库领域40年，最核心的本质是构建了良好的生态环境。在这个环境中大家都能获取到自己想要的，直白的说，从事Oracle相关的工作，能让大家都赚到钱。早期Oracle数据库技术并不是最好的，但是因为没有硬性的License授权限制，只要是想用想学的，都可以下载到没有任何功能限制的介质，官网上还提供了非常详细的安装管理和优化文档，生怕你学不会用不好。正式凭借着开放的市场策略，让Oracle数据库赢得了大量的忠实用户，产品在众多场景中得到了广泛的使用。开发商基于Oracle数据库开发的应用软件运行稳定、性能良好，获得用户的好评；而Oracle则充分利用这些机会快速发展和完善自己的产品。

由此构建了一个良好的市场生态系统，集成商通过出售产品赚取到渠道利润，开发商通过开发满足客户个性化需求的功能软件赚到应用开发的钱，而DBA则也能够通过自己对数据库的了解，让数据库能够更快更好的运行，也能赚取到自己的那份“辛苦钱”。

其次是技术生态

Oracle提供了丰富的性能观测体系和故障诊断手段，从运行统计指标维度看，在Oracle 11g数据库中有600+，到了19c大幅跃升到2000+；而等待事件模型，在11g中多达1300+，到了19c上升到1900+。通过这些指标体系可以快速对数据库运行状态和所发生的问题进行精确定位。同时，Oracle也非常注重运维知识的积累，其官方支持知识库(My Oracle Support)中包含了各种故障场景的Case处理步骤，以及对相关概念和数据库核心运作机制的详细说明文档。正是有了这些扎实的技术支持基础，让运维人员并不需要去翻阅源码就能比较清晰的了解数据库的底层运行逻辑，结合统计指标、等待事件、运行日志和后台知识库中的案例，绝大多数问题都能在运维层面得到解决，而不需要动不动就“召回返厂”去麻烦研发人员。

正是基于这些技术基础，催生了一个新的岗位 – 数据库管理员，专门负责数据库的管理和运维，也就是前文所说的“修车人” 。在这个体系中，运维管理等“脏活累活”可以交给数据库管理员来负责，研发可以专注在数据库产品功能开发等“高大上”的工作上。

尴尬的DBA

但在国产数据库的生态中，传统DBA角色处在一个非常尴尬的地位。

首先，DBA的技能主要来自于实战经验的积累。比如结合操作系统、内存、存储及网络等多个维度的最佳实践，让数据库稳定高效的运行。但是这些最佳实践是需要各种案例和场景的打磨，国产数据库的使用案例和技术积累和Oracle相比差距还不小，因此专业的运维人员得到锻炼的机会也少，在不掌握源码的情况下，DBA没有太多可发挥的空间；

其次，大多数传统DBA写代码的能力并不占优，他们的工作性质也比较难接触到源码。除了实战经验，DBA另外的主要技能来源就是阅读文档，但绝大多数国产数据库厂商提供的文档都非常有限，即使提供了文档也仅限于概念，安装和配置类的，深入介绍原理实现和相关的资料很少。至于故障案例知识库更是绝无仅有，能保持社区的问题能及时得到回复就算是非常优秀的。更有一部分厂商，不仅没有对外发布官方文档，连测试介质都不提供，更别提什么生态建设。这种情况下，DBA怎么能快速成长？

写在最后

昨天已经发布了新一期的安全可信评测入围产品，意味着国产数据库的竞争已经到了下半场，没有进入名单的数据库，基本已经被排除在国央企的采购清单之外，未来的发展空间基本被定格。但是即使进入了名单并不意味着能够高枕无忧，下半场比拼的将会是生态建设的持久战。

这个世界都是很现实的，当其他人没办法通过你的产品赚到钱的时候，还会有人用你的产品吗？

最后再回到开头的话题，研发抛头露面是一件值得骄傲的事情吗？这恰恰说明产品还远未成熟，市场生态仍然亟待完善，从整个产品生态上来说，需要做的工作还很多很多。