能力和态度一直是管理学里对绩效研究的两个维度。如果我们假设能力和态度都是一个非负数的话，通常大家认为绩效=能力X态度。之所以用乘法而不是加法，是因为其中任何一个为零，绩效为零。

但是西方管理学上认为能力和态度对绩效的贡献的方式方法，影响程度是不一样的。具体的细节这里不展开，我引用一句名言来总结：Hire for Attitude， Train for Skill。简单来说招人的时候看态度，招进来去培训提升能力。

这话里面透露的意思是能力是可以通过培养获得的，但是一个成人的世界观价值观人生观的可塑性已经不强了，所以态度这个维度的改变就更困难。因此招人的时候更应该看态度。找到态度合适的人，培训之，就是能产生好绩效的员工。

有关能力和态度的东西，不仅仅体现在理论上，也体现在实践上。无论国内国外的企业，对态度都是很重视的。西方企业里，亚马逊是一个代表。Jeff Bezos提出来的亚马逊14条领导力准则，更多体现的是一个人的态度问题。亚马逊的成功和领导力准则密不可分。亚马逊内部，自上到下都通过领导力准则工作，招人面试，考评，升级都围绕这个展开。有关14条领导力准则我的知识付费专栏里有10多篇文章详细介绍，这里就不展开了。

同样的例子在中国也适用。阿里巴巴就是一个非常讲究态度的公司。当然这个态度在亚马逊叫领导力准则，在阿里巴巴叫做价值观。阿里的面试里有独特的HR面试，HR有一票否决制，以确定是否符合公司的价值观。阿里的绩效考核打分有两个独立的分：能力和价值观。能力强而价值观不行被开的人不在少数。比如说著名的技术达人左耳朵耗子因为价值观离开阿里。下图是我从官网截图的阿里巴巴价值观。客户第一，团队合作，拥抱变化，诚信，激情，敬业。这些都是非常正能量的词了。

下面我们以阿里云PolarDB这个实例来分析一下能力和态度这两个维度在实际过生产生活里的情况。PolarDB是阿里云RDS团队出品的新时代云数据库，和AWS的Aurora展开竞争的。读我的公众号的人也应该不陌生了。有关这个数据库的详细情况，我们还是引用官宣文章：阿里云发布自研商用关系型数据库POLARDB。此外还有一篇专门介绍PolarDB的能力的官宣文章：6倍性能差100TB容量，阿里云POLARDB如何实现?

PolarDB团队2018年也在国际数据库顶级大会VLDB发表了industry track的论文，详细介绍了PolarDB的核心技术PolarFS的实现。这也是中国企业为数不多的在国际数据库顶级会议上发表论文。我本人大概发表过一打的这样档次的论文，但是基本上都是在美国的学校和美国企业里发表的。中国企业能发表出来，也进一步证明了PolarDB，以及其背后的阿里云RDS团队的能力。

本文的另外一个维度是态度，用阿里巴巴的说法是价值观。总结起来就是客户第一，团队合作，拥抱变化，诚信，激情，敬业。讨论这个维度，我们需要一些事实。

本文非技术类文章，但是为了让吃瓜群众都能够读明白，我们也不可避免的要科普一点技术。PolarDB是一个MySQL兼容的数据库。我们引用前PolarDB团队丁奇在极客时间mysql的专栏上的介绍，mysql是一个服务器/存储引擎架构。

服务器负责连接，权限，查询等等，而存储引擎用来存储数据。mysql是一个服务器/存储引擎架构。存储引擎不同决定了mysql到底能提供什么样的服务。举个例子，现在最流行的是Innodb，提供了对事务处理的支持。但是MyISAM则不支持。

PolarDB我们可以简单的认为在mysql 服务器上对接了一个新的存储引擎PolarFS。这个存储引擎有很多优越的性能。当然，根据PolarDB开发者的说法，对服务器层的改动也是巨大的。但是这种简化的方式有助于非数据库专业的人更好的理解这个产品。我也就不精确的用这个说法了。

