内容来源：DevOps案例深度研究 –Amazon持续交付之道战队（本文只展示部分PPT及研究成果，更多细节请关注案例分享会，及本公众号。）

本案例内容贡献者：单冰 (Topic Leader)、 赵栋、梁兴龙、李杰、毛艳清、牛恒

本次案例解读：王立杰

（图片来源于网络）

上一篇文章《DevOps案例研究|史上最能“拜客户教”的公司，是如何做到持续交付的？（第1趴）》，通过介绍Amazon实行DevOps的背景，为大家解答了为啥Amazon被称为史上最“拜客户教”的公司，以及它如何在这种理念指导之下，通过DevOps提升研发效能，从而支持业务增长。

注：整个案例研究分成如下几个部分，本文为该系列文章的第二篇，后续内容会在本公众号持续发布，请大家关注“DevOps”公众号！避免错过后面的精彩内容。

了解了实行DevOps的背景，那么，Amazon这家史上最能“拜客户教”的公司，具体是如何做到持续交付的呢？本文将为大家拆解Amazon持续交付的具体实践。

Amazon的DevOps也是端到端的闭环过程，即先有构建（Build）->测试（Test）->发布（Release）的交付流水线，再从客户经历监控（Monitor）->下次计划(Plan)的反馈闭环。

在整个打造闭环的过程中，Amazon一共经历了四个方面的变革。

一、组织变革

1.1 “两个披萨”团队

任何时候、任何大的变革，都需要先从“人”的层面进行。这涉及到组织文化的重构、组织价值观与行为的梳理。Amazon也不例外。Amazon的“两个披萨”团队在业界流传已久，“两个披萨”团队是指在Amazon内部划分团队的规则：购买两个最大号的披萨，如果能够让你的团队吃饱，那就可以保留这么多人；如果不能吃饱，说明你的团队人数太多，需要拆分。这个说法其实也是在提倡敏捷小团队，典型的敏捷团队是5-9人，也差不多两个披萨可以吃饱。

1.2 一流的人才

团队组建成功，要想充分激发起团队的主动性、能动性，必然离不开授权与激励，因此Amazon提倡充分授权，即“完全所有权；完全问责制；一致的激励措施”，一句话概括就是权责利的奖罚分明。当然，开发与运维的协同必不可少，毕竟这是狭义DevOps的基本范畴。这里需要强调一点：Amazon对人才的要求极高。贝索斯认为：雇佣最优秀和最聪明的员工是公司走向成功的保证。Amazon一直坚持招人的高标准，坚决不会为了满足各业务部门的人力资源需求而放低招聘标准。每次招募员工时，无论男性还是女性，都要求一个比一个水平高，只有这样，才能使整个人才储备的标准提高。随着Amazon的不断壮大，贝索斯对员工的要求更高了，并在会上不断重申要求员工要用心工作、努力工作和超时工作。同时，贝索斯不能容忍愚蠢的行为，即使是偶尔为之也无法容忍。2009年2月，Kindle2发售前夜的大会彩排现场，由于出现了一些计算失误，贝索斯怒斥了通讯部门的员工，“我不知道你们是不是没有用高标准要求自己，还是你们只是不知道自己在做什么。”在这样的高标准要求之下，那些不满以及不适合Amazon的员工都被贝索斯坚定地解雇了，取而代之的是拥有新观念和更多经验的人。当然，留下来的老员工都得到了丰厚的回报。

1.3 充分授权

有了一流的人才，还需要对员工充分授权。为了强化沃尔玛创始人山姆-沃尔顿“崇尚行动”的理念，贝索斯创造出了“放手去做”（just do it）这一奖项，Amazon非常支持员工发挥主动精神去取得显著业绩，尤其是在其主要工作职责之外取得的成绩，并认为即使员工因此出现了很大的失误，也应该获得褒奖，因为他们承担了很大的风险，并在此过程中展现了足智多谋的一面。另外，贝索斯认为等级制度对变化不利，他在会议和演讲上表示，要把Amazon的经营重点放在权力下放和独立决策上，并且一以贯之地执行。

二、架构变革

2.1 变革背景

在2001年，Amazon网站仍然是一个大的单体应用，由数百万行C++代码组成。几千个开发者同时开发一个大的版本，开发完成，再由一个工程师团队手工进行应用上线。如下图所示：

很明显，这种单体架构的开发效率之低和协作成本之高可想而知。

• 所有人修改的代码都是一个应用代码，代码冲突不断。 
• 构建时间长，任何小修改都必须重新构建整个项目，这个过程往往很长。 
• 稳定性问题：一个小问题，都可能导致整个应用挂掉。 
• 代码高度耦合，新人的学习成本太高，不容易融入团队。 
• 不易扩展：无法满足高并发的业务需求，在必须规模化时，很快达到其极限。

这样的单体架构已经严重影响到业务的增长。为了彻底解决这一问题，贝索斯2002年发了一封信，要求必须改变，如果谁不改，就开除谁。这个背景我们在上篇文章有提到，点击复习?【DevOps案例研究|史上最能“拜客户教”的公司，是如何做到持续交付的？（第1趴）】。这个突破口就是“架构变革”，整个网站需要从单体应用转变为面向服务的架构，也就是SOA。每个服务只需要单一用途，让每个开发团队都可处理一个独立的可交付的代码单元；要简单，不要复杂；各个业务的组成都是通过API实现连接和数据交换，从而实现去耦合。

2.2 变革成效

在完成这样的架构变革后，收效显著：

1) 发布效率提升

