AmazonAwayTeams架构分析/解密:AWS的项目师能够研发和维护他

目前硅谷内外各大公司现在寻找到了自己独有的迅速研发及制定功能特征的方法

而在云服务厂商亚马逊的机制中,拥有一个“AwayTeams”的特定处理模式,它的核心概念为:接受本身很多缺点以获得最优解。

ElReg曾经了数月的时间与该模式多位相关人员进行分析,现在将陆续与你们进行分享。由于亚马逊员工无权公开谈论企业外部事宜,我们的信息源将会维持匿名的方式。同时亚马逊云服务(AmazonWebServices,下简称为AWS)官网发言人反对对我们的调查结果发表评论。

亚马逊从未像公开其领导力措施一样支持公开编纂他们的管控机制,因此要捕捉亚马逊这样规模巨头的方式手段常常是一个挑战。但下列的表述或许可以为这些寻找大体量团队协同研发解决计划的他们提供一些新的模式。

目前面对的挑战

如果企业的项目师包括科技人员数量超过数百或数千时,整个组织还会超过传统团体协同的负荷。当开发面临崩溃时,就必须寻找这种可以鼓励20,50或者100个小团体相互协同的管理模式。

敏捷(AgileandScrum)或者DevOps等方式可以鼓励特定项目从概念阶段到投产阶段中的大幅发展,但这种方式并不会提升现有各团体间的协同方式。

系统以及运用程序建立清晰且连贯的缓解计划是较为基础的意愿,即便是组织一个专业团体来进行推进只是更加。所以无论最初对团体协作考虑的如此全面,后期才会想要进行肯定程度的调整。

企业中各个团体都是因为这种特殊目标而建立的。甚至各团体还负责各自独立的赢利或是损失,独立的目标或是关键指标(比如遭受Intel公司选用经历的启发而采取OKR模式的Google)。但在现在的公司系统中,几乎全部应采用整个公司的服务相互间都有着紧密关联。

当有人向你的队伍要求挑战,需要在你的队伍还在交付的服务中发起一个新的请求,例如新功能,修复错误或是进行改进配置,你会如何处理?你会给对方权限访问你的源代码吗?假如新功能能得到用户或是顾客的欢迎,你会将新功能的初期维护保留在你的员工内部,或是将其卖给负责交付的员工?假如你的队伍可以添加一项能帮助其它团队降低利润的功能,那么你必须在完成已规划好的功能前添加这项功能吗?

但是有其他人认为左右问题可以被简单解决企业aws架构设计方案,并且公司外部每人都可以完成对的事,那么他/她必须没有在大型组织中所谓工作过。

此外,良好的管控层应协商团体,帮助人们更好地进行协调工作。但寻找管理层的协助都会在某些程度上减少工作能力。另外需要确定的是:管理层也并不总能作出合理的决定。

亚马逊团队协同机制

亚马逊自创立早期就陷入着左右看到的这种现象。他们建立了一个采用面向服务架构(SOA)的平台(带来了很多特有的整合点以适配亚马逊这样一个互联网企业的管控机制)。

AmazonAwayTeams架构分析/解密:AWS的项目师能够研发和维护他插图-阿鹏资源网

2017年在旧金山举行的国内人工智能会议中,AndrewNg(斯坦福研究员,企业家包括AI专家)曾发表过一个对话,其中解释道:真正的互联网企业并不是一个拥有线上网站的购物中心,而是一个无法响应迅速迭代,拥有A/B测试包括自上而下设计方式的公司。

亚马逊并没有再次发明一个新的方式,它也是正在研究许多企业陷入的相似现象,似乎也显然找到了应对困境的方式。亚马逊创建了一个改进内部员工协作的制度,并强行下达指令规定内部员工建立各自独立服务接口,这些服务需要采用A/B测试包括自上而下的设计方式。这样的模式推动了公司外部团体协同的一个新概念:AwayTeams。

事实说明亚马逊体系,尤其是AwayTeams,与科技哲学家的探究结果一致。例如RayKurzweill对现今来科技指数级建设的预测,以及麻省大学院校校长EricVonHippel关于客户驱动整合实力的文章

