能力和态度一直是管理学里对绩效研究的两个维度. 如果我们假设能力和态度都是一个非负数的话, 通常大家认为绩效 = 能力 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 作为一个例子分析了能力和态度两个维度对绩效的影响. 接下来我们还是重归主题. 对于能力和态度的两个维度, 蒙牛集团的牛根生有过一段非常经典的阐述:"有德有才, 破格重用; 无德无才, 坚决不用; 有的无才, 培养使用; 有才无德, 限制录用". 这段话很好的总结了今天的话题.
来源: http://zhuanlan.51cto.com/art/201812/589077.htm