微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

近期有不法分子打着爱盈利的旗号,制作“爱盈利”名称的App,并伪造爱盈利证件,骗取用户信任,以抖音点赞赚钱或其他方式赚钱为名义,过程中以升级会员获得高佣金为名让用户充值。
爱盈利公司郑重声明:我司没有研发或运营过任何名为“爱盈利”的APP,我司做任务赚钱类产品从没有让任何普通用户充值升级会员。我公司产品均在本网站可查询,请将网站拉至底部,点击“关于我们”可查看爱盈利相关产品与服务。
温馨提示:当遇到此类问题请拨打官方电话或添加官方微信,以免财产损失。爱盈利官网地址:www.aiyingli.com。
  • 推广与合作
X

Amazon为何能做到持续交付

来源: 2390
爱盈利(aiyingli.com)移动互联网最具影响力的盈利指导网站。定位于服务移动互联网创业者,移动盈利指导。我们的目标是让盈利目标清晰可见!降低门槛,让缺乏经验、资金有限的个人和团队获得经验和机会,提高热情,激发产品。

Amazon为何能做到持续交付

作者:继小驹

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

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

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

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

Amazon为何能做到持续交付

与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上台全体动员,紧张的不行,工程师在发完新版后天天得加班。由此一例可见差距。

原文>>>

End.

转载请注明来自36大数据(36dsj.com):36大数据 » Amazon为何能做到持续交付

爱盈利-运营小咖秀 始终坚持研究分享移动互联网App数据运营推广经验、策略、全案、渠道等纯干货知识内容;是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台;

评论

相关文章推荐

SELECT dw_posts.ID,dw_posts.post_title,dw_posts.post_content FROM dw_posts INNER JOIN dw_term_relationships ON (dw_posts.ID = dw_term_relationships.object_id) WHERE 1=1 AND(dw_term_relationships.term_taxonomy_id = 3413 ) AND dw_posts.post_type = 'post' AND (dw_posts.post_status = 'publish') GROUP BY dw_posts.ID ORDER BY RAND() LIMIT 0, 6

京ICP备15063977号-2 © 2012-2018 aiyingli.com. All Rights Reserved. 京公网安备 11010102003938号