申请加入亚杰

《架构即未来》读书会

作者:站长 时间:2016-10-28

7月26日亚杰商会邀请到了《架构即未来》译者陈斌先生为我们深度解读此书,让创业者能够更加的易于理解技术架构和管理,从中汲取能量!


《架构即未来》由易宝支付CTO陈斌先生翻译,磁云科技CEO、京东集团终身荣誉技术顾问李大学先生亲自作序;原阿里巴巴副总裁徐子沛先生和宜信宜人贷首席技术官段念先生联合力荐的一本书。一经面世月销量就超过一万亿册,在这本书当中凝聚了作者在多年来在不同的互联网公司和咨询过程中积累的丰富经验。

下面是小编根据嘉宾分享整理的干货。

陈斌我翻译《架构即未来》这本书,是因为我发现在易宝集团里面,很多的架构师、研究人员、技术人员有很多通病,他们在一些技术的决策上经常会犹豫不决。其实有很多东西都是有固定的思维模式,所以我就想,我能不能把在国外的经验,硅谷的经验写成一本书。我们有一段时间开始写了,后来发现《架构即未来》这本书,这本书讲的事跟我要写的其实是一回事,最后就促成我翻译这本书。
 
本书是两部分,一部分是讲技术管理方面的一些思路,另一部分是讲技术架构的思路。
 
我们为什么一直把《孙子兵法》跟架构搞到一起去?这本书的两个作者虽然是美国人,但他们都是军校毕业的,非常喜欢研究《孙子兵法》。所以他们看很多技术架构的问题,看很多技术管理的问题,是用我们《孙子兵法》的观点去看的,每一章开篇的时候都会讲一句《孙子兵法》的一句话来概括那一章的内容。《孙子兵法》里面讲过一句话,就是“故善战者之胜也,无智名,无勇功,故其战胜不忒。不忒者,其所措胜,胜已败者也”,意思是真正善于用兵的人,没有智慧过人的名声,没有勇武盖世的武功。而他既能打胜仗又不出任何闪失,原因在于谋划、措施能够得以保证,他所战胜的是已经注定失败的敌人。由此可见架构设计是决定未来成功的关键。 在管理当中如果我们有这个人员和过程的交互,如果这种交互不断地向好的方向发展,我们叫良性交互,再配合以技术,有好的决策,这种就会循环地向上发展。相反,如果人员跟过程配合得不好,导致不良的技术决策,那么就会不断地向下盘旋,形成一种恶性循环。

互联网企业经常犯的一些通病
1
领导和管理,其实是不一样的
领导活动是描述愿景、制订使命、设定目标、组织激励,制定标准、营造文化的氛围。管理活动反过来是根据你的愿景来评估这个目标怎么去实现,怎么度量,怎么协调,怎么管理,怎么评估,怎么培养人。所以领导是一个牵引的力量,而管理更多是一个推的力量,这是两个不同的力量,两者的胜任标准和素质要求是不一样的。
2
企业其实就像花园一样
土壤是企业的文化,花草是企业的员工,领导的关怀就跟阳光一样,养分是员工培养的。不合适的员工是杂草,好的员工是鲜花。当你是一个园丁的时候,你看到园子里有很多杂草,你把它拔起来,你永远不会感觉到后悔,因为你早拔出来一天,周围其他的花花草草就会得到更多的营养和水分,不会遮挡光。我们需要工作态度好,专业技术能力好的这种人,我们最不想要的杂草是怎样的?态度太不好,技术水平很差。
 
