Amazon为何能做到持续交付

网络 通信技术
Amazon可以让一个Dev从功能的设计,开发,测试,发布,后续的监控一个人在完成。平均每十几秒就有一次发布,每天发布好几千次,保证快速高质量的持续交付。

前段时间去国内一家大型电商公司做交流,正好也回顾了一下Amazon的经历方便做比对。以下信息应该都是可以公开的。

Amazon可以让一个Dev从功能的设计,开发,测试,发布,后续的监控一个人在完成。平均每十几秒就有一次发布,每天发布好几千次,保证快速高质量的持续交付。

从工程师管理上,主要实行了DevOps。让每个人有更小更明确的任务,you build it, you run it. 而工具方面这主要得益于一个Build tools的组,他们把Platform和Internal tools做到了功能是和易用性上在界内数一数二。让Amazon retail那个超级庞大复杂的网站时刻可以被流畅的使用。而这个组做的主要工具有5类:

  1. Brazil Build, 对package进行分发和建立,每次build至少涉及上百个package,可以在几分钟甚至几十秒内完成build并保证不出错。
  2. Apollo Deployment, 对环境进行管理,比如某一个service上线需要用到哪些package group,依赖有哪些,参数要设置哪些,机器要多少台etc。按最小的service单元每次也会涉及到在几十台host上做deployment。
  3. Code base,所有代码存放在中央代码库,可以按reference,method,keyword之类搜索所有相关代码。
  4. Monitoring System,对service进行监控,告警,故障分析etc。
  5. Pipeline,把build,test,deploy全部串起来,对整个流程进行监控。大部分操作如rebuild,代码回滚,停止deploy一键操作就可以完成。

与Microsoft相比,Amazon的所有tools全公司统一使用的,更新及时且统一,有专门非常大一个组负责开发维护。而Microsoft由于组织架构原因,各个组间code不是互相可见的,做这些tools也各自为战,你做一套我做一套,精力分散加上code/api等不透明导致online infra做的非常渣。以至于Microsoft想rollback一次得叫上PM,QA,Dev等人一起弄个大动作。而Amazon随便一个Dev通过Apollo只需one click就可以rollback了。这也导致Microsoft想做daily deployment几乎不可能,更别说hourly deployment了。

Facebook也有十余年历史了,但Ops的经验还相对不足。有时候看Facebook的朋友工作做时用到了一些工具,总体感觉缺乏统一规划性,deployment tool,monitoring都有,但是还不够完善。好在工程师们都足够强,可以依赖工程师的个人素质去解决一些问题。这个一会儿后面再补充几句。

以Google的人才和技术实力,Internal tools自然也是一样都不缺,唯一的区别是在易用性上还和Amazon的差一点,当然对于Google的工程师来说,这点区别并不造成太大影响。

刚才说到Facebook和工具还不完善,很多时候要依赖于工程师素质,Google的工具易用性也还可以提高。那么为什么Amazon要把internal tools做的这么强大并且这么产品化呢?按一般公司的想法,内部工具反正给内部用的,能用就行,好不好用,丑不丑,统一不统一都不重要。

这涉及到Amazon的人才战略。Amazon 90%以上的是初级程序员。来自于校招或1-2年工作经验。想让这些人真正发挥出价值有两条路可以选:

1.花1年培养他们,让他们对业务能独当一面。

2.给他们拆分出足够小足够简单的任务,并给出足够强大的辅助工具,让他们可以在1-2个月内就能开始发挥全部价值。Amazon显然选择了第二种方式(想想当时才入职第二周就开始oncall了,如果没有强大工具的支持,不可能去解决系统问题的。)显然第二种方式对工程师是非常不友好的,但从资本的角度出发,这是以低廉的方法***程序的榨取劳动力。这也导致Amazon的turn over rate要高于Google和Facebook。

以前作为工程师,也非常喜欢Google对待工程师的方式,不过后来更多的接触商业之后觉得Amazon和Uber这样的公司,哪怕是Facebook这样的公司,才更像一个正常的商业运作的公司,而Google这种过于理想化的方式更像是在研究所。

那么什么时候公司需要开始重视internal tools呢?按之前Twitter一名工程师分析的结论(文章暂时找不到)是当公司工程师团队超过50人时,internal tools可以开始提升整体团队的效率和工程质量。上面比较的几家都是工程师非常强的公司,如果你的公司的工程师强不到那种程度, 利用好工具做好持续发布更尤为重要。

美国大部分公司是很支持并愿意去做internal tools的,而国内由于对工具价值的理解不够,或者说对长期规划不足,导致与重视程度也不够。听说滴滴每次发个新版还要CEO上台全体动员,紧张的不行,工程师在发完新版后天天得加班。由此一例可见差距。

责任编辑:武晓燕 来源: 知乎专栏 @继小驹
相关推荐

2015-10-26 10:34:20

IaaS持续交付

2019-06-03 15:30:27

操作系统Android 华为

2017-02-27 18:28:45

持续交付部署

2017-02-27 18:35:23

集成交付部署

2017-12-24 21:29:18

OpenShift持续交付集群

2017-02-27 18:50:42

运维持续交付

2016-08-05 17:19:37

持续集成持续交付系统运维

2020-03-31 09:53:08

互联网数据技术

2017-10-19 09:47:55

容器化微服务集成

2018-01-05 10:47:59

前端JavascriptWeb

2016-12-27 19:26:43

2019-04-30 13:09:30

苹果微软KOL

2018-05-05 14:34:57

云计算区块链融合

2016-01-07 10:29:36

MesosDocker持续交付

2023-05-12 15:07:40

测试开发

2021-03-31 09:00:00

管道集成工具

2022-04-21 14:43:59

AI数据隐私

2022-11-24 13:36:23

网络信息

2024-11-26 08:36:56

SpringJar机制

2015-12-11 10:27:50

易维帮助台/Helpd
点赞
收藏

51CTO技术栈公众号