AWS内部开发和维护技术

云头条导读：IT外媒The Register独家披露了这个云巨头的内部结构和员工实践，经云头条编译分享，供大家参考。

硅谷内外的众多公司已找到了各自的方法来迅速开发和部署功能特性。

不过，互联网巨头亚马逊庞大的云计算部门AWS内部有个特别的消化系统：一个名为Away Teams的概念，这个概念是指为了达到最快速度，接受某些缺点。

IT外媒The Register花了几个月的时间与零距离接触这个概念的十几个人进行了交谈，现在与读者们分享。这些知情人士仍保持匿名，因为他们无权公开谈论亚马逊。这个美国巨头的官方发言人拒绝对调查结果发表评论。

详细介绍像亚马逊这么庞大的组织的运作方式始终是一个挑战。这家公司从未像对其领导原则所做的那样公开整理过管理体系。但本文有望为力求在大规模环境下协调技术开发的人提供新的思路。

手头的问题

一旦贵公司的工程师和技术人员成百上千，适用于团队层面的一切满足不了新的需要。生产环境处于一片混乱时，必须找到某种方法，那样那20个、50个或100个团队才能互相帮助。

敏捷、Scrum和开发运维（DevOps）等方法可以使某个特定项目保持顺利开展，并从概念环节进入到交付环节，但它们无法使众多团队的工作保持协调性。

当然，为某个平台或应用软件开发一套连贯的设计是个基本问题，组织管理项目以实施这种设计也是个基本问题。但无论你最初做得有多好，后来都需要调整。

那些团队中的每一个都是为了实现某些目标而设立的。也许它们有各自的盈亏（P&L），或目标和关键结果（OKR，谷歌就采用了著名的OKR，受英特尔使用OKR的启发）。但在现代平台中，构成整体的几乎所有服务都将相互使用。

有人出现在你的办公间，索要你提供的服务中的一项新功能，或者要求修复错误或优化性能，你会怎么做？你让他们可以访问你的源代码吗？如果新功能受到用户或客户的欢迎，你是将其仅保留给你的团队还是将其交给可能更适合拥有它的团队？如果你的团队能添加一项可以帮助其他团队赚更多钱的功能，你应该先搞这项功能，再搞路线图上的功能吗？

谁认为这类问题很容易解决，认为每个人都会做正确的事情，那他从未在真实的大企业中工作过。

当然，好的管理层应该适时干预，帮助团队协同工作。但寻求管理层的关注会减慢进程。而令人惊讶的是，管理层并不总是做出正确的决定。

亚马逊的内部协作体系

亚马逊自成立以来就面临这些问题，为此创建了一套基于面向服务架构（SOA）原则的体系（包括一些重要的补充，以便整理出使互联网公司大获成功的管理创新）。

斯坦福大学研究员、企业家兼AI专家吴恩达在2017年旧金山AI大会的一次演讲中解释，一家真正的互联网公司不是设有网站的购物中心，而是一家奉行短周期时间、A/B测试并将决策机制下放的公司。

亚马逊在这方面没有重新发明轮子，而是研究分析许多公司面临的问题，但它似乎确实找到了解决这个问题的一种有趣方法。它有一套优化内部协作的体系：围绕一批独立管理的服务来组织开发工作，采用一套令人着迷的政策来管理一切，基于A/B测试、下放的决策机制以及精心打造的协作文化，这种文化充分利用一个新的概念：Away Teams。

正如结果证明，亚马逊的体系、尤其是Away Teams与技术大咖们的发现结果相一致，比如Ray Kurzweill解释了技术呈指数发展的规律，麻省理工学院（MIT）的Eric Von Hippel教授对用户驱动创新的魅力发表了独到见解。

从Yegge名言到面向服务协作

根据The Register对其行为的了解，亚马逊CEO Jeff Bezos向来喜欢强制行使职责，从CEO的角度来看，这是公司高层要求下属完成某些类型的变革。

