内容来源：DevOps案例深度研究 –Amazon持续交付之道战队（本文只展示部分PPT及研究成果，更多细节请关注案例分享会，及本公众号。）
本案例内容贡献者：单冰 (Topic Leader)、 赵栋、梁兴龙、李杰、毛艳清、牛恒
本次案例解读：王立杰
（图片来源于网络）
上一篇文章 《DevOps案例研究|史上最能“拜客户教”的公司，是如何做到持续交付的？ （第1趴）》 ，通过介绍Amazon实行DevOps的背景，为大家解答了为啥Amazon被称为史上最“拜客户教”的公司，以及它如何在这种理念指导之下，通过DevOps提升研发效能，从而支持业务增长。
一、组织变革
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++代码组成。几千个开发者同时开发一个大的版本，开发完成，再由一个工程师团队手工进行应用上线。如下图所示：
- 所有人修改的代码都是一个应用代码，代码冲突不断。
- 构建时间长，任何小修改都必须重新构建整个项目，这个过程往往很长。
- 稳定性问题：一个小问题，都可能导致整个应用挂掉。
- 代码高度耦合，新人的学习成本太高，不容易融入团队。
- 不易扩展：无法满足高并发的业务需求，在必须规模化时，很快达到其极限。
2.2 变革成效
1) 发布效率提升
在Amazon初始架构中，任何一个bug修复，都需要更改应用程序中某些C++ ，单个修复完，还要等待其他人完成对应用程序其他模块的更改，并对整个应用程序进行测试之后才能发布。 切换到微服务体系架构后，开发团队可以只对其负责的微服务进行更改，可以独立发布，只要保证质量即可。2) 错误隔离
在微服务体系架构中，每个团队都在独立的代码基础上工作，不仅团队间的代码冲突减少，而且错误被隔离到单个微服务中。3) 技术多样性
以前，所有的代码都是C++代码，整体开发团队被限制在一个通用的技术堆栈和过程中。 采用微服务后，允许独立的团队为给定的服务选择正确的流程和技术，采用Java或者Python等框架都可以。这样，就可以吸引更多有才华的工程师，让他们采用各种新技术。4) 新人融入快
新工程师可以安全地在一个小型的微服务上进行编码。对于一个工程师来说，没有必要仅仅为了修复一个bug而去学习一大堆代码库，学习曲线降低。5) 团队拥有更大的自主权
采用微服务的最大变化可能是文化。为了提高敏捷性和效率，微服务开发团队做出以前无法控制的决策，比如发布日期、质量策略。这一点跟前面的组织变革，正好相辅相成。三、工具变革
3.1 APOLLO
一个云应用程序可能拥有数百个单独的微服务，每个微服务可能由多个实例组成(为了可用性和可伸缩性)，这就带来微服务规模的增长；而 每个微服务将由各自的开发团队独立更新。快速增长的微服务数量和更新的频率要求一个完全自动化的部署工作流程和基础设施。 Amazon内部的APOLLO工具，在这种场景下应运而生 。APOLLO主要对环境进行管理，比如某一个服务上线需要用到哪些package group、依赖有哪些、参数要设置哪些、机器要多少台等。按最小的服务单元每次也会涉及到在几十台主机上做部署。
- 从代码到客户的全自动化。通常，一旦开发人员将代码提交源代码库，就会有一个按钮流程，自动获取最新的源代码，并将其打包到部署工件中，如容器，然后将整个工件部署到准生产或生产环境中。这被称为持续交付。
- 弹性缩放。微服务本质上是相当短暂的部署新版本、退出旧版本，并根据利用率添加或删除新实例。Amazon采用的是Elastic Compute Cloud，支持弹性扩展地部署基础设施。
3.2 Build tools
Amazon崇尚每个人有更小更明确的任务， “you build it, you run it.” 落到工具层面，这主要得益于 一个叫Build tools的组，他们把Platform和Internal tools做到了功能性和易用性在业界内数一数二。
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一键操作就可以完成。
四、流程变革
总结
如果你对搭建流水线感兴趣，想体验一下如何用工具实现真正的交付流水线，体验从修改代码再到一键上线的快感，体验如何从0到1打造一款产品，建议你来我们的 DevOps黑客马拉松 ！ ！ （识别文末图片中的二维码即可报名~） 号外！ 号外！ ！ 如果你想跟“无敌哥-王立杰”老师微信交流，请在公众号后台回复“无敌哥”，您将会得到“无敌哥-王立杰”老师的微信二维码，添加时注明理由。
拓展阅读：DevOps案例研究：知人善任——Google敏捷核心文化
DevOps案例研究：进取到让自己毛骨悚然，Netflix公司的简介和文化
DevOps案例研究|史上最能“拜客户教”的公司，是如何做到持续交付的？（第1趴）
DevOps案例研究：庖丁解牛，剖析Google持续交付之道
历久弥新 - 微软万亿市值背后的文化支撑（上）|DevOps案例研究
历久弥新 - 微软万亿市值背后的文化支撑（下）|DevOps案例研究
DevOps黑客马拉松
9月7-8日 北京
专业大咖陪你一起进化
欢迎企业组队PK，企业团队报名有特惠
目前已经有两家企业组队！！
赶紧报名吧~⬇️⬇️⬇️
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
