@Lenciel

关于中台的一次分享

去年在 iTech 做了一次中台的分享,之后就答应右军再整理个说明。

目录

概述

中台这个词火爆挺久了。但从阿里 2015 年提出并开始实施,发展到目前为止,并没有「标准化」:换句话说,它跟「人工智能」,「大数据」,「微服务」一样,具体的含义在不同公司不同时期的不同上下文里,有着千差万别的含义。

并且和这些词不太一样的是,它是一个在中文技术圈被频繁使用,但在其他语言环境下几乎找不到的词。所以我常跟身边的朋友说,关于它的争议特别多,大家不用感觉奇怪,可以参考中医。

本文的主要目的,是总结一下过去在中台架构和建设的过程中的思路和方法,方便大家对「中台」有一个相对一致的概念和边界,从而在后续的工作中更好地进行思考、讨论和选择。因此内容主要集中在:

  1. 中台是什么:我们对中台的理解是怎样的。
  2. 中台做什么:我们做出判断和选择的思路是怎样的。

一旦进入具体实现的细节,各个公司的技术栈、上下文和团队发展阶段各不一样,往往没有太大的参考意义,故本文不做过多讨论。

是什么?

中台的起源

中国有个好习惯是「治学先治史」,我们要了解中台究竟是什么,可以看看它发展的历史。

行业里面最早提出并实施「中台战略」的阿里内部,关于它的起源有两种说法:一个是马老师 2015 年年中参观 supercell 之后提出的1;一个是阿里的工程师们针对业务上的挑战参考美军的发展提出的。

supercell 是一家人数只有不到百人,却连续推出了《部落战争》等多款爆款游戏,先后被软银和腾讯投资数十亿美金的游戏行业的传奇公司。它最大的特色就是内部以小团队(cell)形式作战,每个 cell 最多不超过 7 人。这些小团队依靠公司提供的公共的后端架构、引擎、算法、美术等中台资源,按照几周的时间周期推出大量新游戏,快速试错。

美军则是从一战时的按「军」为单位作战,到越战时按「营」为单位作战,逐步演进为「突击队+航母」的方式进行作战。前线突击队通常 7 到 11 人,有着中后台的强大支持(包括各种资源上的保障支持,卫星和无人机提供的侦查能力,高精度导弹的炮火支持等等),可以灵活选择战术并引领整个进攻高效完成。

可见,无论这两种说法哪种准确,中台战略主要都是指通过「小前台,大中台」的架构方式,降低试错成本,加快响应速度,从而真正做到「降本增效」

「中台」和「平台」的关系

中台既然是一种架构方式,那么看到「小前台,大中台」的时候,最容易有的困惑就是这跟以前行业里流行过的「厚平台,薄应用」的架构方式有什么区别。

实际上,如果理解了企业级应用的架构难点,以及从服务化到平台化再到中台化的演变过程,就能非常清楚中台架构方式究竟是什么了。

层次与架构

「架构」在软件行业是一个非常微妙的词。

我觉得无论是最初的 C/S 架构、B/S 架构还是如今的微服务架构,架构的内涵主要包括以下两点:

  • 是最高层次的系统分解和抽象
  • 是不易改变的设计方案和抉择

要想对系统进行分解和抽象,找到不易改变的部分,主要的方法是分层。在计算机本身的架构中,到处都有分层的例子:

  • 系统:硬件层->HAL 层->OS 层->应用组件或平台->各种应用。
  • 网络:不管是五层还是七层的分法,大体上都是硬件->链路->网络->传输->应用。

分层的方式最核心的好处在于:

  • 封装细节,解除耦合:不如不用知道硬件细节就可以在 TCP 上构建 FTP 服务,如果硬件层完全换了 FTP 服务也可以正常运行。
  • 有利于标准化:因为每层的实现相对自治,就容易形成每一层的标准化协议和运行机制。

和网络这样体系架构已经非常成熟的系统相比,互联网公司构建的「企业级应用」,难度主要在于:

  • 复杂的数据层次:需要持久化并经常变更的数据很多,需要打通和集成的外部异构系统很多,数据状态复杂访问量大访问方式异构
  • 复杂的业务逻辑:各种商业规则和潜规则形成的业务规则,还会随时变化,软件里没有比业务逻辑更没有逻辑的东西了

