Amazon Away Teams架构剖析解密：AWS的工程师如何开发

小提示：您能找到这篇{Amazon Away Teams架构剖析解密：AWS的工程师如何开发}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的Amazon Away Teams架构剖析解密：AWS的工程师如何开发内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">如今硅谷内外各大企业已经寻找到了自己独特的快速开发及部署功能特性的方式。

< ">而在云服务巨头亚马逊的体系中，拥有一个“Away Teams”的特殊处理机制，它的核心概念为：接受自身某些弱点以获取最优解。

< ">El Reg曾经花了数月的时间与该机制多位相关人员进行探讨，现在将正式与大家进行分享。由于亚马逊员工无权公开讨论企业内部事宜，我们的信息源还会保持匿名的形式。同时亚马逊云服务（Amazon Web Services，下简称为AWS）官方发言人拒绝对我们的调查结果发表评论。

< ">亚马逊从未像公开其领导力原则一样支持公开编纂他们的管理体系，因此要捕捉亚马逊这样规模巨头的方法机制总会是一个挑战。但以下的描述或许可以为那些寻求大规模团队协作开发解决方案的人们提供一些新的思路。

< ">< font-size: 18px;">当前面临的挑战

< ">一旦企业的工程师以及技术员工人数达到数百或数千时，整个组织将会超出传统团队协作的负荷。当开发陷入混乱时，就需要寻求某种可以支持20，50或者100个小团队互相协作的管理方式。

< ">敏捷（Agile and Scrum）以及DevOps等方法可以支持特定项目从概念阶段到交付阶段中的持续演进，但这些方法并不会优化现有各团队间的协作方式。

< ">为平台或者应用程序创建完整且连贯的解决方案是较为基础的需求，即便是组织一个专业团队来进行实施也是如此。所以无论最初对团队协作考虑的多么全面，后期总会需要进行一定程度的调整。

< ">企业中各个团队都是为了某种特定目标而设立的。甚至各团队还负责各自独立的盈利或是亏损，独立的目标或是关键指标（例如受到Intel企业使用经历的启发而采用OKR模式的Google）。但在现今的企业平台中，几乎所有应用于整个企业的服务相互间都有着密切关联。

< ">当有人向你的团队提出挑战，需要在你的团队正在交付的服务中发起一个新的请求，例如新功能，修复错误或是进行优化性能，你会怎么处理？你会给他们权限访问你的源代码吗？如果新功能能获得用户或是客户的欢迎，你会将新功能的后期维护保留在你的团队内部，或是将其交给负责交付的团队？如果你的团队可以添加一项能帮助其他团队增加收入的功能，那么你应该在完成已规划好的功能前添加这项功能吗？

< ">如果有任何人觉得以上问题可以被轻松解决，并且企业内部每人都可以完成对的事，那么他/她一定没有在大型组织中真正工作过。

< ">当然，良好的管理层应协调团队，帮助他们更好地进行协同工作。但寻求管理层的协助总会在某种程度上减慢工作效率。另外必须明确的是：管理层也并不总能做出正确的决定。

< ">< font-size: 18px;">亚马逊团队协作机制

< ">亚马逊自成立初期就面临着以上提到的这些问题。他们创建了一个基于面向服务架构(SOA)的系统（增添了某些特有的创新点以适配亚马逊这样一个互联网公司的管理模式）。

< ">2017年在旧金山举办的全球人工智能大会中，Andrew Ng（斯坦福研究员，企业家以及AI专家）曾发表过一个演讲，其中解释道：真正的互联网公司并不是一个拥有线上网站的购物中心，而是一个能够响应快速迭代，拥有A/B测试以及自上而下设计方法的公司。

< ">亚马逊并没有重新发明一个新的模式，它只是正在研究许多公司面临的相同问题，似乎也确实找到了解决问题的方法。亚马逊创建了一个优化内部团队协作的机制，并强制下达指令要求内部团队构建各自独立服务接口，这些服务必须基于A/B测试以及自上而下的设计方法。这样的机制促成了企业内部团队协作的一个新概念：Away Teams。

< ">事实证明亚马逊体系，尤其是Away Teams，与技术哲学家的研究结果一致。例如Ray Kurzweill对近年来技术指数级发展的分析，以及麻省理工学院教授Eric Von Hippel关于用户驱动创新能力的文章。