Bezos利用其个人魅力、成功的光环以及身为CEO的权力，迫使整个公司自我改造。迫使Amazon.com吃自己的狗食并使用AWS就是这样一个举措。竭力让亚马逊完全迁离Oracle数据库是另一个举措，不过这个举措的发起人很可能是AWS的掌门人Andy Jassy。不过我青睐的是向面向服务架构转变的举措，这就是后来所谓的Yegge名言（Yegge Rant）。

正如在亚马逊供职几年后跳槽过来的谷歌工程师Steve Yegge所说，2002年前后，Bezos要求亚马逊的每个人都将本部门的产品作为通过API予以公开的服务来提供。Yegge的帖子解释，这种强制行使职责的做法引起了巨大的痛苦，因为整个公司在学习应对各种技术和运营问题，比如调试面向服务架构，每个内部用户都有可能是浑然不觉的拒绝服务（DOS）攻击者、导致流量飙升时保持足够的性能，处理运营支持，发现什么服务可用以及其他许多问题。我们应特别指出，Yegge很快后悔发这个帖子（https://launch.co/blog/googler-steve-yegge-apologizes-for-platform-rant-shares-bezo.html）。

然而，强制行使职责按计划运作起来，并围绕拥有一些有趣原则的服务打造了一种技术文化。我们无法从多名知情人士处证实的一个原则是这个政策：一旦某团队是API的唯一剩余用户，它就成为该服务的所有者，即使最初开发API的不是该团队。

但是，光有成熟的面向服务架构所需的技术、工具和运营解决不了内部协作这个问题。这时候亚马逊首开先河，提出了Away Team概念。The Register没听说亚马逊为这套体系取了名称，不过面向服务协作似乎很贴切。

亚马逊面向服务协作的几个原则

据The Register所知，以下是亚马逊面向服务协作的工作原理。

1. 团队结构

• 拥有服务的每个团队都有一系列目标，可能还有代表成功的P&L。通常制定了路线图以实现这些目标。

• 团队表面上是自治的，可以做出实现目标所需的任何重要决定。

• “给客户带去价值”是每个团队遵从的使命的一部分。这使用模拟新闻稿等内容来加以整理，确保开发人员牢记最终用户的需求。

• 团队尽可能保持小规模，坚持两个披萨规则（two-pizza rule），这意味着团队成员就六个人左右。

• 服务可能重构，也可能将新服务扔给新团队。不成功的团队将关闭，它们开发的技术将分发给其他团队或被丢弃。

• 常常成立新团队以解决紧迫的端到端问题。

2. 开发流程

• 团队使用一组共享的开发工具来用于源代码和管理开发流水线，其中一些作为共享服务来提供。有许多经常或普遍使用的工具和服务，但没有硬性要求。每个团队都可以做合理的事以快速完成工作。虽然确实如此，但到某个时候你要用数据来表明为何偏离了标准。

• DevOps模式完全得到积极接受。每个团队都为其服务提供运营支持。

• 访问大多数源代码并不难。一个团队通常很容易查看另一个团队的源代码，没有事先的约束。有一些例外。

• A/B测试和详细监控很普遍，用于网站和基础设施的几乎方方面面。测试基于WebLab服务，由一个培训员工如何使测试具有显著统计学意义的团队提供支持。

• 团队通常没必要为内部使用资源的费率而担心。没有用于追踪这种使用的转手的内部货币。内部跨服务使用资源的费率作为预算编制过程的一部分而予以分配，由财务团队监控，财务团队与各团队定期会面，讨论服务方面的任何异常增长，并鼓励优化。

• 减少技术债务并不是做任何事情的充分理由，除非它对实现团队的目标有影响。

3. 协作实践

• 对一个团队的服务进行更改可能由另一个需要改进版功能的团队（即所谓的Away Team）来完成。该团队研究Home Team的代码，根据已确立的工程标准来添加所需的代码，然后让该代码处于良好的状态，由拥有该服务的Home Team维护，需要时提供帮助。

• 如果Away团队因请求者没有能力对服务进行改进而行不通，这确实导致管理层讨论如何优化全局路线图。通常路线图排得满满当当，因此容纳新的请求意味着重新调整现有的路线图。