数据库产品里都有日志文件。mysql的日志文件分两种，一种是独立于存储引擎在服务器端的，叫做binlog，另外一种是存储引擎支持的。比如Innodb里有redo log和undo log。前者主要支持故障恢复，后者主要用于支持事务和多版本。具体技术细节不展开。 这里继续引用丁奇在专栏里的一段解说：

PolarFS和Innodb一样也实现了redo log和undo log。Binlog因为是server端的log，所以所有的mysql存储引擎都可以用来进行备份。这个特性也被一些mysql兼容的数据库，比如前段时间沸沸扬扬的TiDB用来接入已经有的系统。TiDB最初开始作生意的办法是把自己挂载到成熟的mysql系统里面作为一个从库。通过解析binlog来实现这个目的。这个特性也为很多企业把数据复制到数据仓库里面做OLAP分析提供了标准的解决方案。所以在mysql里面，binlog是一个非常重要的东西。

铺垫了这么多，重点来了。阿里云RDS团队在推出PolarDB之前，也有自己的mysql 产品。这个产品也提供了三备份多活方案。三备份多活方案是通过binlog进行复制的。用户也用binlog来复制数据去数据仓库进行分析。这个产品对binlog的处理非常的贴心，不但会有任务定时上传备份binlog，也有定时删除binlog的任务。所以用户既不需要担心binlog丢失的问题，也不担心binlog堆积的问题。

PolarDB推出来之后，底层的PolarFS有类似innodb的redo log。所以数据复制备份可以直接在存储层用redo log做掉。当然PolarDB的后台有自动备份redo log的能力，类似于RDS自动备份binlog的能力。这不足为奇。

PolarDB因为自己基于redolog的物理复制来构建复制关系，不依赖binlog，所以：

默认关闭了binlog

如果用户需要用binlog可以打开binlog，但是

后台不像RDS那样有任务会定时上传binlog备份，并且

后台也不会有定期删除binlog的任务。

我们知道，用户是需要通过binlog复制数据进第三方的。这个团队也是有技术有能力把binlog的自动备份和删除给做好的。他们之前的产品就提供了这个功能。但是他们没有做。用户要用binlog，自己看着办吧。binlog堆积，自己看着办吧。写到这里，我有点顾虑阿里云的PR和PolarDB的团队要跳出来找我，说我在胡说八道了。为了避免麻烦，我还是引用一下官方的说法吧：

PolarDB可以把binlog做得更好用，从能力上来看，是没有问题的。因为之前更早的产品已然可以支持更好的用户体验了。能够做到却没有做，就不是能力问题了。那这算是态度问题吗?

我们首先问一个问题：PolarDB为什么要这样处理binlog呢?以最邪恶的想法去理解，binlog难用了数据就都留在PolarDB了。接下来在PolarDB上做各种OLAP的支持，用户也就没必要把数据挪去第三方的数据仓库分析了。这种圈养客户的做法是很符合经济利益的。当然，也和客户第一的阿里巴巴价值观相违背。

作为对阿里巴巴价值观(客户第一，团队合作，拥抱变化，诚信，激情，敬业)比较了解的我很难想象PolarDB会出于这样邪恶的目的故意把binlog用的很难用。那么更为合理的解释是对binlog易用化的支持，会影响PolarDB的查询的latency和throughput等等的技术指标。团队又有很多优先级更高的事情要做。所以这个优化就不是团队优先考虑要做的了。

那么，以牺牲用户体验换来的这些技术指标，是一个好的牺牲么?客户第一这个价值观，在这里需要怎么解读呢?阿里云的RDS团队在PolarDB里面没有实现自己在mysql的RDS里已经实现的binlog的自动上传备份和自动删除功能，是一个态度问题吗?这个事情恐怕没有一个明确的答案，就留给大家去思考吧。

如上，我们以PolarDB作为一个例子分析了能力和态度两个维度对绩效的影响。接下来我们还是重归主题。对于能力和态度的两个维度，蒙牛集团的牛根生有过一段非常经典的阐述:"有德有才，破格重用;无德无才，坚决不用;有的无才，培养使用;有才无德，限制录用"。这段话很好的总结了今天的话题。