< ">< font-size: 18px;">来自Yegge的讨论：亚马逊面向服务架构的转变

< ">根据我们的了解来看，亚马逊的CEO杰夫贝索斯（Jeff Bezos）拥有着非常强势的管理风格。从公司执行层面来探讨的话，这样的管理风格的确是企业变革的必要因素之一。

< ">Bezos使用了他的领袖魅力以及他作为CEO的权利要求亚马逊改造自己，并要求https://Amazon.com必须使用自己生产的云服务。其中的改造可能是目前AWS的负责人Andy Jassy提到的全面移除Oracle技术（Amazon completely off Oracle）。但我最喜欢的改造是在“Yegge Rant”中叙述的亚马逊向面向服务架构的转变。

< ">Steve Yegge曾经是亚马逊的员工，工作了几年后转为替Google工作。2002年左右，Bezos要求亚马逊所有的团队都要以公开服务接口的方式，提供数据和各种功能。Yegge在发布的相关讨论帖（发布在现已弃用的Google+上）中解释说，这个强制的命令引起了亚马逊内部的巨大波澜。亚马逊员工们需要学习以及探索各式技术以及操作问题，例如面向服务架构的错误定位，服务性能控制（任意一个公司内部团队都可能突然发起大量请求，成为一个潜在的DOS攻击者），服务监控，服务发现等等机制。另外，我们可以了解到这篇文章发布后，不久就被Yegge删除并对文章的发表表示了懊悔。

< ">这样的强制命令就按照Bezos的计划顺利进行下去了，并由此围绕着服务架构本身一些有趣的原则创建出了一种全新的技术文化。其中一个可能的（我们还没有获取到多个渠道信息可以支持交差验证）原则是：一旦某个团队成为了某个特定API唯一的用户，他们就会成为该服务的所有者，即使他们并不是这个服务的开发者。

< ">但是，对于一个成熟的面向服务的体系架构而言，单独的某个技术，工具或者操作并不能解决内部协作的问题。这是亚马逊开辟新天地的地方，尤其是Away Teams的概念。我们好像没有听过说亚马逊将其正式定义为该模式的名称，但用它来解释面向服务架构似乎很合适。

< ">< font-size: 18px;">亚马逊面向服务架构的协作机制

< ">以下是我们对亚马逊面向服务架构的协作方式的研究：

< ">团队结构

< ">任何一个负责某项服务的团队都有一系列需要达成的目标和衡量目标达成的收支指标。为了实现这些目标，团队通常会制定服务演进图。

< ">团队应是自主的，可以做出实现目标所需的任何重要决定。

< ">“对客户的价值”是每个团队的使命的一部分。使用模拟发布方式(Mock)保证开发人员牢记最终用户的需求。

< ">团队尽可能地保持小规模，坚持两个披萨原则，大约为六个人的团队。

< ">服务可以被重构，也可以将其拆分为新服务并分配给一个新的团队。没有工作量的团队将被叫停，他们的技术产出将由其他团队接手或被废弃。

< ">新团队通常会来处理紧急的端到端问题。

< ">开发流程

< ">团队使用一组共享的开发工具或共享服务进行源代码管理以及开发流水线管理。其中有许多常用的工具和服务，每个团队都可以自主选择来快速完成工作，不做硬性要求。尽管如此，在某些时候还是需要解释团队选择特殊工具的原因。

< ">DevOps模型完全被采用并接受，每个团队都会为其服务提供运营支持。

< ">访问大多数源代码并不难，通常一团队在没有事先约束的情况下，可以很容易地看到另一团队的源代码。然而还是难免会有一些例外的情况。

< ">A/B测试和详细监控普遍用于站点和基础设施的各个方面。测试由一个基于WebLab服务的团队提供支持，该团队负责培训员工如何使测试结果更易于统计。

< ">团队通常不必担心内部资源使用率。不会有单独的内部统计维度来跟踪资源的使用情况。服务内部使用率会作为预算流程的一部分进行统计，并由财务团队进行监控。他们会定期与团队会面，讨论服务的任何异常增长并鼓励团队对其进行优化。

< ">减少技术债并不是做任何事情的好理由，除非它对实现团队目标产生影响。

< ">协作实践

< ">对某危机公关的途径团队所有服务的修改需求可能会由另一个团队，也就是所谓的Away Team进行实施。该团队会根据已建立的工程标准处理服务所有者的代码，以便根据工程标准添加所需的代码。接下来Away Team会将该代码维持在良好可维护的状态，并由该服务所有者所在团队进行后期维护，并在需要时提供帮助。