因为这两方面的复杂性,对企业级应用分层时最困难的问题就是究竟有哪些层次,每一层的职责和边界是什么。到目前为止,最流行的做法是按照 Brown 的建议2把它分为三层。

  • 表现层主要处理用户与系统之间的交互:可以是 App 或网页,也可以是桌面客户端。
  • 领域层主要是处理各种业务领域内的逻辑:包括数据抽取,规则计算等等的逻辑。
  • 数据层主要是数据库,消息队列等进行数据交互和持久化的工作。

各层的运行环境

进行了层次划分之后,一个需要进行的架构选择就是在哪里运行这部分工作:是在服务器上,还是在用户的机器上。

一个常见的误区是把表现层直接对应到前端应用,领域层直接对应到后端应用。实际上表现层的大量逻辑有可能是在我们的服务器上渲染的。而随着桌面电脑或者手机的处理能力和交互需求的提升,很多领域层的业务逻辑反而是在客户端进行处理的。举个简单的例子就是各种表单填写时的字段校验,在过去是需要提交到后端进行的,现在则有很多是监听用户焦点离开当前输入框就进行了。

因此,在确定各层的运行环境的时候,核心是根据应用本身的特点,考虑不同的运行环境的优劣点安排:运行在客户的机器上,好处是响应性能和不依赖网络;缺点是如何把变更同步到各个客户的机器并且让它有效(想想不同浏览器的兼容性)。

比如数据层,我们当然不希望每个用户有一个自己的数据库,然后我们来做这些数据库之间的读写同步,所以它一般都是运行在服务器上的。但是我们又希望用户有很好的响应和体验,所以我们各级的缓存里有不少是部署在客户端的。

再比如表现层,我们希望给用户很良好的响应速度和用户体验,所以可以在后端根据用户画像进行千人千面的数据组织来给不同用户组合不同的操作界面。同时我们又希望能够对客户端能够有更好的控制力,所以会打造客户端的各种框架和组件。

架构的核心难点

进行了层次划分和运行环境的选择之后,架构的核心难点就在于如何抽象出:

  1. 标准的协议和运行机制。
  2. 满足标准的分布式执行单元。
  3. 去中心化或中心化的控制单元。

正是在这样的抽象过程中,行业里提出了 SOA,微服务,服务网格等服务化到平台化的解决方案(SOA 和微服务的一个很重要的区别是执行单元和控制单元和通信方式,SOA 是有总线的)。而在三层里,如何对控制和处理复杂业务逻辑的领域层进行架构是关键中的关键,它既是公司业务生态的基础,也直接决定了业务探索的速度和业务创新的成本。

所以我们以领域层为例,看看为什么需要业务平台,它又如何演化到业务中台。

业务中台是什么

建设敏捷的前台+强大的中台,绝不是因为阿里或者京东做了,所以货车帮要赶这个时髦。而是货车帮本身的业务不断发展下,技术体系的正确应对策略。

子系统时期

货车帮初期,只有一个主业务,也只有一套主系统。随着 ETC/车油/金融等业务的发展和技术人员的增加,这个系统的交付速度和稳定性都变差了。于是在 2017 年开始做分布式系统:把原来的单体系统拆分成多个中心承担的分布式子系统。

最多的时候我们技术体系有 13 个中心组成,除开包括了用户中心、活动中心等在内的基础服务中心,还有包括平台业务中心(车货匹配业务),车后业务中心等在内的各个业务系统中心,以及大数据中心,运维中心等。

这个阶段的核心工作实际上是把数百人的团队拆分成了功能相对比较集中的小团队。每个独立的系统可以独立设计、独立接需求、独立发布,整个研发交付速度和系统稳定性扛住了业务高速发展的需要。

但随着事业部化的推进,业务决策链路更短,业务发展更快,技术人员的数量也快速增长。而且各个事业部的定位不一样,业务发展阶段、方向和规则都很不一样。为了快速应对每天的业务需求变更,所有的员工都在加班加点,但由于在业务抽象建模,系统架构的开放性等方面考虑不足,导致业务逻辑之间的耦合和相互影响,研发质量和效率大幅下降。

这种见招拆招,垂直发展,未做足够抽象通用的架构行业里称之为「烟囱型架构」,解决这种问题通常就需要平台化了