3
没有最佳的人选,只有最合适的人选
乔布斯31岁的时候进入苹果公司,以他的孩子气,粗鲁和自私的问题,对公司的流程、管理过程,无视这些过程,结果造成苹果公司士气低下,他不断地改变产品的结构和思维,最后使产品缺乏聚焦和连贯性,结果被公司赶出苹果。十年后,在乔布斯41岁的时候,他重回苹果并担任CEO,他经历锻炼以后非常成熟。同时保持着对产品完美度的疯狂追求。在这种情况下,他就更加自律,再加上与生俱来的能力,那么就带来了扭转公司局面的这种新的形势,新的领导力,而且形成了新的产品,新的形式,最终他取得了成功。很显然,在乔布斯30岁的时候,他是一个很有能力的人,但是他的行为,他的做事方式不适合苹果公司当时发展。当他41岁的时候,重返苹果,他的成熟,他的自律、他的负责,对苹果来讲是合适的一个人,整个技术的决策对管理是有正面的作用。所以我们没有最佳的人选,只有最合适的人员。
 
4
业务干部和技术干部的沟通鸿沟
技术主管往往描述了一圈,说了很多事情,业务主管就等着一句话,到时候你能不能给我搞定,比如下个月你能不能搞定,其他你讲的我全部不懂。他都不懂,他怎么能理解你?原因很简单,就是技术主管和业务主管的教育背景、经验背景,和他们的性格特质是不一样的。两个成长背景完全不一样,那你要他们两个怎么有共同的语言一起去做事?这就需要技术主管主动跨过这个鸿沟,解决沟通的障碍。因为对技术主管来讲,如果他多学一点财经的东西,能看懂资产平衡表、债务报表,并不是很难的事,而且经验背景对他来讲也无所谓,其实公司更多的是给技术主管和业务主管更多在一起沟通的机会,教会他们互相沟通的技巧。
 
5
冲突
一个团队内部有归属感,但同时团队之间也有排斥感,这就是我们产生冲突的一个重要的原因。当一个事情出现了,我们说这件事情谁来做,是这个团队,还是那个团队做,这种就是恶性冲突了,我们最不希望看到这种恶性冲突出现的。当一个问题出来,大家在讨论的时候是讨论怎么来做,用哪个方案来做,这种是良性的冲突,是我们每次要叫头脑风暴,就是要做这些事,我们要尽可能抑制恶性冲突,特别是做管理的,看到恶性冲突立马要想办法制止,要鼓励良性的冲突。
 
6
IT思维跟产品思维
IT思维是什么意思呢?咱们普通的做IT的,其实从开始的时候IT都是公司内部自己搞,自己写程序,自己搞很多事,外面买软件。做IT本身服务的对象是谁?是公司内部的其他员工,他的用户是可以被抓来的,他通过培训能教会你怎么用,再烂的系统也让你们学会怎么用。而产品思维的人他们想问题的时候首先想到他的客户,特别我们做互联网企业,他想到的是广大的,平台以外的,我不知道的那些用户,他也不可能把用户都是抓来说培训一把,他甚至都不知道是谁,怎么培训?只能是通过不停地迭代,不停地用户反馈来快速地响应用户的需求,揣摩用户的需求,这也是为什么互联网的服务做起来比传统的IT服务要困难,因为你的用户是你不知道的,是你很难揣摩或者抓到他的需求点,和他的痛点的。所以我们鼓励的是要有产品思维的人,最忌讳的是用IT思维来做互联网的业务。
 
7
团队的规模
怎么把人员组织和过程搞好。对于一个团队,多大算好,多大算小?这个就是一个例子,这本书里讲到,就是亚马孙的CEO,他们在团建的时候出去,他就讲沟通太可怕了,其实你仔细想想,一个人不需要沟通,两个人要沟通,三个人沟通,四个人沟通,人越多沟通的成本会越高,越难。如果一个团队有超过某个数的人往往沟通起来就变得不可控制。所以一个最有效的团队的大小是多少呢?是两张披萨能喂饱的那些人,这个是讲美国的八寸披萨,8个人到9个人,看肚量多大,一般是8、9个人为好,就是说在团队里有团队负责人,有产品经理,有架构师,有研发人员,有测试人员,有相应的项目管理和运营人员,这样的话团队的整个沟通效率会非常高。
 