• 如果使用Away Team扩展服务因某种原因而行不通，那么复制和构建加快进度所需的任何内容完全没问题。只要你的需要有助于前进，就不必担心跨平台的复制。

• 构建服务的团队所做的工作对其他服务产生积极的下游影响时会得到表彰。管理层表彰对全局的贡献，通常在总部的P&L上予以体现。

• “水准提升者”（Bar raiser）是充当独立专家的亚马逊员工，负责批准关键决策，常常在其他团队工作，不仅被用来招聘人员（他们通晓这方面），还被用来对设计、客户体验、架构和A/B测试做出影响重大的决策。有可能不按水准提升者的建议行事，但这种举动会记录下来，并让更高级别的管理层看到。

这些原则的运作方式略有不同，具体取决于使用它们的亚马逊部门。

一套演变成服务的最古老的原创技术通常名为遗留技术。有一个名为MAWS的内部平台，它是非公开服务的内部平台。公开形式的AWS是最新的服务。可能还有我们没听说过的其他服务。

比如说，Amazon.com或Kindle等旧产品可能会使用来自所有这三个层的服务。Alexa和Echo等新产品往往使用AWS上的更多公开服务。

从遗留技术到MAWS再到AWS经历多代的演变，开发工具方面也是如此。所有这些变化都在需要数年才能完成的浪潮中出现。

AWS本身之外的团队不太可能有服务或团队层面的P&L。一般而言，AWS团队拥有最强的方法纯粹性，这是指服务、团队和P&L都拥有同一边界的状态。

请记住，本文是与亚马逊处于不同层面、有着不同视角的许多人交谈后撰写而成的。让文章更有洞察力是好事，但找到了解全局和详细历史的人并非易事。亚马逊公关人员请注意：The Register表示随时准备与亚马逊首席技术官Werner Wolf坐下来探讨详情。

Kurzweil和Von Hippel如何解释面向服务协作的魅力？

亚马逊的模式鼓励团队到团队、服务到服务的直接协作，为协作提供原则，以便在每个团队优化直接需要的服务的基础上，取得尽可能大的进展。

两位著名的研究人员已研究了如何可以优化技术开发。

麻省理工学院的Eric Von Hippel教授对用户驱动创新的研究表明，用户可直接获得构建解决方案的手段时，至少可能会带来巨大的创新。原本必须呈现在需求文档中或从使用者传递到构建者的“黏性信息”（https://evhippel.mit.edu/papers/section-2/）很难获得，根本不可能全面。如果这一步因使用者和构建者是同一个人或同一个团队而不必执行，结果好得多。亚马逊的Away Team模式奉行这个概念，让团队得以构建完全适合用途的基本模块。

Ray Kurzweil对技术发展的指数级步伐的分析提供了另一个视角，可以透过该视角解释亚马逊模式的魅力。此处（https://earlyadopter.com/2018/03/09/technology-leverage/）总结了Kurzweil的模型，不过其论点如下：

• 起初，由于基础服务在开发之中，任何技术领域的进展似乎都很缓慢。

• 不过随后，较复杂的服务用较简单的服务构建而成，依此类推，加快了开发步伐。

• 与此同时，资金用于改善最具影响力的服务。

• 随着服务使用得更多，越适合用途。

Kurzweil的研究表明，在许多不同的技术领域，这种模式从古到今都适用。在亚马逊，我的观点是我们仍处于这种指数级曲线的早期阶段，这是由亚马逊内外的服务使用情况驱动的。

如果没有使用方面的数据推动资金和优化，亚马逊的模式将无法运作。端到端团队和Away Team在识别新服务和改善现有服务的适应性方面起到了至关重要的作用。

目前，AWS专注于构建通用的高级服务，这些服务都适合一个通用的软件开发平台。亚马逊本身（Amazon.com、Alexa和Kindle等）以及正在构建各种产品和IT基础设施的AWS客户正在该平台上构建最高级别的服务。

亚马逊的面向服务协作的几个特性