平台化时期

从一个个的中心到平台化,核心是业务抽象建模和保持系统架构的开放性:

  • 拉通考虑各个业务的逻辑,把基础能力抽象出来,解决共性的 80%问题。
  • 系统架构上保持开放性可扩展性,把业务和业务之间不同的逻辑隔离并进行封装,解决 20%的个性化问题。

比如每个业务都需要用户注册和审核的功能,所以我们通过用户平台来提供统一的接口。而不同业务比如车货匹配业务和车油业务对司机审核的力度要求是不同的,前者需要司机提供驾照等证件,后者可能就宽松很多。平台要把不同业务的逻辑隔离开进行封装,对外提供一致的接口。

再比如营销活动,各个业务都要做。我们就可以抽象出一个从设计,上线,到数据收集全生命周期管理的活动平台,提供给各个业务使用。但是各个业务具体的活动逻辑要做到很好的封装,就需要建立元数据中心、规则中心、活动界面自动生成、活动数据自动埋点等等。

图1 子系统到平台化的架构升级

平台化的核心收益其实就是降本增效:

  • 抽象共性,减少重复建设投入的人力和时间成本。
  • 快速支撑,提高需求到研发上线到效果复盘各环节效率。

平台化的过程一般都会经历从 API 治理和提供,到服务化,到最终形成平台的过程,所以各个平台并不会在同一天完成。实际上,一直到货车帮开始建设中台的时候,仍然有很多平台正在建设中。

那么我们为什么又要推中台战略了呢?

中台解决的问题

我们以一个新业务负责人的视角就很容易想通平台化的问题了。

首先,作为各个业务的负责人,要了解各个平台的功能和职责并且推动合作很困难。做一个新功能的 MVP 究竟需要多少人多少时间甚至都算不出来。

首先,平台是提供抽象出来的共性功能,每个团队专注自己的事情,提升效率。但这样虽然带来了专业,却很容易导致「各家自扫门前雪」,对于创新业务的支持力度不足。

所以,就会出现类似下图的问题:当公司的保险业务负责人想要进行某个新功能的开发时,经过反复沟通,发现自己的团队承担的部分可以在两天之类完成开发,但是依赖的团队对这相关功能的排期可能排到了两三周后面。

图2 业务平台带来的「各家自扫门前雪」

最后也是最大的问题是,领域的平台化解决了领域层内部的问题,但业务的执行都是跨领域的。涉及用户、商品、交易、营销、支付、服务等等环节,横跨多个系统。如何把多个平台的数据集成到一起并加工分析而产生新的支持到业务的价值,变得非常困难。从当时的实际情况看,按照平台化的架构方式,基本上是没有办法做数据驱动运营的。

因此,平台化之后虽然解决了烟囱式架构的很多问题,但是随着公司的发展,整个组织的效率仍然会逐渐降低。这不是一个技术问题,而是一个复杂生态下的协作问题。要解决这样的问题,就要通过打造中台来解决前面说的企业级应用架构的三个核心难点:

  1. 标准的协议和运行机制。
  2. 满足标准的分布式执行单元。
  3. 去中心化或中心化的控制单元。

所以,中台化其实是平台化之后的自然阶段,它主要是带来了:

  • 提供完整解决方案而不是暴露 API,给业务带来的快速创新和试错能力的提升。
  • 通过数据统一治理和应用,给业务带来数据驱动的运营能力的提升。
  • 通过解决信息获取成本高,系统互联互通成本高的问题,给企业带来组织效率的提升。

中台建设的前提和难点

中台建设的前提也是难点有两个。

第一个是要需要有稳健的基础设施

  1. 系统性解决复杂度。
  2. 系统性解决高可用,高并发。
  3. 系统性解决开发测试环境一致性和便利性。

能够做好具备这三个能力的基础设施,要求公司具备较强的 IaaS/PaaS 层的建设能力。

第二个难点,在于中台本身的建设过程中,如何进行抽象和划分边界

但从技术架构上来说,常见的抽象方式有两种:

  1. 按照信息流、资金流、数据流等等的构成 element 和 process,自上而下进行抽象。
  2. 按照对应一个个数据单元的 entity 以及这些 entity 的状态和转移,进行自下而上的抽象。

