今年对于我来说，目前面临的是职业生涯的又一次转型。二十多年前从系统架构师转型做专职DBA的那次转型是比较顺利的，因为以往的十多年研发经验是给我的DBA生涯加分的。现在从DBA转型做软件产品，我是没有什么经验的，虽然我做过十多年软件开发，不过做定制化软件的人与做产品的人看似都是在做软件，不过其中的差异是十分巨大的。如果用做定制软件的思维去做产品，那肯定是做不好的。其中最为关键难解决的问题是功能与易用性之间的权衡。

　　对于一个产品来说，功能强大与简单易用是两个看似很一致实际上可能很分裂的概念。与做定制开发不同的是，通用型的产品的功能越丰富越好，越能够满足更为广泛的客户群体的需求。比如对于数据库产品而言，为什么现在的国产数据库都要做多模融合，要做HTAP，就是为了让用户无论从哪个维度去选择，自己的产品在功能上都不吃亏。

　　简单易用则是与功能丰富完全相反的，功能越多，系统的易用性必然就会越差。比如功能极其全面的Oracle肯定很难去与MySQL比易用性。MySQL使用起来十分简单，90%的故障都可以用一次风险极小的重启来解决。随着产品的功能增加，对于用户来说使用起来就越加复杂。用户在使用一个产品的时候，往往只会使用其中的一部分功能，如果你的产品做得不够好，那么用户不使用的功能反而会给用户造成困扰。

　　一个好的数据库产品必然是兼顾了功能和易用性的，Oracle数据库中的数百标准参数和数千个隐含参数就是为了让有特殊需求的用户去应对千奇百怪的个性化场景的。

　　以前我做DBA的时候，总觉得某些数据库运维工具过于简单，无法解决运维工作中遇到的各种问题，O记的OEM十分强大，但是其复杂度之高，让高手都很难玩得很明白。几年前我以做一个比OEM更好用的OEM的想法开始了一个运维工具的研发。在前几个用户上线的时候，大家觉得还不错，只是功能还略微少了一点，与我介绍的“运维知识自动化”的理念的最终实现形态还有些区别。那时候系统中只有几十个Oracle的故障模型和几十个常用工具，简单易用但是功能覆盖不足。随着产品的功能覆盖面越来越全，并且适配了大量的国产数据库和开源数据库，系统中出现了数千个工具，这个产品也犯了OEM的毛病，使用起来越来越复杂。想要做一个没有大系统病的OEM，最终只能做成一个比OEM的功能少很多，但是比OEM更不好用的产品。

　　对于国产数据库而言，用户需求更为复杂，这个矛盾也更加突出，数据库厂商如果不能解决好这对矛盾体，也是难以让用户满意的。目前应对这个矛盾的方法不外乎两种，一种是走自己的路，让用户去吐槽，这种做法其实与自绝于市场无异，在如此内卷的国产数据库市场中，想要活下去，必须抓住能抓住的没一个客户。

　　另外一种做法是无条件满足客户的需求，不过这么做很容易把数据库这个通用产品做成了项目。几乎每个以客户为导向的国产数据库厂商都经历过，目前只有少数厂商已经走出了这个阶段，实现了版本收敛。

　　我和很多国产数据库的朋友交流过，大家都觉得走过这个阶段一切都会好起来，产品版本必然会收敛，实际上这种观点还是过于乐观了。想要解决好这个问题，必须向O记学习。Oracle数据库把这二者解决得很好，功能越来越强大，同时也变得越来越易用。

　　Oracle是如何做到这一点的呢？我个人觉得，Oracle的成功中最隐秘的秘诀是自身全面数字化。二十多年前OWI的出现让Oracle的可观测性得到了极大的提升。利用OWI，Oracle构建出了一系列模型，比如著名的Time Model，利用Time Model，Oracle RDBMS内核能够完成多种自身机制的自动化分析，实现了大量内部参数的自动化调整。最终让Oracle本身随着新功能的不断加入而变得越来越复杂了，但是因为大量的复杂性问题都可以自动分析，自动调整了，反而让使用和运维Oracle数据库变得比十几年前更加简单了。比如现在Oracle的共享池比起二十五年前的9i来说复杂得多了，不过因为共享池出问题而导致的严重问题不足二十年前的十分之一。

　　从本质上来讲，全面数字化是Oracle如今变得如此易用的关键。目前阶段，国产数据库与Oracle在这方面的差距依然是十分巨大的。国产数据库在可观测性与数字化方面的课必须要补起来。AI时代到来，可能有不少国产数据库厂商的朋友希望利用智能化去弥补自己在数字化方面的不足，从而实现弯道超车。我要泼一盆冷水，没有数字化，就别谈智能化。如果数据库内核都无法把一个数字化的自己展现给AI，AI如何能够帮你去完成自治化服务？

　　解决丰富的功能与简单易用问题，依然是需要在研发上做出巨大投入的，在实现功能的同时，把可观测性做好，国产数据库才能在未来的智能化时代里走得更好。