在Amazon初始架构中，任何一个bug修复，都需要更改应用程序中某些C++ ，单个修复完，还要等待其他人完成对应用程序其他模块的更改，并对整个应用程序进行测试之后才能发布。切换到微服务体系架构后，开发团队可以只对其负责的微服务进行更改，可以独立发布，只要保证质量即可。

2) 错误隔离

在微服务体系架构中，每个团队都在独立的代码基础上工作，不仅团队间的代码冲突减少，而且错误被隔离到单个微服务中。

3) 技术多样性

以前，所有的代码都是C++代码，整体开发团队被限制在一个通用的技术堆栈和过程中。采用微服务后，允许独立的团队为给定的服务选择正确的流程和技术，采用Java或者Python等框架都可以。这样，就可以吸引更多有才华的工程师，让他们采用各种新技术。

4) 新人融入快

新工程师可以安全地在一个小型的微服务上进行编码。对于一个工程师来说，没有必要仅仅为了修复一个bug而去学习一大堆代码库，学习曲线降低。

5) 团队拥有更大的自主权

采用微服务的最大变化可能是文化。为了提高敏捷性和效率，微服务开发团队做出以前无法控制的决策，比如发布日期、质量策略。这一点跟前面的组织变革，正好相辅相成。

三、工具变革

3.1 APOLLO

一个云应用程序可能拥有数百个单独的微服务，每个微服务可能由多个实例组成(为了可用性和可伸缩性)，这就带来微服务规模的增长；而每个微服务将由各自的开发团队独立更新。快速增长的微服务数量和更新的频率要求一个完全自动化的部署工作流程和基础设施。Amazon内部的APOLLO工具，在这种场景下应运而生。APOLLO主要对环境进行管理，比如某一个服务上线需要用到哪些package group、依赖有哪些、参数要设置哪些、机器要多少台等。按最小的服务单元每次也会涉及到在几十台主机上做部署。

APOLLO可以自动化整个部署工作流程，这也是目前大多数类似工具的通用功能。

• 从代码到客户的全自动化。通常，一旦开发人员将代码提交源代码库，就会有一个按钮流程，自动获取最新的源代码，并将其打包到部署工件中，如容器，然后将整个工件部署到准生产或生产环境中。这被称为持续交付。
• 弹性缩放。微服务本质上是相当短暂的部署新版本、退出旧版本，并根据利用率添加或删除新实例。Amazon采用的是Elastic Compute Cloud，支持弹性扩展地部署基础设施。

3.2 Build tools

Amazon崇尚每个人有更小更明确的任务，“you build it, you run it.” 落到工具层面，这主要得益于一个叫Build tools的组，他们把Platform和Internal tools做到了功能性和易用性在业界内数一数二。

这个组做的主要工具有5类： 

1）Brazil Build

对package进行分发和建立，每次build至少涉及上百个package，可以在几分钟甚至几十秒内完成build并保证不出错。

2）Apollo Deployment

对环境进行管理，比如某一个service上线需要用到哪些package group、依赖有哪些、参数要设置哪些、机器要多少台等。按最小的service单元每次也会涉及到在几十台host上做deployment。

3）Code base

所有代码存放在中央代码库，可以按reference、method、keyword之类搜索所有相关代码。

4）Monitoring System

对service进行监控、告警、故障分析等。

5）Pipeline

把build、test、deploy全部串起来，对整个流程进行监控。大部分操作如rebuild、代码回滚、停止deploy一键操作就可以完成。

Amazon的所有工具是全公司统一使用的，更新及时且统一，有一个非常大的组专门负责开发维护，在Amazon，随便一个开发通过Apollo只需一键就可以实现回滚。而大多数公司由于组织架构的原因，各个组之间的代码不是互相可见的，做这些工具也各自为战，你做一套我做一套，精力分散，加上code/API等不透明导致online infra做得非常渣，以至于想回滚一次得叫上PM、QA、Dev等人一起弄个大动作，这也导致很多公司想做每日部署几乎不可能，更别说分钟级部署了。 

四、流程变革

人都是不可靠的，都会犯错误，但机器不会，只会忠实地执行。提高效率，避免错误的关键，就是要把一切能流程化的东西自动化。关于这部分，就不多做赘述了。

总结

正是上述四大变革提升了Amazon公司的整体DevOps能力：Amazon可以让一个Dev从功能的设计、开发、测试、发布、后续的监控由一个人完成。平均每十几秒就有一次发布，每天发布好几千次，让Amazon最终实现一年5000万次的部署。
如果你对搭建流水线感兴趣，想体验一下如何用工具实现真正的交付流水线，体验从修改代码再到一键上线的快感，体验如何从0到1打造一款产品，建议你来我们的DevOps黑客马拉松！！（识别文末图片中的二维码即可报名~）号外！号外！！如果你想跟“无敌哥-王立杰”老师微信交流，请在公众号后台回复“无敌哥”，您将会得到“无敌哥-王立杰”老师的微信二维码，添加时注明理由。

拓展阅读：DevOps案例研究：知人善任——Google敏捷核心文化

DevOps案例研究：进取到让自己毛骨悚然，Netflix公司的简介和文化

DevOps案例研究|史上最能“拜客户教”的公司，是如何做到持续交付的？（第1趴）

DevOps案例研究：庖丁解牛，剖析Google持续交付之道

历久弥新 - 微软万亿市值背后的文化支撑（上）|DevOps案例研究

历久弥新 - 微软万亿市值背后的文化支撑（下）|DevOps案例研究

DevOps黑客马拉松 

9月7-8日 北京

专业大咖陪你一起进化

欢迎企业组队PK，企业团队报名有特惠

目前已经有两家企业组队！！

赶紧报名吧~⬇️⬇️⬇️