前者是更加常见也容易入手的方式,但是扩展性较差。后者则更加面向领域内的模型3,具有更好的健壮性,能够支撑更多的业务场景。

但需要注意的是,对系统边界的划分,通常不是一个简单的技术架构的问题,而是牵扯到流程设计、组织架构、业务归属等在内的极其复杂的挑战。

因此,进行中台建设一个隐含的前提,是公司的文化有一定成熟度,并且核心管理团队和骨干成员有一致的目标。摩擦在所难免,解决的办法更多不是靠的技术。

做什么?

理解了中台是什么,我们来看看做什么。

一个很好的做法是,先看看别人做了什么。

别人做了什么?

图3 阿里中台架构图 - 摘自钟华云栖大会分享」

核心三大部分:

  • 基础设施:一套支撑分布式服务研发、上线和运营的基础设施4
  • 业务中台:包括了用户中心、交易中心、搜索中心、营销中心等在内的业务中台。
  • 数据中台:包括了数据技术,数据资产管理,数据服务等各个层次的数据中台。

我们的总体架构

根据我们对中台的理解,并参考其他公司的做法,货车帮的总体架构是:

  • 前端和接入层
  • 前台业务
  • 业务中台和数据中台
  • 基础设施
  • 企业效能和运维保障体系

图4 整体系统架构:前台/中台/后台

这套架构的核心目的,是在更快更好的支撑公司进行业务创新的同时,赋予业务真正的数据驱动运营的能力,从而在提升组织效率的同时,为发挥大数据的威力奠定基础。

基础设施

图5 货车帮面向云原生的基础设施

包括云原生平台 Newton 在内的基础设施的设计和开发,以及统一规划和提供的企业效能和运维保障能力,过去已经有过不少分享,这里就不再赘述。

但需要再次强调的是,如果没有一套足够好的基础设施,最好先不要开始进行中台的建设。

业务中台

业务中台的核心建设步骤是:

  1. 从业务领域的边界是什么,提供的基础服务是什么,领域服务和领域服务之间的流程链接标准是什么等角度,抽象出模型、规则和协议
  2. 基于这些模型、规则和协议,建立业务实施标准和管控标准。
  3. 根据实施和管控标准,提供权限集中管理、流程灵活可配的工具和引擎。

也就是说,如果还是像平台化阶段,通过一堆 API 来暴露能力,那就不是「中台」

以中台化之后的用户中心为例,它将不再只是提供用户注册审核相关的 API 或者类库,而是需要站在公司业务特点上建立物流领域的包括用户认证,用户审核,用户评价,用户等级,用户画像等在内的用户标准体系,并且负责所有相关的系统开发、业务协同和评价机制搭建,最终形成完整的能力地图,通过工具和协议开放。

再比如,以订单的创建过程为例,我们传统的做法。需要梳理从能力规范、运行机制到配置管理和执行系统以及运营服务团队构成的整套标准,才能真正为各业务方提供快速、低成本的创新能力。

图6 通过业务中台,为各个前台业务提供统一的订单处理能力

最终,业务中台将通过各种层面的产品和服务来落地:

  • 业务能力图谱。
  • 业务需求分解和配置的工具。
  • 业务流程设计和配置的工具。
  • 业务指标度量和跟踪的工具。

基于这些产品,把每个业务它是怎么出来的,出来之后做了哪些业务需求和业务活动,每个业务活动的效果是怎么样的,都沉淀下来。在此基础上,通过统一的运营平台作为中控单元,把整个业务中台串起来,将业务逻辑与具体实现的分离。

数据中台

数据中台的核心在于从数据技术、数据资产、数据服务等各个层次,进行规范和标准化:

  • 数据技术:数据如何采集,如何存储,如何进行离线和实时计算。
  • 数据资产:全域的数据治理,包括建模,数仓,数据集市等。
  • 数据服务:包括对外和对内以产品,接口或者中间件形式提供的各种数据服务。

图7 数据中台实现真正的数据统一、实时、在线

因此,数据中台将通过下面这些产品落地:

  • 统一的数据采集、存储、计算平台。
  • 统一的数据资产管理平台。
  • 统一的数据研发工具平台。
  • 丰富的数据服务,完备的数据集市和统一的接口/中间件。

