Amazon为什么能作到持续交付

本文来源：知乎专栏 @继小驹，做者林坦，曾就任于美国Amazon总部负责全球交易系统以及存储系统，现为互利科技创始人兼CEO。
原文连接：https://zhuanlan.zhihu.com/p/...

前段时间去国内一家大型电商公司作交流，正好也回顾了一下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上台全体动员，紧张的不行，工程师在发完新版后每天得加班。由此一例可见差距。