< ">如果请求者没有能力基于服务的演进规划来进行服务修改需求的实施，而导致了无法采用Away Team这样的模式。这通常是由于该服务的演进规划不够全面，因此为了容纳新的需求则需要重新调整现有的服务演进规划。

< ">如果使用Away Team模式对服务进行扩展时，由于某种原因无法继续往下进行。那么此时可以进行复制原有服务或创建一个新的服务等能够推进你的进度所需的任何操作。只要能够帮助进度的推进，就不必担心平台内部各服务间的重复。

< ">创建服务的团队在做出对其他服务产生积极影响的事情时会获得信誉以及管理层的认可，这样的影响通常是直接影响损益的。

< ">“Bar Raisers”是一种作为独立专家角色的亚马逊员工。他们日常会在其他团队进行工作，但会对负责的服务站在相对独立的角度上进行关键决策，例如招聘，宣传，设计、客户体验，架构，A/B测试等方面。这可能违背了对于Bar Raisers这个角色的初始定义，但在这样的操作模式下，问题会很容易被注意到并且易于更高级别的管理层进行管理。

< ">这些关键原则被运用在了亚马逊的各个不同阶段：

< ">亚马逊最古老的原创技术通常被称为Legacy平台，之后诞生了有一个名为MAWS的非公开内部服务平台，我们耳熟能详的AWS是它最新的公开形式。但在这个演进过程中也可能还有其他我们未曾听说过的平台。

< ">例如，https://Amazon.com或Kindle等旧产品可能会使用三个平台中的服务。Alexa和Echo等新产品则可能更倾向于在AWS上使用更多公共服务。

< ">从Legacy到MAWS甚至是到AWS的过程中，开发工具已进行了多代演进，所有这些演进都需要数年才能完成。

< ">AWS以外的团队不太会在单个服务或是团队层面有直接的损益产生。所以一般而言，AWS团队对单个服务，团队以及损网上代运营是真的吗益之间的边界拥有着最多的经验。

< ">这是在与组织的不同层面和不同观点的许多人访谈后得出的结论，可以让我们理清自己的思路。但找到了解整个情况和详细历史的人并不是一件容易的事，就像亚马逊的公关人员总是说：我们随时准备与亚马逊首席技术官Werner Vogels坐下来，详细聊一聊。

< ">< font-size: 18px;">Kurzweil和Von Hippel介绍面向服务架构的协作

< ">亚马逊的模式鼓励团队对接团队，服务对接服务这样直接的协作方式，以便在每个团队在需要对某个服务进行优化时，尽可能多地取得进展。

< ">当记者开始了解亚马逊的模型时，我意识到面向服务架构的协作结构使用了两位著名研究人员记录在册的技术优化方案。

< ">麻省理工学院教授Eric Von Hippel对用户驱动创新的研究表明，当用户直接获得创建解决方案的手段时，跟高几率会产生巨大的创新。否则必须将一系列需求相关的“粘性信息”呈现在需求文档中或从用户传递给开发者，这非常困难并很大几率无法完成。但如果用户和开发者是同一个人或处于同一个团队时，就不必执行此步骤，这样的结果反而会更好。亚马逊的Away Teams也秉持着这一概念，并允许团队创建具有高度适应性的服务。

< ">Ray Kurzweil在技术指数级发展的分析中提供了另一个思路，通过它可以解释亚马逊模型的内涵。记者总结了Kurzweil在技术杠杆研究使命中的模型，他论文的观点如下：

< ">起初，任何技术领域的进展看似非常缓慢，这是由于当时处在正在开发基本服务的阶段

< ">但是接下来到了使用简单的服务构建更复杂的服务。长此以往推进了开发的速度

< ">与此同时，资金逐渐大量投入到了那些具有优势的服务

< ">随着服务的使用越多，服务的目标适应性就越变越好

< ">Kurzweil的研究表明，在许多不同的技术领域，这种模式总是贯穿整个技术发展史的。从我的角度上看，亚马逊仍然处于这个模型指数曲线中的早期阶段，这是由亚马逊内外部对服务的使用程度来决定的。

< ">如果没有足够的服务数据来推动资金和优化，亚马逊的模型将无法运作，端到端的实施团队以及Away Team在识别新服务和改善现有服务的适应性方面发挥着至关重要的作用。