业务中台与数据中台的关系

业务中台和数据中台是相互促进的关系:

  • 业务中台数据同步到数据中台,结合外部生态数据,面向场景要求选择(或设计)合适的算法,进行数据的计算,实现数据在洞察和预测方面的价值。
  • 大数据分析的结果要能反馈到业务生产系统中,实现对外提供数据服务,对内提供数据驱动业务运营。
  • 数据服务中心在这个架构中,肩负起业务中台和数据中台的双向交互职能:一是通过数据中台的能力负责业务中台各中心对跨中心或业务场景下数据需求的收集、反馈和实现;另一方面负责将数据中台的数据分析后的价值辐射给业务中台其他中心。

总结

关于中台的文章已经有很多了,本文主要是讨论之前在负责货车帮时的一些思路。总得来说,我认为:

  1. 中台不是目的是手段,需要根据各个公司自己业务和团队的情况来量身打造。
  2. 中台建设需要强健的基础设施,还需要组织架构、企业文化、流程制度等各个纬度的支撑。
  3. 负责建设中台的团队要有很强的业务抽象能力和很好的服务精神。
  1. 《企业IT架构转型之道》 

  2. 《企业应用架构模式》 

  3. 《领域驱动设计》 

  4. 有些地方称基础设施为技术中台。我觉得基础设施是国内外(国外叫 infrastructure)同行使用已久一说就懂的词,没有必要为了追求和「业务中台」、「数据中台」文字上的对称就胡乱发明概念,而且这层很明显不是跟其他两个中台平行的。 

怎样读书(3)

目录



前面说了,有的书增长智慧,有的书提升技能。

它们挺好区别,但用个表来对比会更加清楚:

加智慧类 加技能类
经验和原则为主 知识和方案为主
对广泛领域适用 对单一领域适用
难选择,但好看懂 好选择,但难看懂
看懂之后也难以实践 看懂之后就很好实践


因为适用范围更广,读起来的舒适度更高,并且仍然代表了主流价值观等原因,「增长智慧」的书籍统治了非虚构类图书的畅销书单。

但这些畅销书和它们的读者也有自己的尴尬。

尴尬的鸡汤

我把它叫做「机场书店谜之尴尬」。

这是我出差的时候发现的:每个机场书店,一堆畅销书的中间,总会有一个电视机,在播放某位大佬关于「智慧」的分享:早些年主要是余世维于丹之类的,现在则是互联网巨头的管理者。

大部分人会忍不住拨弄一下那些畅销书,用余光看看其他人的站位,读一读,然后心安理得地捧起文学名著或者杂志。

我还看过不止十次各种年龄各种造型的人,围在电视机旁边听讲。

当有同伴走过来的时候,他们连忙指着电视说:「这帮骗子」。

人们无法抗拒畅销书的封面,那些让你在事业财富、身心健康或人际关系等方面取得突破的智慧秘籍。

这是个每年 300 多亿的图书市场。

那人们显而易见的尴尬又来自何处?

我觉得首先,很多人在公共场合给脑子进补,总有正人君子路过洗头房的那份尴尬

在公交车上看《守护好你的财产和爱》的人希望加个书皮。

在办公室看《怎样让老板听话》的人担心被老板杀害。

但除了公开满足任何私密需求都有的那点尴尬,我觉得尴尬可能更来自于怀疑

「它们有用吗?上次我读完的那本就毫无用处。」

我的建议

这方面的书我看得不那么多,下面是作为选择了「技能」的人,对「智慧」类书籍的一点粗浅的建议。

不要觉得尴尬

智慧类书籍被嘲笑为鸡汤不是没有原因的。

不要说写一本书,就算你给别人提两三点建议,也可能收到类似「你不是让我看清自己并接受自己吗?为什么又建议我针对有问题的地方改进和进步?」的反馈。

而作品越多名声越大越畅销的人,陷入这种可能的机会则大大增加:从于丹到格拉德威尔1,当人类面对的问题前所未有的困难和具体,掌握的技能前所未有的复杂和深入,那些「智者」提供的通用的、一刀切的建议,操作起来往往是困难的。

但是如果你认可「技能」和「智慧」就是两个东西,后者就是提高你解决大部分问题的平均水平的品质的集合,包括:自律、反思、同理心、经验见识等等。