8
团队的组织结构
有三种不同的类型,一是直线的职能型的,就跟军队一样,大的工厂都是这样。研发的在一起,测试的在一起,运营的在一起,做什么都在一起,这种方式是适合以前的内部IT 系统。但如果你到了要对外提供软件,像微软一样,你就不能再走这种路,会在纵向的壁垒上出现问题,所以就需要打破壁垒,让大家把不同的人员,研发找一个,测试找一个,运营找一个,产品找一个,项目管理找一个,组成一个矩阵型组织,可以快速有效地完成某一个特定的任务,往往是我做一个软件开发,这个软件开发周期完了,这个团队就散了,这是很有效的。这个保证了效率,但是这个也有问题,这个问题是说每个人都变成神经分裂,俩老板,常常左右为难。三是敏捷型组织,就是把研发测试运营,所有跟一个项目相关的,全部都关到一起,你们就这一票人干这票事,也不用出去找别人,你所有需要的资源都在这里面,自给自足,充分授权,这个最好的是干什么呢?比如我们现在对外提供服务的,这是最好的,因为他的优点是能够最大程度地保障创新能力,你不会因为一些杂事受到影响。还有第四种共享经济型组织,就是像今天的优步和滴滴打车,这种情况下的新的组织形式,在新的这种共享经济情况下,把很多社会上片状的资源,分散的资源给集成,使用起来,这是新的一种组织形式。
 
9
过程
合适的人员配合合适的组织结构,最关键的还是要有非常合适的过程,把大家的活动组织起来,这样才能取得成功。其实对一个技术组织来讲,过程的成熟与否是决定了技术决策和你技术人员、组织互动成功与否的一个关键。比如说你的流程,你的过程是没有经过检验的,这是一种情况。经过检验的是一种执行,是一种量化,除了量化还可以不断优化,有不同的方法。我这里讲的是CMMI模型,就是通用的,在美国的一个大学里专门为政府项目研究的时候提出的模型,根据你的流程和过程的成熟度,0级,1级,2级……一直到5级,你可以是流程可以管理,可以定义,定量化,所以根据不同的层级,不同的成熟度,我们要确保我们的流程,或者是过程不断地成熟,这样的话呢,才能保证你合适的人员和合适的组织配合这个成熟的过程,取得成功。
架构原则
 
 
后一部分跟大家讲的是架构原则,这部分是更加技术方面的,作为架构师,作为CTO,在日常的决策过程中会需要注意或者需要了解的15个原则。这15个原则,大家看着都很朴素的,但实际上在你技术的设计工作中非常常用。
 
1
N+1设计
N+1原则是经常会有人说,我们要布几个数据库,其实我们叫N+1,就是说你永远都给自己留一个,一个给用户,你有一个是给失败用的,因为你想,如果一个应用,里面有一个给用户用,给下一个版本做更新,你有可能在这过程中死掉一个,你最少三个够用。这是经过很多架构师反复实践得到的一个原则,其实我们叫三原则,数据库要三个,服务器要三个,很多人看到是三,这本书的后边有专门一章讲三原则,叫魔法的三原则,大家有空可以去看一下。
 
2
回滚设计
当你要求一个新的产品上线的时候,你必须要有你完善的方案,要知道怎么操作,同时知道怎么回滚,还有在上线变更的时候,要根据性能或者交易的流量及时采取措施,这三条少一条不准上线,不准变更,这三条就反应回稳的设计。而这里面有一个必要的细节东西,当你做技术设计的时候,不管你什么版本,怎么迭代,你的数据库永远只做加法,这个是一个小秘密,很多数据库的DPA一来就说我很厉害,数据库这么乱,怎么清理干净?其实是永远不要清理,只做增量,因为你不知道你什么时候会回滚到哪一步,但你一旦要做了清理,你就形成了断带,你的数据库就不会跟你的用户相匹配了,这是一个非常有用的原则。
 
