大家好，非常荣幸能够有机会和大家一起分享，我叫陈斌。The Art of Scalability 的作者 Martin Abbott，是我在 eBay 工作时认识的。去年，我将这本书翻译成了中文，名叫《架构即未来》。
我在 1993 年出国去到新加坡，担任新加坡航空公司的高级系统分析员。之后到硅谷，在硅谷参加了各种创业的活动，在不少公司做过技术工作。
2001 年，我在日立美国担任系统集成总监。随后在 Abacus 担任***架构师。2008 年，我在 eBay 和 PayPal 从事高级架构工作。在这段时间里，我有幸参与了 eBay 在架构方面的很多实践，也就是这本书—— The Art of Scalability 中讲的很多故事。
这本书是由两位作者完成的，一位是 Martin，另一位是 Michael。
他们写的***本书 The Art of Scalability，我翻译后取名为《架构即未来》，第二本书在今年四月份出版的，书名为 Scalability Rules，中文译名为《架构真经》。
这两本书分别从互联网管理实践，架构和技术方面，做了很多非常好的总结。这本书非常出名，可能有的同学已经了解了部分内容，下面我将会和大家分享。
CTO 必备的管理能力：人员、组织、过程
首先，我想从管理的角度和大家分享，主要涉及人员、组织和过程三个方面。
这三个方面在《架构即未来》书中，基本通过两个循环作讲解，分别是向上的正向循环和向下的负面循环。
所谓良性的循环（向上的循环），是指合适的人员在合适的组织方式的组织下，通过合适的流程所规定的活动，使项目和系统不断地优化，不断地向前发展。
向下的过程是指与此相反，过程不合理架构不合适。当处在这些不合适的情况下，各种活动及项目就会出现完成后成员互相埋怨对方没有做好，导致越做越差的负面效果，而这种效应就会叠加。
所以我们希望我们的组织和团队都有正向的良性的循环，不断地从一个成功走向另一个成功，越做越轻松，越做越简单。这就是人员组织过程主要讲的内容的逻辑。
人员
这里要和大家分享的是书中提到的：领导力和管理能力的问题。
这也是我回到中国之后发现的，不仅仅互联网而是很多企业都存在的共性问题：大家不区分领导力和管理能力。
领导能力是指如何带动一个企业不断地向前走，靠的是***个人的魅力，***对理念目标和使命的引导，去激励大家。而管理能力是指把一个大的目标分解成小的目标，小的目标进一步分解，让员工高效率地实现。
领导能力和管理能力的主要区别在于力量的方向。领导力是像火车头一样牵引团队的动力。管理力是在团队后面推动的力量，让团队向前走。
两者所需要的技能是不一样的。领导力需要以身作则，有自知之明，或很谦虚，使命为先。更多的是一种天赋，领导精神和牺牲精神。
而管理的能力呢，更多的是关注细节分解任务，要善于沟通，善解人意，能够有很强的执行力。这是两者的不同点。
本书还强调了企业及企业文化。他用一个花园来比喻企业，花园里的土壤就像企业的文化。我们谈起企业文化，总认为只有中国才讲究的话，其实到了美国更加讲究企业文化。
良好的企业文化，就像花园土壤的土质很好，可以长出很多好的花花草草。那这些花草就是企业的员工。
当然有很漂亮的花也会有奇葩。奇葩或者不合适的草，即不合适的员工。而管理者就是企业这座花园里的园丁。园丁的责任：施肥除草，淘汰不合适的花草，进行选材。
我从硅谷刚回来的时候，很多人问我：能不能帮忙介绍一个硅谷的大牛，我们公司上市就差这么一位大牛了，或者是有了这位大牛，公司才能如何如何……
我们认为人员是组织过程中的首要元素，但人员没有***，只有最合适。
我经常用 Steve Jobs 的例子来说明这个问题：Steve Jobs 在三十岁的时候呢，是一个很自负，孩子气的一个人，不负责任，缺乏团队精神，很多项目朝令夕改。
结果，员工和企业不欢迎他，被迫离开了苹果。而当他四十一岁重返苹果的时候，他变得很负责，很自律，不仅保持了自己的创新精神，还加强了产品的经验。
那么同样一个 Steve Jobs，为什么在十年前被企业扫地出门，十年后成为天才，带领苹果腾飞，使苹果有了今天的成就？
原因就在于十年前他不是一个合适的人，并不是说他不是一个牛人，不能打造***的产品。但是十年后，经过历练，他变得更适合团队，也更适合环境，所以才会有他和苹果当年的成功。
关于人员，要和大家分享的是，如何像园丁一样对花园里的花花草草进行区别考评，优胜劣汰。这就是这本书里特别讲到的 BP 模型。B 指 behavior，指员工是否符合企业文化，P 指 Performance，指员工是否具有能力创造业绩。
那么公司管理者最喜欢的是既符合企业文化又有能力的人，即处于***象限，要保留的精英。相反，如果是对企业文化不认同，技术的能力又差的员工，就是需要淘汰的人。
而第二象限代表的员工，是管理者需要培养的员工。这类员工有专业的能力，是不同领域内的专才，但是企业文化方面比较差，这样的员工可以通过培养让他成为精英。
关于人员，还有一件事要和大家分享：如何使我们的人员能够在一个企业里留得住，发展好。我从美国回到易宝支付之后有一点感触非常深刻，就是这么多人，却连一个架构师都没有。
一个总监领着大家做，可能会有一些初级研发啊、中级研发、高级研发，但是没有架构师，大家做的事都是一样的。
***我们做了一些改变，我们有研发架构、测试架构、网络架构、安全架构、配置架构、系统架构和数据架构。
那这些架构师是怎么培养呢？首先，工作经验很关键，因为架构师需要一定的经验积累。我们认为七年以上的工作经验足以胜任一个架构师，从而给员工成长的空间。
组织
《架构即未来》这本书里还提到了一个非常有价值的概念，也是我观察到的，硅谷的企业和国内的企业之间的一个差别：即在业务和技术之间沟通上的问题。特别是主管一级人员沟通的问题。
比如说业务主管会强调要完成什么业绩；而技术主管在讨论的时候经常强调有什么问题，什么技术细节，什么 Bug，什么无法解决的问题，这两者很难沟通到一起。
原因是很清楚的：因为业务主管和技术主管在教育背景、经验背景和性格特质上差别很大。一个内向，一个外向；一个是学理工的，一个是学经济和管理的。
特别是他们成长的路径，业务主管往往是业绩做得好，技术主管往往是项目做得好研发做得好。
组织内的冲突，是我们探讨人员的时候必须要强调的。
组织内的冲突：一种是认知型冲突，一种是感情型冲突。当我们在做一个项目的时候经常有疑问：谁来干这件事？这就是一种感情型冲突。
人作为一种高级动物，我们都会有保护自己的本能，而这样的情况往往在我们做项目的过程中是存在一定破坏性的。
作为一个架构师，应该及时发现这种冲突，制止这种冲突。我们在项目进行的过程中需要冲突，但不是感情型冲突，而是认知型冲突。
那什么是认知型冲突？认知型冲突是指在决定要做某个项目，对执行方案有不同意见时，我们要从中选出一种***方案。
所以当一个团队在讨论什么是***方案的时候，***的组织方式是讨论时，参与人员有年龄差异，也有岗位和职能差异，能从各个不同的角度对方案提供不同的意见。
我们再从中选取一个***的方案，这是保证项目或研发走向成功的基础。只有当选择的方案和策略是对的时，结果才有可能是正确的。
还有一件让我印象深刻的事：在我们的互联网企业，特别是国有企业或者是大型的传统型企业中，常常分成两种思维模式：
- IT 思维模式。
- 产品思维模式。
所谓 IT 模式，指的是 IT 部门往往服务的是企业内部客户。比如说公司的 IT 部门，其提供的服务可能是 CRM 系统或某种业务系统。
那么在工作过程中，这个部门主要考虑的是成本，因为 IT 部门的成本是直接计入公司成本，需要尽量节省成本。
还有一个要考虑的因素，是公司内部的客户的满意度。在这种情况下，产品做出来后，如果内部客户反馈不好，常常是采取企业内培训的方式，培训到用户会用为止，可能产品很差，但是培训跟得上，这就是 IT 思维。
而产品思维，特别是互联网产品思维呢，他不知道他的用户是谁，在哪里，或仅知道用户某种类型，但不具体。
那么这个时候就会采取试错的办法，做出一个产品后投放到市场上，根据市场反馈，作相应的修改。而关于成本，产品人员更多考虑的是产品能赚回多少钱，而不是花掉多少。
我们再来探讨组织，人员都是要靠组织组成起来的，那什么样的组织最合理？
《架构即未来》书中讲了一个两张披萨的故事。亚马逊 CEO Bezos 曾提到，沟通是很可怕的事情。他要求亚马逊的团队规模不能超过两张比萨饼能喂饱的人数。两个披萨能喂饱多少人呢？
我们简单计算一下：八寸的这种披萨大概两张能喂饱八个人左右。所以团队的规模不能太大，过大的团队会造成噪音的存在。规模***是七到八个人，其中有主管、架构、项目管理、研发和测试。
说完了组织规模，还要考虑组织的结构。大家都知道我们现代社会的工业或企业的组织结构是按照军队的线性结构设计的：骑兵在一起，步兵在一起，通讯兵在一起，炮兵在一起。各兵种之间有纵向的领导和横向的合作关系。
随着工业发展，当我们提供软件服务，这就需要研发人员、测试人员、运维人员、项目管理人员和产品人员，大家天天在一起去讨论问题、解决问题。当项目结束，软件研发成功后，团队解散。这就是矩阵型结构，非常适合软件行开发企业。
第三种情况，是指将所有项目人员放在一个团队里，即敏捷型组织。这种敏捷型组织呢，所有的人在一个团队，沟通更顺畅，更容易形成合力解决问题。
这种方式最适合 SAS 服务，即对外提供的是软件为基础的服务。我们可以根据自己企业所处的不同阶段，所提供的不同产品和服务，选择合适的组织机构。
过程
除了人员和把人员合理地组织起来工作以外，还有一个重要的事情是过程。过程是指将所有人组织起来的活动中，大家按什么逻辑和方向来走。
很多公司，包括易宝支付，我都发现这样的问题：一个公司，特别是运维系统发生一些问题，管理人员会怎么办？
大家往往会追究是谁的责任，然后处理责任人，如扣奖金、记过处分、甚至开除。往往把处理人作为主要的目标和主要的手段。
这里有张伯克利一位教授的图，借用他的图，我们来说明上面这个问题：一个系统由软件硬件测试、脚本、网络等很多要素构成，图中每个红点代表的是软件中的 fault 或 Bug。
平常的它们相安无事，当外界用户的输入进入，如某种输入情况、某种流量或某种 profile，可能会引发这些 fault 或 Bug 出现问题。
如果你的系统有合理的监控，能观察到这些蛛丝马迹，系统就可以避免出现大的问题。相反如果观察不到，系统就会失去目标从而出现大的问题。
所以，当我们在考虑过程中所出现的问题时，我们应该聚焦在系统，也就是软件硬件网络当中的 fault 上。一定要在每件事情发生之后聚焦为什么会发生这种问题，其根源在哪里，而不是聚焦在人上。
当我们把这些红点，fault 都解决掉，那么系统就不会在同一个地方栽两次跟头。这就是我们强调的，要聚焦优化过程和优化架构，而不是聚焦人。
除了优化架构、优化过程以外呢，《架构即未来》书中还多次强调了 CMMI。CMMI 是由美国某大学同国防部在承包项目过程中制定的一种流程管控的办法。
这种办法认为，无法度量的流程是差的流程，而好的流程不仅可度量，还能很细致的度量，***的情况则是流程拥有一个成熟度模型，能够分级评估。
即使企业不提供外包服务，我们也需要优化流程：有合适的人员、合适的组织方式、合适的流程、合适的决策使项目不断地从一个成功走向另一个成功。这部分就是我跟大家分享的《架构即未来》书中提到的关于管理的内容。
架构设计理念
关于架构设计的理念，其中提到的时间，均在《架构即未来》和《架构真经》中有提及，让大家了解架构师如何做设计。
今天要讲的理念是：非技术设计。所谓非技术设计是指在设计互联网或信息系统架构的时候，要像建筑师一样去考虑问题：设计一座房子时，我们要考虑房子的结构，承重强度等。
当我们在做架构设计时往往考虑的是：前端用 Java 语言、Tomcat，然后通过 MySQL 放在某某服务器上、某某存储上，然后由某某路由器来负责完成。
如果不知道的人看到这种设计一定会说架构师是收了人家钱在打广告吧。实际上，真正的架构设计是不应该考虑任何产品的，而是为了满足用户的需求，选取最合适的手段和方式来完成。
架构设计要回归事情的本源，这里讲一个故事：当年美国和苏联太空竞赛，双方遇到在太空无重力状态下无法写字的问题。美国的做法是花巨资研发一种新的太空笔，当这种笔研发出来后，他们发现竞争对手苏联却一直在用铅笔写字。
这里是想告诉大家，我们在设计系统时，必须要从事情本源出发，而不能只考虑用什么系统、什么技术，因此归纳出这个概念：非技术设计。
在设计的时候从非技术角度考虑，不要一开始就给出技术解决方案，或许要解决的问题因为某个业务上的改动或者某个流程上的变化，就不需要几个月的开发工作了。
这里有两个过度设计的例子：设计一个空调。如果设计一种空调在绝对零度到零上三百度都可以用，你也许能够实现，但需要耗费大量资源，却完成了一件没有必要的事情，就如同美国太空笔一样。绝大多数人不需要在这样极端的环境中使用空调。
过度设计不仅指超出实际需求的设计，还包括过度复杂的设计。比如你要求你的助理把附近某便利店中的所有商品一种买一样，却只用其中一样，然后把剩下的商品都送回去。
这样的做法听上去很愚昧，但实际上，我们在架构设计和系统实施过程中经常会发生类似问题：我们在调取一个数据的过程中，经常会把数据库中的所有数据都搬出来，却只找其中的一个记录。
这两个例子启发我们：在架构设计的过程中，不要过早考虑技术因素，而是脱离技术，回归到事情本源去解决问题。