那你是不是需要这些呢?它们在书里面是不是存在呢?

答案显然是肯定的。

「所有的智慧类书籍都是鸡汤」也是一种「鸡汤」。

但是确实要学会选。

特别不值得读的

当积极的规则(哪些是值得读的)不太好提炼时,通常可以先把消极的规则确定下来。

哪些不值得读?我看有两类。

假大空的自我修炼类

无论你做不做管理,大概都听过 GE 的前 CEO 杰克·韦尔奇

他最著名的书是《》,里面最著名的话是「reaching for the impossible」。

非常自驱,但又非常空洞:如果你具体看看怎么「完成不可能的目标」,就会发现他把各种观点 —— 包括「懂得坚持」和「懂得放弃」这样互相冲突的观点 —— 都铺陈了一遍2

总有一款适合你。

很明显,穆里尼奥如果只是在每场比赛开始前和中场休息的时候说:「来,我们赢」,他的年薪应该不是 1500 万欧元。

但稍微多读一点书你会发现,各个领域内都充斥着这种,一味强调主观能动性的力量,在具体观点上却异常模糊的书籍。

它们宣称把一切「消极」的思想都赶出体外,积极地、专注地追求单一的目标,就能够得到心里想要的结果:无论是你卧床不起了想着健康,还是你经商受挫了想着致富。

昨天看《布鲁克林秘案》,达福对着诺顿大喊:「你丫看点爱默生好吧」,让我想起来《好策略,坏策略》里提到的「New Thought」这个流派。

19 世纪初,爱默生提出了「超验主义」,强调人人都可以和上帝直接交流,且人人都有神性。

在这之前,无论中西方,能够与神对话,是少数统治阶级和神职人员的特权。

林肯说他是「美国孔子」,「美国文明之父」。

接下来就有了基督教科学派,认为一切物质皆虚幻,物质的问题都可以通过灵修来解决:心系成功就会带来成功,唯恐失败则会招致失败。

到了 19 世纪末,在加州混喜剧圈的淘金者普伦蒂斯· 马尔福德写下了《Thoughts are Things》,认为思想会吸引其他的不可见元素,通过自我实现,形成具体的可见的物质。喜悦和愉快的思想吸引好的元素,产出好的物质;担忧和恐惧则带来厄运。

这就是所谓的「New Thought」。

沿着这条线你去看那些精神励练或者灵修冥想类的书就可以找到清晰的脉络:

这些作者每个人都号称自己发现了秘诀,但你仔细一看就知道他们是一个门派的(比如 Byrne 就明确说 Chopra 是自己的偶像)。

并且这个门派经营得挺红火3:我看到很多个人和团体在实践那些正念和信仰的疗法,而且,我已经收到过四本别人送的《秘密》了。

我反对读这类书更重要的原因是,它们不但没用而且可能是有害的:

  1. 成功的因素往往是复杂的:认为全神贯注积极正向就能赢,只是抓住了人的一种心理,就是认为追求单一化的目标就会带来诱人的回报,自己遇到的问题只是因为「杂念太多太贪心」。一个反驳的例子是德法历史上的「儿童十字军」,他们带着无比的正念上路,大部分人死在路上,侥幸活着到达目的地的,男孩被殴打,女孩被强暴。
  2. 成功的复杂因素里积极心态起到的作用非常有限:如果你和我一样觉得苹果一开始的成功主要是因为沃大叔脑子里面早就构思好了个人电脑如何制造并且等来了周边硬件的成熟,而不是乔帮主进行了什么冥想,那这个不用解释。
  3. 坚定地追求单一目标的风险是巨大的:目标坚定并且一心想着成功,不会自动带来成功。但是失败了之后,打击是巨大的。我对各种具体的反思是欢迎的,对各种面向内心的自省是高度怀疑的。当然,大胆追求,深刻体验确实是强者游戏。
  4. 一切可能性都应该去面对和处理:特别是坏的可能。如果你让我选宇宙飞船,我肯定选「考虑过 2 万种错误场景如何处理」的那艘,而不选「心若在梦就在,may the force be with you」那首。如果你让我选合作伙伴,我也宁愿选择一个可以去考虑和应对不利情况的人。