来自Yegge的提问:亚马逊面向服务架构的转化

根据我们的知道来看,亚马逊的CEO杰夫贝索斯(JeffBezos)打造着十分强势的管控风格。从企业执行层面来分析的话,这样的管理风格的确是公司转型的必要要素之一。

Bezos使用了他的领袖魅力及其他成为CEO的权力提出亚马逊改造自己,并提出Amazon.com必须使用自己制造的云服务。其中的建设其实是现今AWS的负责人AndyJassy提到的逐步移除Oracle技术(AmazoncompletelyoffOracle)。但我最偏爱的改造是在“YeggeRant”中描述的亚马逊向面向服务架构的转化。

SteveYegge曾经是亚马逊的职员,工作了几年后转为替Google工作。2002年以上,Bezos要求亚马逊所有的队伍都要以公开服务接口的形式,提供数据和各类功能。Yegge在推出的相关探讨帖(公布在现已取代的Google+上)中理解说,这个强制的命令导致了亚马逊内部的很大风波。亚马逊员工们必须学习并且思考各种科技包括操作原因,例如面向服务架构的错误定位,服务品质控制(任意一个企业外部团体都必然时常发起长期请求,成为一个巨大的DOS攻击者),服务监控,服务发现等等措施。另外,我们可以知道到这篇文章公布后,不久就被Yegge删除并对文章的发表声称了懊悔。

这种的强行命令就根据Bezos的方案成功进行起来了,并因此推动着服务架构其实一些有趣的方法建立出了一种全新的科技文化。其中一个似乎的(我们还没有获得到多个平台信息可以鼓励交差验证)方式是:一旦某个团队打造了某个特殊API唯一的用户,他们经常作为该服务的全部者,即使它们并不是这个服务的开发者。

然而,对于一个成熟的面向服务的机制架构而言,单独的某个技术,工具以及操作并不能缓解内部协作的难题。这是亚马逊开辟新天地的地方,尤其是AwayTeams的概念。我们就像没有听过说亚马逊将其即将定义为该方法的名称,但用它来理解面向服务架构仍然很适合。

亚马逊面向服务架构的协同机制

以下是我们对亚马逊面向服务架构的协同方式的研究:

团队结构

开发流程

协作实践

AmazonAwayTeams架构分析/解密:AWS的项目师能够研发和维护他插图-阿鹏资源网

这种关键要素被采用在了亚马逊的各个不同阶段:

亚马逊最独特的原创科技往往被称为Legacy平台企业aws架构设计方案,之后成立了有一个名为MAWS的非公开内部服务系统,我们耳熟能详的AWS是它最新的公开方式。但在这个发展过程中也必然也有其它我们从未听说过的平台。

此外,Amazon.com或Kindle等旧品牌也许会使用三个系统中的服务。Alexa和Echo等新品牌则似乎更偏向于在AWS上使用更多公共服务。

从Legacy到MAWS甚至是到AWS的过程中,开发工具已进行了多代发展,所有那些演进都必须数年才会完成。

AWS以外的团队不太会在单个服务或是员工层面有直接的损益产生。所以通常而言,AWS团队对单个服务,团队包括损益之间的界限拥有着最多的经验。

这是在与组织的不同层面和不同看法的许多人对话后得出的推论,可以让我们理清自己的想法。但找到了解整个状况和具体历史的人并不是一件容易的事,就像亚马逊的公关人员总是说:我们随时准备与亚马逊首席科技官WernerVogels坐起来,详细聊一聊。

Kurzweil和VonHippel介绍面向服务架构的协同

亚马逊的方式支持员工对接团队,服务对接服务这样直接的协同方式,以便在每位员工在必须对某个服务进行改进时,尽可能多地取得进展。

当记者起初了解亚马逊的模型时,我能力到面向服务架构的协同结构使用了两位著名研究人员记录在册的科技提升计划。