亚马逊的协作原则具有差异化，避免了时常出现在其他大企业的一些问题：

• 可能需要请求几个月，以访问另一个团队的源代码。

• 某个团队会保留为客户创造收入或便于控制关键决策的功能，而不是传递给天生适合该功能的团队。

• 引起管理层的关注以便做出重新调整路线图的决策可能需要数月。这种关注常常并不会导致真正的协作。

• 除非激励机制得到调整，否则团队可能推迟为另一个团队提供帮助。

• 局部优化团队路线图优先于有可能转变业务的工作并不罕见。

有了亚马逊的面向服务协作体系，许多这些问题永远不会发生，一些问题发生的几率会低得多。如果说任何像亚马逊这么庞大的企业没有人事纷争，那未免太天真了，但这些原则往往鼓励步调一致，打心眼里注重客户也是如此。

以下是亚马逊遵循上述原则的体系具有的几个优点：

• Away Team模式和通常易于访问的源代码意味着投入可以轻松跨越服务边界，以增强整个服务系统的功能。如果团队有这样的愿景：通过改进其他服务，使自己的服务拥有更强大的功能，将拥有出色的执行力。

• 大大减少了管理层解决协作问题和重新调整路线图所需要的时间。在亚马逊的模式中，时而需要重新调整路线图，但由于成功的服务资助Away Team，尽量减小了这种情况。

• 团队自主还减少了管理层给予意见的需求。亚马逊的政策是，只要能为客户提供价值，放手去干，不必担心重复或偏离标准。不用等待开发完美的共享服务。也没有非得使用完美的共享服务一说。

• 没有转让定价（transfer pricing）意味着团队通常专注于提供更好的服务，而不是追踪支出。资源使用情况由财务团队跟踪，他们会查找峰值使用，要求给予解释或加以优化。

• 注重数据削弱了意识形态上的激情。我可能是对的，或者你可能是对的，但我们不需要争个你死我活。我们最终会见分晓，因为数据始终是对的。

• 跨团队严密审查的好处与生俱来。你的代码将是可见的。你的决定可能受制于水准提升者。Away Team编写的代码须得到另一个团队的接受。如果你马虎行事，代码会显露无遗。

• 随着时间的推移，服务的AWS公开版本往往受到青睐，因为它们常常拥有比内部服务更高的质量和性能，而更多的使用加快了改进过程。

亚马逊模式的缺点是，架构可能含有重复或同一个服务的许多版本。一个常见的座右铭是“两个比一个都没有要好”，意思是做你需要做的事。另一个起到制约的座右铭是“超过五个就不好”，所以切忌每当某个服务并不适合时，就创建一个新的服务。

更让人担心的是，产品连贯性和一致性可能受到影响。

当然，我们提出的观点只代表理论，并不代表实际上可能出现的缺陷。正如对亚马逊的系统感到沮丧、五个月后弃用的这个人在博客中写道（https://medium.com/@andrewgoldis/why-i-quit-amazon-just-5-months-after-ive-started-4ce872520f02），Away Team模式、水平提升者和标准开发环境都可能出岔子，导致问题。亚马逊是一种压力大、竞争激烈的环境，正如Glassdoor等网站上的帖子可以证明，这种环境对员工和管理人来说很难适应。

Bezos常常将“业务在发展前进。我们必须更快地前进”这句话挂在嘴边。面向服务协作模式针对短期和长期的速度进行了优化，使用Kurzweil的指数杠杆，并避免了Von Hippel的黏性信息。最后，亚马逊很乐意使用面向服务协作，以确保AWS和内部服务快速增长，不管样子有多难看。

之前一篇AWS开发者工具总经理Ken Exner的专访也不错，推荐给大家《 AWS 是如何做软件开发的 ？这里给你答案》。

云社群欢迎加入，群主微信：guanhongyan1023（备注任职单位+职位，否则不予通过）

相关阅读：

AWS是如何诞生的

AWS vs K8s 是新的 Windows vs Linux

AWS 产品 2016、2017、2018 TOP 30：用户采用率指数