神叨叨的绝技秘方类

我被成全影响,经常强调「重要的都是具体的」。

它的一个推论是,神秘的东西很少是靠谱的

我甚至觉得,古今中外的智慧就那么些4:面对事情的一些经验,和经验里面折射出的胆量、韧性、反思、正直、无私等品质的力量。

所以如果你看到有人说病是吃出来的而且还能吃回去,或者看到我们的前嫂子5搞了个 Goop 宣传售卖各种心法秘籍,包括取法天朝宫廷可以塞在下体的玉石,转身就跑是对的。

但是有些作者在传授武功秘籍的时候可没有这么好察觉。

比如「千万不要做并购,除非大家的文化一样」。

比如「穿上性感内衣和他在沙发上来一发就可以增进感情」。

比如「单体的应用带来了巨大的问题,微服务才是正确的架构方式」。

要知道,看起来不那么反直觉的秘方,还是秘方。如果你明明在寻找「智慧」,但是书里面出现了一个如此具体的建议,你应该做的是想想:

  1. 它对所有的情况都适用吗?
  2. 作者这么做奏效了,是遇到了什么情况,有什么样的条件?
  3. 我在什么情况,有什么条件的时候,可以试试?

特别值得一读的

我的挑选标准很简单:

  1. 经典老书
  2. 观点清楚具体
  3. 大量例子说明印证观点

形成这样的标准是因为:

  1. 智慧总体上内容有限,新作品很多是陈旧观点的演绎,要不就干脆是错的。而穿越时间的作品往往是洞察人性和社会架构,并经受了实践考验的。
  2. 虽然要适用于多种情况,但是它不能和稀泥,试着讨好各种想法的人。简单说,智慧必须是解(虽然很可能是局部最优的解),但它不能是一道新的选择题。
  3. 普遍适用的规则,其本身往往是简单的,提供大量实例的作者展示了自己扎实的思考过程,同时也可以让读者参与其中,然后再结合实际的情况进行运用。

理解最后一段特别重要:人们对这类书的抱怨很多时候是因为太着急。

在朋友圈转发一个颇有见解的文章就可以彰显自己的智慧,使得这种着急加剧了

如果你期待读几本书就能够获得智慧,对自己和对书的要求可能都太高了。「阅读—思考—实践」是掌握所有东西的唯一途径,智慧也不例外。

我的这类书籍的列表正在构造中。

「值得」和「不值得」之间

每个人有自己的安排。

我一般每半年花一整个周末来看看「智慧」书籍,以经管类的为主,但总的算起来占读书的比例里面很少的部分。

我不会花时间去读《明朝那些事儿》,因为它最好的情况下也就是让我再感受一下《水浒》《三国演义》里那些人性的光辉和挣扎,不太符合我的那三个标准。

但可能你很有时间,那么只要你不把阅读本身当成重点,而是伴随着思考和实践,读大部分这类「值得」与「不值得」之间的书应该都是无害的。

可是,这些时间,为什么不用来创造点什么呢?

  1. 格拉德威尔因为些了写《Blink》、《Outliers》、《Tipping Point》这些畅销书,被很多较真的科学家嘲讽为把偏见和轶事当规律。后来有人甚至为了嘲讽格拉德威尔,专门整了一个生成格拉德威尔式图书的网站。 

  2. 在看完书之后我充满好奇地去研究过他在 GE 实际上做了什么。说「杰克韦尔奇」就是个空洞的人肯定是不对的,但这里我们说的「杰克韦尔奇」就像「孔子」或者「荷马」一样,他们的作品里有多少是他们自己的观点,我们先忽略,只讨论(也许是别人帮他们写的)书里面展示和代表的东西。 

  3. 信徒虽多,也有意见领袖,但和 New Thought 的初衷 —— 大众不再受到信仰和观念的压迫 —— 却恰好是背道而驰了。 

  4. 这是互联网时代人类社会的一个挺大的悲哀。在历史长河中被记录并广泛流传下来的那部分东西往往是好东西。现在传得更快的往往是标题惊悚,文笔浮夸的垃圾。 

  5. 之前传出两个人离婚的消息本座还唏嘘了很久,现在真的是为 Chris Martin 感到庆幸,而且不分手哪有 Everglow 这样的好歌呢。