前段时间去国内一家大型电商公司做交流，正好也回顾了一下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个月内就能开始发挥全部价值。Amazon显然选择了第二种方式（想想当时才入职第二周就开始oncall了，如果没有强大工具的支持，不可能去解决系统问题的。）显然第二种方式对工程师是非常不友好的，但从资本的角度出发，这是以低廉的方法最大程序的榨取劳动力。这也导致Amazon的turn over rate要高于Google和Facebook。

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

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

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

前段时间去国内一家大型电商公司做交流，正好也回顾了一下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个月内就能开始发挥全部价值。Amazon显然选择了第二种方式（想想当时才入职第二周就开始oncall了，如果没有强大工具的支持，不可能去解决系统问题的。）显然第二种方式对工程师是非常不友好的，但从资本的角度出发，这是以低廉的方法最大程序的榨取劳动力。这也导致Amazon的turn over rate要高于Google和Facebook。

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

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

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