本文共 4357 字,大约阅读时间需要 14 分钟。
,作者:Martin L. Abbott and Michael T. Fisher,是一本关于扩张中的企业组织采用web扩展来增长他们的产品和服务的书。也谈及了技术和架构的实现,以及处理扩展也要上升到组织的结构。目的是为读者展现如何组织技术、人和流程来达到良性循环的目的,以及持续改进的方法,从而实现可扩展性。
\近期发行的第二版新增了来自Apple、Spotify等公司等实际案例,还挑选了第一版发行以来被认为是至关重要的一些主题,InfqQ就这些内容采访了作者。
\InfoQ: 可扩展性看起来是个技术问题。你是怎么想到通过组织这样一个角度来写这本书的?
\\\\\我们在8年半之前创建公司的起初时间也是这么想的。当时我们只是想帮助一些公司在技术/产品架构上的事情。但是一次又一次的经历后,我们发现虽然在产品架构内会表现出一些扩展的限制的症状,但是组织和流程的性质也是引起的原因。因此之后,我们就开始专注于组织、流程和架构,将问题扼杀于萌芽之中。
InfoQ: 那么谁应该将本书的阅读放在首要位置,IT专家还是IT管理者?
\\\\\我们认为本书是为诸如专注于产品的工程师、工程管理人员、工程执行人员,以及产品经理、产品管理人员而写的。此书的其中一个前提就是工程师需要有业务知识,经理和管理人员要有产品/技术知识。本书聚焦于那些要创建最好的产品的人们-能够同时理解业务开发和产品开发并能从中找到有价值的内容。
InfoQ: 在书中您谈到了人是一个可扩展系统的重要部分,你能在这里阐述下这个观点吗?
\\\\我们经常开玩笑的说机器人给我的启示正如电影“终结者”那样,但是它目前还没有那么的先进。因此,人仍然是定义产品的不二选择,那么或明或暗的表明人是有局限的。因此,人才是扩展方程中最为重要的部分。
InfoQ: 对于可扩展来说除了人之外三个最重要的方面是什么?为什么会这样呢?
\\\\\
- 流程:根据你的公司的成熟度选择合适的流程。流程太多就会扼杀创新,太少又会带来灾难。适当的流程会是导轨的形式,能够有助于产品计划在正常的道路上行进,哪怕是在我们人类有着犯错的毛病。 \
- 架构:特别的架构可以确保能够回答它是如何做到伸缩的以及是如何失败的问题的?而后者则是我们经常忽略的问题。我们通常是为了“正常工作”而设计-而不是为了“失效”时设计。但是如果我们不能够理解失效是如何发生的话,那么失效就是不可预测的。 \
- 组织结构和所有权:建设一支能够相互配合、完全拥有自主服务的团队,他们不仅会创建出高水平的可扩展性,还会有高水平的创新能力。
InfoQ:伸缩云的广泛使用不是已经由云供应商为我们解决了可扩展的的问题了吗?
\\\\\这是一个常见而又危险的误解。伸缩云通过“按需使用”来扩大我们的解决方案,从而能够降低成本,缩短上市时间。但他们不会为我们的扩展性提供解决方案的架构,也不会让我们的应用更加的高可用。他们能够做到:增加更多的服务器、更多的资源-是可以的;解决方案能够让成功率更高、更加容易的切分独立组件-做不到。
InfoQ:考虑到这些方面,改变一个组织的规模是一个系统性的努力,这些改变从哪儿开始?
\\\\\在顶层--基于管理、共享以及相关利益者的批准。不进行改变这种规模就永远不会成功,除非是团队全部成员都同意作出改变。
InfoQ: 企业目前不仅在寻找一个可扩展的架构,还同时要求大幅缩短上市时间,对于此同时实现这二者你有什么方法上的建议?
\\\\\读我们的书:),必须认真-我们所提供的解决方案很多都是为了帮助公司的扩展和缩短上市的时间。举例来说,服务的开发,我们帮助团队从原来的架构无缝迁移到组件的分离架构,假设该团队在各自的服务中没有冲突的话,就减少了开发的摩擦,理所当然的上市时间就短了。
InfoQ: 在书中您也提及了关于ITIL和DevOps,如果你认为他们的方法对于敏捷来讲是站在对立面的,那么可扩展最适合配合什么方法?
\\\\\是也不是。将ITIL和ITSM引入到可扩展中有其表现强大的一面,比如问题和事件管理分离的概念。如果过度的采用的话(参考上面的流程),它就会带来负面的效果。但是,从概念的角度来讲,他们的想法在这些领域不仅是强大的还是必要的。讲ITIL流程引入到DevOps是绝对可能的。我们认为是他们在其它领域将之设为了对立,其实我们认为DevOps的态度在任何地方都较适用。举例来说,从流程管理的角度看待日常工作(构建一台服务器等等),我们对于ITIL的流程并不待见。
本书从人员、流程、架构设计的角度探讨了可扩展性。
\人员:书的第一部分是对管理进行了简短的介绍。作者在这里特别强调了人力资源的重要性,合适的人在合适的时间做着合适的工作,并能够在扩展中作出正确的行动。作者还在这里给出了具体的建议:
\流程:作者描述了ITIL和CMMI,但是还是有必要在流程和组织之间找到适合的团队,为了避免文化冲突和政治腐败,作者建议团队自行决定自己的流程。
\作为一个实例,作者还引用了容量规划和总体计算:“对于各种各样的组件知道你的总体非常重要,因为你需要得知这个信息来做财务预算、雇佣计划、发布计划、以及可扩展项目的优先级。对于系统内部的每个主要组件都要做计算,诸如每个应用服务池、网络设备、带宽使用、以及数据库服务器等。”作者还建议任何组件规划都不要超过容量规划的50%。取决于组件的类型这个数字可以增长到60%,但他们认为一个计划是75%的话绝对是最大值了。
\架构:这里是作者总结的15条最佳应该采用的架构设计:
\在本书的第一版中就推出了AKF Scale Cube,这是一个分析和解决扩展问题的三维模型,它们是:
\AKF的Scale Cube曾是一文中所采用的例子。
\Martin L. Abbott,增长与扩展咨询公司AKF的联合创始人,他曾是Quigo的首席运营官,Quigo是一家广告技术的创业公司,在Quigo他主要负责产品的策略、产品管理、技术开发以及客户服务。Marty曾经在eBay干了六年,头衔有高级技术副总裁、首席技术官、以及执行团队成员。而他再加入eBay之前,Marty在Gateway和摩托罗拉做过很多国内和国际的工程、管理和行政岗位。他也曾服务过几个私人和上市公司的董事会。Marty拥有美国军事学院的计算机科学学士学位,并在佛罗里达大学获得计算机工程硕士学位,也在哈佛商学院高管教育项目修习过,并获得凯斯西储大学的管理学博士。
\Michael T. Fisher,增长与扩展咨询公司AKF的联合创始人,Michael曾是Quigo的首席技术官,而Quigo是2007年被AOL所收购的一家做广告技术的创业公司。在加入Quigo之前,Michael是eBay的子公司PayPal负责工程和架构的副总裁。在PayPal之前,Michael曾在通用电气(General Electric)待了7年,负责帮助开发公司的技术战略,并在哪里获得了六西格玛黑带大师。Michael在美国陆军服役6年,做过飞行员和队长。他在凯斯西储大学韦瑟管理学院获得了博士学位和工商管理硕士学位,在夏威夷大学获得信息系统硕士学位,也是美国陆军军官学校(西点军校)的计算机科学学士,Michael也是凯斯西储大学韦瑟管理学院的设计和创新部门的副教授。
\查看英文原文:
\\感谢对本文的审校。
\给InfoQ中文站投稿或者参与内容翻译工作,请邮件至。也欢迎大家通过新浪微博(,),微信(微信号:)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群(已满),InfoQ读者交流群(#2))。
转载地址:http://nnbnl.baihongyu.com/