3
禁用设计
经常有应用设计是没有做禁用,就是当你的应用出现问题的时候,你没有回旋余地,一般就一条路,要不就走过去,要不就死掉,这就要求你必须有一个禁用原则,我禁用,我有什么其他路可以走,你要想清楚,这个是作为原则要求的。这个做的比喻是说你生产一个汽车,没设闸,你就直接开就好了,我们要生产汽车肯定不能这么干的,但我们做应用,大家回想一下,我们多少系统设计都是没有设闸的?反正就跑就行了,从来不想让它停,但真的有问题你想让它停,想让它换一个路径的时候怎么办?没有人想,这是一个很大的问题。
 
4
监控设计
这个也是跟车是一样的,你开车的时候肯定要监控速度、油量、发动机温度等等,但是我们很多应用,只做应用,不做监控。作为一个单独存在的应用,你要有完善的监控,你在做变更的时候你要看着你的监控,你才可以做变更,你没有相应的监控,你不要做变更,这样会逼着大家把监控设计完善起来。
 
5
多数据中心设计
这个大家都知道数据中心一般要有两个,一个热备,一个冷备,但其实上如果你看这本书,他会跟你说数据中心放得越多,你的成本越低,可能这个东西跟大家脑子里的想法是不一样的,数据中心多成本也多,其实是不对的,这本书讨论清楚了。
 
6
采用成熟的技术
如果从一个软件整个的生命周期看,从它的初期开始有人去采用,到后期大家逐渐抛弃它,到最后没有人在用,基本上是照着这个线走。当20%的人在市场上用这个软件的话你就去用,你不要说等到70%、80%的人在用了再用,20%的人在用你就去用,到剩下20%在用的时候你就赶快撤,特别是开源项目,要有一个比较清楚的判断。你可以去看开源项目的发布周期,迭代多快,如果每星期都迭代一个那千万别用。
 
7
泳道原则
就是隔离故障。什么意思呢?在理想情况下,一个应用它最好是它下游的被调用的应用和它的依赖的数据库都在同一个泳道里,就是说你游泳的时候,只顺着一个方向在游,旁边两边都会有塑料的绳索给你分开,避免你弄太多浪花,或者别人弄太多浪花影响你,这是一个理想状态,真实生活中,很多都会说我这个要调到那个,那个要调到那个,很难做到只顺着一个方向,你往这个方向走是没错的。这对于你判断这个应用是应该让它这么分一下,还是说再起一个给服务单独用会很有借鉴意义,如果你的应用及其关键,那你最好全都自己的,不要去跟别人有任何交叉。
 
8
扩展的原理
扩展包括水平扩展与垂直扩展。所谓水平扩展就是说你可以根据老板兜里的钱去买更多机器,水平地去扩展。垂直扩展是指今天这个机器做这个应用,不够用了,我换个大点的,然后我老板有钱我再换大一点的,不行我再换大一点的,因为你这种扩展是有顶限的,到一定程度是没办法扩展的。所以今天开会很多企业大家都喜欢的是水平扩展,都希望我不停地铺机器,只要有钱我买普通的机器就可以用,这里面讲到三轴扩展理论,就是说X轴是不断地克隆机器,Y轴是拆分应用,Z轴是按照用户的属性进行数据库的分解。X、Y、Z三个加到一起使你的应用适合任何海量的调用,是没有问题的。
 
9
商品化原则
公司里的系统管理员和网络管理员经常是贴人大战,自己想不明白的事,就是我什么时候该买什么东西?在硅谷流行的很简单,你就去买街上卖得最便宜的那个设备就对了。比如你买服务器,你不用去分析性能怎么样,哪个最便宜就买哪个。原因是说这个服务器之所以最便宜,是因为它经过市场的充分竞争,服务器里面的元件已经商品化了,只有商品化的元件他才会便宜,部件坏了,买一个换了就行,成本又低,影响又小。
 