< ">目前，AWS专注于创建更高层次的通用型服务，这些服务适合用于各类通用平台的软件开发。例如亚马逊自身（Amazon.com，Alexa，Kindle等）以及正在构建各种产品和IT基础架构的AWS客户。

< ">< font-size: 18px;">亚马逊面向服务协作的特征

< ">亚马逊的协作原则与其他大型组织不同，因此避免了其他大型组织经常出现的一些问题，如：

< ">可能需要消耗几个月请求访问另一个团队的源代码

< ">直接产生收益的服务或服务的关键决策权仅由一个固定的团队负责，而不会将其传递给服务所有者团队。

< ">让管理层注意到重构某些演进需求可能需要耗费数月时间。通常这样的关注也不会促成有效的团队合作

< ">在调整激励措施之前，团队可能会将对向他人提供帮助的优先级降低

< ">团队内部优化的优先级很容易高于整体业务转型

< ">借助亚马逊的面向服务的协作系统，大部分问题永远不会发生，有些问题则会减小发生频率。如果说任何像亚马逊一样规模的组织都没有政治因素的影响，那就太天真了。但这些原则鼓励大家像这个最优方案靠拢，就像鼓励拥抱用户价值一样。

< ">以下是亚马逊体系内的一些优点：

< ">Away Team模型以及访问源代码的便捷性意味着可以轻松跨越服务边界，以增强整个平台中服务的易用性。团队可以轻易地完成通过改进其他服务来完成自己团队服务的优化

< ">解决协作问题和重构服务演进方案所需的时间成本大大减少。在亚马逊的模型中，演进方案有时需要重新考虑，但由于有Away Team的协助，这些事件会被弱化

< ">团队自治过程中还减少了对管理输入上下文的需要。这样的政策是尽一切可能专注于为客户提供价值，而不是担心服务重复或偏离标准。在开发完美的共享服务时不需要等待，在使用完美的共享服务的时候不会有任何阻力。

< ">服务转让定价制度的剔除意味着团队更加致力于提供更好的服务，而不是始终追求效益最大化。资源的使用情况由财务团队跟踪，他们会分配请求并且对资源调配进行优化

< ">专注于数据减少了主观判断。我们不需要进行争论，任何一方都持有着各自的观点。我们最终只需要关注数据，因为数据总是正确的

< ">凸显了跨团队审查的优点。团队的代码将是可见的，所有的决定会受Bar Raisers监督，而Away Team编写的代码必须被其他的团队接受。如果马虎对待代码，那么它将会被公开。

< ">随着时间的推移，公开版本的AWS服务往往会成为首选。顾客们对亚马逊产品的迷恋加速了亚马逊持续的优化自身内部服务，促使公开版本的AWS服务通常比内部服务拥有更高的质量和性能

< ">亚马逊模型的缺点是架构可能包含重复的服务或是同一服务的多个版本。有这样一个座右铭：“有两个好过一个都没有”，意思是做你需要做的事情，另一个平衡的座右铭是“一个都没有好过有五个”，所以每当发现有些服务并不是完全适合的时候，也不要忘掉它而去创造新的服务。

< ">更大的一个担忧是产品凝聚力和一致性可能会受到影响。这位作者还没有花时间在AWS之间挖掘各API模式之间的差异，我也无法对内部API进行这样的操作，但我们被告知这确实是存在的隐患。

< ">当然，我们提出的观点代表了理论，而不是从实践中获取经验教训。正如在亚马逊体系中受挫并且在五个月后离开亚马逊的人在本博客中所述，Away Team模型，Bar Raisers和标准开发环境都可能出错并导致问题。亚马逊是一个高压且竞争非常激烈的环境，这就导致了他们的员工和经理都很难在像Glassdoor这样的网站中公开发表自己的看法。

< ">“商业总是在发展迅速，我们必须加快行动”。这是Bezos一贯的口头禅。面向服务架构的协作模型基于Kurzweil指数理论以及减少Von Hippel提到的粘性信息进行着短期以及长期的优化。最后，亚马逊很乐意使用面向服务架构的协作来确保AWS和内部服务快速增长，但表面看起来确实是激进了一些。

原作者：Dan Woods

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

译者：赵越 ThoughtWorks咨询师，李之琳 ThoughtWorks业务分析师