麻省大学院校校长EricVonHippel对客户驱动整合的探究表明,当客户直接取得建立解决计划的方式时,跟高概率会出现很大的创新。否则就要将一系列需求相关的“粘性信息”呈现在供给文档中或从客户传递给开发者,这相当困难并巨大概率只能完成。但即使客户和开发者是同一个人或进入同一个团队时,就不必执行此方法,这样的结果仍然会更好。亚马逊的AwayTeams也体现着这一概念,并允许团队建立带有高度适应性的服务。

AmazonAwayTeams架构分析/解密:AWS的项目师能够研发和维护他插图-阿鹏资源网

RayKurzweil在科技指数级建设的预测中提供了另一个问题,通过它可以理解亚马逊模型的内涵。记者反思了Kurzweil在科技杠杆研究使命中的建模,他论文的看法如下:

Kurzweil的研究证实,在许多不同的科技行业,这种方式总是贯穿整个技术演进史的。从我的视角上看,亚马逊甚至进入这个建模指数曲线中的初期阶段,这是由亚马逊内外部对服务的使用频度来决定的。

但是没有足够的服务数据来实现资金和改进,亚马逊的建模将能够运作,端到端的推进团队包括AwayTeam在识别新服务和提高现有服务的适应性方面发挥着至关重要的意义。

AmazonAwayTeams架构分析/解密:AWS的项目师能够研发和维护他插图-阿鹏资源网

AmazonAwayTeams架构分析/解密:AWS的项目师能够研发和维护他插图-阿鹏资源网

现在,AWS专注于建立更高层级的通用型服务,这些服务适合用来某些通用系统的硬件研发。例如亚马逊自身(Amazon.com,Alexa,Kindle等)或者正在形成这些品牌和IT基础架构的AWS客户。

亚马逊面向服务协同的特性

亚马逊的协同原则与其它大型组织不同,因此导致了其它大型组织一直发生的一些原因,如:

打造亚马逊的面向服务的协同软件,大个别现象仍然不会出现,有些原因则会增加产生强度。如果说其他像亚马逊一样规模的组织都没有历史原因的妨碍,那就太天真了。但这种方法支持你们像这个最优计划效仿,就像支持拥抱用户价值一样。

以下是亚马逊体系内的一些特点:

亚马逊模型的特点是构架可能包括重复的服务或是同一服务的多个版本。有这种一个座右铭:“有两个好过一个都没有”,意思是做你必须做的想法,另一个平衡的座右铭是“一个都没有好过有五个”,所以经常看到有些服务并不是完全合适的之后,也不要忘记它而去塑造新的服务。

更大的一个质疑是品牌凝聚力和一致性似乎会得到影响。这位作者还没有花时间在AWS之间挖掘各API方式之间的差别,我也能够对内部API进行这种的操作,但我们被告知这显然是存在的缺陷。

此外,我们要求的看法代表了理论,而不是从实践中获得经验教训。正如在亚马逊体系中崩溃以及在五个月后回到亚马逊的人在本博客中所述,AwayTeam模型,BarRaisers和标准开发环境都必然错误并造成原因。亚马逊是一个高压且竞争十分强劲的环境,这就出现了人们的人员和经理都很难在像Glassdoor这样的官网中公开发表自己的看法。

“商业总是在建设快速,我们需要加强行动”。这是Bezos一贯的口头禅。面向服务架构的协同模型采用Kurzweil指数理论及其减少VonHippel提到的弹性信息进行着短期或者大量的改进。最后,亚马逊很愿意使用面向服务架构的协同来实现AWS和外部服务迅速下降,但表面看上去显然是极端了一些。

(DanWoods不仅是一名技术观察师,还是作家和IT顾问,在Twitter和LinkedIn能找到他。)

原作者:DanWoods,2019年5月14日07:03

原文链接:theregister.co.uk/2019/05/14/amazons_away_teams/

译者:赵越ThoughtWorks咨询师,李之琳ThoughtWorks业务分析师

------本页内容已结束,喜欢请分享------
© 版权声明
THE END
喜欢就支持一下吧
点赞6赞助作者 分享
评论 抢沙发

请登录后发表评论

    请登录后查看评论内容