10
非核心则购买原则
你要研发一个东西,你的目的是要为了在市场卖这个东西,作为一个产品,你能做出来差异化的竞争优势,就是你比市场上已经有的这些都牛一些,别人能买你的,那你就去做。但如果你是说我们做的这些东西为了给公司内部用的,别去做,因为你去做了,然后你还要维护,还要长期维护,会形成公司的技术负债,并不是给公司在节省资金,这种事不要做。这个时候架构师就要立即否定了。
 
11
小构建,小发布和快试错
这个大家很清楚,如果你一个应用发布里面有很多改动,你要发布了之后结果是怎么样?出一点问题很难查,因为里面的东西太多了,但反过来,你的发布只是里面改了一点东西,错了你就往那怀疑,就那东西,不会有别的,但是作为互联网企业,我们更重要的可能是VC的钱,老板的钱拿来了,我投资进去搞6个月才能发现跟市场不搭边,还是说我一星期扔出去一看,市场没反应,这事不靠谱,别做了,所以这个就叫快速迭代,快速试错,通过你的小的迭代来试探用户,取得用户的反馈。
 
12
异步设计
就是我做一个东西,往往就是从头到尾调用,全都调用,很紧密的,就像我们系统前一段时间,一个应用系统死掉,造成一个重要的应用系统死掉,因为应用系统太忙,或者硬盘出了问题,写不进去了,所以关键系统死掉,这是很愚昧的事,这就是没有遵循这个原则,你所有的应用,第一个应用到第二个应用,第三个到第四个,这种应用,你如何中间都让它隔开,它之间通过Q或通过其他的方式来异步实现数据和信息的交流,而不是所有都紧靠在一起的,这个是很关键的,这个不仅仅影响你系统关键业务死掉的可用性,重要的是如果这个执行得不好,会造成你系统的扩展性差,还会造成你系统的成本升高。
 
13
无状态设计
这是在硅谷用来衡量一个企业是不是成熟的公司一个重要标志。很多公司因为忙,所以做的应用都有状态,就是有黏性的,如果有黏性,结果很明显,就是我所有的机器不管我放多少,你的应用用户请求过来只能进一个,因为它有黏性,它只认那台机器,它要找回那台机器,这就要求你做一个合理判断,你系统操作以后要前后关联,要有黏性,那没办法,你能不能暂时存储呢?存到哪里?是不是可以先存在客户端,或者在用户手机上,能解决最好,解决不了能不能说我放一个集中的地方去存储呢?如果实在不行,我才放到数据中心里面,所以这个是一个标志性的成熟度特点。
 
14
前瞻性设计
作为架构师和CTO,当你在做设计的时候一定要看到眼前的,我们叫HE的,你要看到从现在再加一代的东西,你要做一定的研究和站到这能看到再下一代的东西,所以对目前社会上或者科学上很多技术新的进展要有敏感性。如果现在你是做互联网金融,区划链你是不是有所布局,或者深度学习你是不是有布局,或者是不是有预研发,这都是很关键的。
 
15
自动化原则
就是能够自动化做的就不要去手动做,这是我感觉在中美文化上这方面的差别,老美是很懒,能把它搞自动化,千万别用人去做,恨不得所有的东西都自动化。我们是可以搞很多人去,不行的话我人肉扛上去,要多少人我找一片人来,但实际上人的问题不仅仅是成本,更多的是当人在做这些交互过程的时候,人都会犯错误的,不小心或者是没有意识,或者是沟通不清楚,会造成各种事故,所以我们希望能够自动化的,通过编码现在很难,测试可以,CIC集成可以,监控可以,所以能自动全部把它自动化掉,这样让你的运营成本降低的同时,可用性和改发性提高上来。

Copyright © 亚杰商会 版权所有 13018368号-2
地址:北京市海淀区北四环西路66号中国技术交易大厦B座17层1728室
本站SEO服务及技术支持由Netconcepts提供