o******g
发帖数: 114 | 1 zhanmajia童鞋的感受基本属实，amazon的名声很好，但是比较好进，在里面呆两三年
正好去FLG。
Amazon的主要问题就是Retail的margin太低，确实开不出好的福利，所以大家容易
turnover，然后turnover又造成oncall的load特重。其实Facebook，Google的也有
oncall，不过由于人员稳定些，系统的bug修好了，所以load不是那么重，然后公司的
福利又好，大家就不complain，形成正循环。这是为啥Amazon的oncall complain特多
，而其他online company的oncall complain较少的原因。
另外提提amazon的技术，amazon的很多business logic的code确实质量不高，但是
amazon的整个platform和dev resource水平是相当相当相当的高（请原谅我用了3个相
当），amazon有这些东西：
1）Apollo deployment system --- 这个可以做到one click deployment 和
rollback，
2）Performance monitoring system --- 使用实在是太简单，而功能非常强大
3）Brazil build，package
4） Code search／review
第四点的水准和其他top tier的公司差不多，但是1），2），3）的东东，我的评价是：
甩微软100条街，－－－ 微软的online由于公司结构的原因，每个部门都自己做
deployment， monitoring，build，导致了水平普遍不高，在微软来说，production的
deployment／rollback是天大的事，非得dev/test/pm一起参与，在amazon，随便一个
dev就自己做了。。。。这主要得原因就是微软的online infrastructure实在是。。。
举个最奇葩的例子，在FLAG， 你都可以看任何一个人最近做了那些codecheckin，也可
以search／browse任何一个部门的绝大部分code。但是微软呢，对不起，不允许。。。
。你甚至都不知道其他部门怎么用你的API，有多少部门用。。。所以微软做不到资源
和经验教训共享，每个部门的online都自己从头做起，导致了 online 变成了笑话。在
微软daily和weeklydeployment 基本上是做梦。
甩Facebook 5条街，－－－facebook的team还比较小，operation的经验不如
amazon多，所以很多东西功能虽强大，但是不够实用，还在evolve，很多问题主要靠
engineer 的个人水平解决。。。不过，里面的engineer水平确实不错。。。
甩Google半条街－－－实事求是说，google的这些infrastsructure更强大，但是
用法及其复杂，所以导致了很多production的监控做起来很麻烦，索性很多monitoring
metrics干脆不加，反正它的service也不是象Amazon那么money related.
本人在Amazon工作过几年，其他几个intern过，所以对一些东西比较清楚，但是不完全
准确，仅供参考。。。 |
g*******s
发帖数: 2963 | |
x*****s
发帖数: 125 | 3 12确实很牛
3，brazil build其实在我看来勉强60分，不过今年以来颇有进步，road map也画了一
张不错的饼，有前途。
至于4嘛，真的不怎么样，不算缺点就不错了，放在优点里有点扯哈~~ |
v*****d
发帖数: 348 | 4 1 2 3天天用，确实彪悍，我曾经问我老板为什么不把1卖出去，老板笑笑没说话。
4的话完全看你code reviewer的水平以及认真负责的程度了。
多
【在 o******g 的大作中提到】
: zhanmajia童鞋的感受基本属实，amazon的名声很好，但是比较好进，在里面呆两三年
: 正好去FLG。
: Amazon的主要问题就是Retail的margin太低，确实开不出好的福利，所以大家容易
: turnover，然后turnover又造成oncall的load特重。其实Facebook，Google的也有
: oncall，不过由于人员稳定些，系统的bug修好了，所以load不是那么重，然后公司的
: 福利又好，大家就不complain，形成正循环。这是为啥Amazon的oncall complain特多
: ，而其他online company的oncall complain较少的原因。
: 另外提提amazon的技术，amazon的很多business logic的code确实质量不高，但是
: amazon的整个platform和dev resource水平是相当相当相当的高（请原谅我用了3个相
: 当），amazon有这些东西：
|
v*****d
发帖数: 348 | 5 真心觉得amazon是个top tier的公司，板上看不上amazon的我只能拜了。。。
【在 v*****d 的大作中提到】
: 1 2 3天天用，确实彪悍，我曾经问我老板为什么不把1卖出去，老板笑笑没说话。
: 4的话完全看你code reviewer的水平以及认真负责的程度了。
:
: 多
|
b***m
发帖数: 5987 | 6 真心支持楼主，微软的在线产品deployment实在是太坑爹了。昨晚指导OP team来
deploy我们组的小产品，如果是我亲自操作，最多十分钟搞定，结果两个三姐活活折腾
了四个小时啊！我就不明白为什么非要通过他们？ |
s*****r
发帖数: 43070 | |
A*****i
发帖数: 3587 | 8 为什么第一点我们公司都用了好几年了也没人觉得很牛逼……
我们的deploy基本上是Build＋deploy一条龙，也是只用点击一下就可以
我觉得如果公司大到一定规模，deploy还算个问题的话那这公司挺傻逼的，没必要用
dev tool来拼实力，有这些东西算正常，没有才算有问题好吧 |
f*******t
发帖数: 7549 | 9 贵公司是？
【在 A*****i 的大作中提到】
: 为什么第一点我们公司都用了好几年了也没人觉得很牛逼……
: 我们的deploy基本上是Build＋deploy一条龙，也是只用点击一下就可以
: 我觉得如果公司大到一定规模，deploy还算个问题的话那这公司挺傻逼的，没必要用
: dev tool来拼实力，有这些东西算正常，没有才算有问题好吧
|
l**b
发帖数: 457 | 10 你们不知道OP team唯一的用处就是给vendor开support ticket吗？ |
|
|
A*****i
发帖数: 3587 | 11 小公司不值一提，曾经写了业界现在比较火的开源云平台80%代码而已
我不是来比较的，只是好奇，dev tool对于一个发展到一定规模的公司来说应该是必需
品而不是奢侈品
【在 f*******t 的大作中提到】
: 贵公司是？
|
B*****g
发帖数: 34098 | 12 你这些技术能做个讲座吗？谢谢
多
【在 o******g 的大作中提到】
: zhanmajia童鞋的感受基本属实，amazon的名声很好，但是比较好进，在里面呆两三年
: 正好去FLG。
: Amazon的主要问题就是Retail的margin太低，确实开不出好的福利，所以大家容易
: turnover，然后turnover又造成oncall的load特重。其实Facebook，Google的也有
: oncall，不过由于人员稳定些，系统的bug修好了，所以load不是那么重，然后公司的
: 福利又好，大家就不complain，形成正循环。这是为啥Amazon的oncall complain特多
: ，而其他online company的oncall complain较少的原因。
: 另外提提amazon的技术，amazon的很多business logic的code确实质量不高，但是
: amazon的整个platform和dev resource水平是相当相当相当的高（请原谅我用了3个相
: 当），amazon有这些东西：
|
c*****l
发帖数: 879 | 13
大神是rackspace吧？
【在 A*****i 的大作中提到】
: 小公司不值一提，曾经写了业界现在比较火的开源云平台80%代码而已
: 我不是来比较的，只是好奇，dev tool对于一个发展到一定规模的公司来说应该是必需
: 品而不是奢侈品
|
f*******t
发帖数: 7549 | 14 小公司情况可能不太一样。我对deployment系统问题的观点比较接近楼主，在这里补充
一下我的认识吧。
大公司里不同部门使用的技术，部署需求都不一样，想实现一个能满足所有人的系统极
其困难，跟小公司或单个网站实现一键部署肯定不能混为一谈。Amazon apollo很好地
解决了这个问题，而我看到其它公司里不同的组都是各自为战。把new binary安装到每
台server上是肯定有的，所以差距体现在如何automate版本更新和rollback过程。
A的deployment系统与package dependency管理系统紧密合作，让几乎所有不同性质的
程序都能一键化。据我所知只有更新mysql database时需要很多手工操作，当然数据库
本身实在太复杂了，改变版本风险巨大。
不清楚你的公司部署时多样化的程度是不是很高。在A，retail website、kindle、AWS
的service，语言不管是java, ruby还是perl，目的地不管是server还是dev desktop，
都通过那一套系统来完成，其它公司真没的比。
【在 A*****i 的大作中提到】
: 小公司不值一提，曾经写了业界现在比较火的开源云平台80%代码而已
: 我不是来比较的，只是好奇，dev tool对于一个发展到一定规模的公司来说应该是必需
: 品而不是奢侈品
|
A*****i
发帖数: 3587 | 15 别的组不知道，我们组有几套不一样的products，都是在一个系统上面deploy的
而且都是一键完成，就这有时候我都觉得麻烦，问过manager为什么要build完再deploy
，还得同时监视metrics
不如直接把metrics和graph联通build而做在deploy的系统里面，人家的回答是，三年
前的东西要啥自行车……
AWS
【在 f*******t 的大作中提到】
: 小公司情况可能不太一样。我对deployment系统问题的观点比较接近楼主，在这里补充
: 一下我的认识吧。
: 大公司里不同部门使用的技术，部署需求都不一样，想实现一个能满足所有人的系统极
: 其困难，跟小公司或单个网站实现一键部署肯定不能混为一谈。Amazon apollo很好地
: 解决了这个问题，而我看到其它公司里不同的组都是各自为战。把new binary安装到每
: 台server上是肯定有的，所以差距体现在如何automate版本更新和rollback过程。
: A的deployment系统与package dependency管理系统紧密合作，让几乎所有不同性质的
: 程序都能一键化。据我所知只有更新mysql database时需要很多手工操作，当然数据库
: 本身实在太复杂了，改变版本风险巨大。
: 不清楚你的公司部署时多样化的程度是不是很高。在A，retail website、kindle、AWS
|
f*******t
发帖数: 7549 | 16 那amazon还是先进一点，已经做到checkin code后自动build、test、deploy到pre-
prod，最终到production还是得靠人工监视
deploy
【在 A*****i 的大作中提到】
: 别的组不知道，我们组有几套不一样的products，都是在一个系统上面deploy的
: 而且都是一键完成，就这有时候我都觉得麻烦，问过manager为什么要build完再deploy
: ，还得同时监视metrics
: 不如直接把metrics和graph联通build而做在deploy的系统里面，人家的回答是，三年
: 前的东西要啥自行车……
:
: AWS
|
A*****i
发帖数: 3587 | 17 那问题是，如果有错误怎么办？checkin后都没有code review？
自己checkin的东西保证能look good 对所有人？
【在 f*******t 的大作中提到】
: 那amazon还是先进一点，已经做到checkin code后自动build、test、deploy到pre-
: prod，最终到production还是得靠人工监视
:
: deploy
|
p*******i
发帖数: 1181 | 18 我们组前几年据说出过类似这样的错误，导致系统瘫痪了半天，后来加入了CR系统，所
有的code从dev到audit要一个CR，audit到prod还要一个人CR才能上
Btw楼主说的很好，Amazon除了绿卡慢点其他我没什么觉得不满意的地方，反正A家基本
也不裁人，Seattle地方也很好房价也比湾区便宜多了，我觉得不考虑跳槽的话绿卡政
策区别实在不大，尤其是很多Master的SDE，本来也申不了EB1要走EB2排期，那就更不
用急着申绿卡了，反正要排那么多年，移民政策又一直在改革。
【在 A*****i 的大作中提到】
: 那问题是，如果有错误怎么办？checkin后都没有code review？
: 自己checkin的东西保证能look good 对所有人？
|
s*****r
发帖数: 43070 | 19 现在有了强大的Jenkis，LiquiBase，Maven这些的tool，on-click deploy真不是多难
的事，包括DB的update和rollback。Maven可以管理所有的过程，支持中小型的web
service足够了。
AWS
【在 f*******t 的大作中提到】
: 小公司情况可能不太一样。我对deployment系统问题的观点比较接近楼主，在这里补充
: 一下我的认识吧。
: 大公司里不同部门使用的技术，部署需求都不一样，想实现一个能满足所有人的系统极
: 其困难，跟小公司或单个网站实现一键部署肯定不能混为一谈。Amazon apollo很好地
: 解决了这个问题，而我看到其它公司里不同的组都是各自为战。把new binary安装到每
: 台server上是肯定有的，所以差距体现在如何automate版本更新和rollback过程。
: A的deployment系统与package dependency管理系统紧密合作，让几乎所有不同性质的
: 程序都能一键化。据我所知只有更新mysql database时需要很多手工操作，当然数据库
: 本身实在太复杂了，改变版本风险巨大。
: 不清楚你的公司部署时多样化的程度是不是很高。在A，retail website、kindle、AWS
|
x****8
发帖数: 127 | 20 5. pipeline很牛逼啊
多
【在 o******g 的大作中提到】
: zhanmajia童鞋的感受基本属实，amazon的名声很好，但是比较好进，在里面呆两三年
: 正好去FLG。
: Amazon的主要问题就是Retail的margin太低，确实开不出好的福利，所以大家容易
: turnover，然后turnover又造成oncall的load特重。其实Facebook，Google的也有
: oncall，不过由于人员稳定些，系统的bug修好了，所以load不是那么重，然后公司的
: 福利又好，大家就不complain，形成正循环。这是为啥Amazon的oncall complain特多
: ，而其他online company的oncall complain较少的原因。
: 另外提提amazon的技术，amazon的很多business logic的code确实质量不高，但是
: amazon的整个platform和dev resource水平是相当相当相当的高（请原谅我用了3个相
: 当），amazon有这些东西：
|
|
|
j********x
发帖数: 2330 | 21 另外lz似乎不知道retail的gross margin有24%吧。。。
多
【在 o******g 的大作中提到】
: zhanmajia童鞋的感受基本属实，amazon的名声很好，但是比较好进，在里面呆两三年
: 正好去FLG。
: Amazon的主要问题就是Retail的margin太低，确实开不出好的福利，所以大家容易
: turnover，然后turnover又造成oncall的load特重。其实Facebook，Google的也有
: oncall，不过由于人员稳定些，系统的bug修好了，所以load不是那么重，然后公司的
: 福利又好，大家就不complain，形成正循环。这是为啥Amazon的oncall complain特多
: ，而其他online company的oncall complain较少的原因。
: 另外提提amazon的技术，amazon的很多business logic的code确实质量不高，但是
: amazon的整个platform和dev resource水平是相当相当相当的高（请原谅我用了3个相
: 当），amazon有这些东西：
|
g**e
发帖数: 6127 | 22 after-tax margin is 1%
【在 j********x 的大作中提到】
: 另外lz似乎不知道retail的gross margin有24%吧。。。
:
: 多
|
z****e
发帖数: 54598 | 23 万恶的资本主义
【在 g**e 的大作中提到】
: after-tax margin is 1%
|
p********r
发帖数: 1465 | 24 retail部分毛利率就低，profit就更低了，具体的可以看财务报表，目前和以后一段时
间内肯定亏钱不解释；从amazon发展战略来看，他们也不指望retail做利润增长点 |
o******g
发帖数: 114 | 25 To Avenssi, 第一点可能在有些小公司不算啥，小公司的service不多，专门做一个定
制性很强的很好用的可能并不困难。但是想想Amazon那么多service，多种多样，都能
很简单的运用好。那就是challenge的地方。我work/intern过的这几个公司除了google
的可以比比外，其他都不行。
并且大家不要小看了这几个东东的作用，没有它们，什么agile，迭代，move fast都是
空话。。。 有了它们，不怕你code写得烂，很快能定位，然后改好。说实在的，
Amazon的oncall因为infrastructure做得好，技术难度比其他几家轻松多了，我过了半
年后，oncall收到pager基本上是几分钟到半个小时搞定，然后回去睡觉，第二天看心
情决定在家发呆还是去公司写postmorterm。其他公司的pager来了，因为不特别
service oriented，找dependancy都要找会，乱七八糟，所以经常要抓很久头发才能有
点idea。不过，想想微软有pro club，google／facebook有免费饭，WS的本性发作，所
以跑了。。。 别了，黄埔军校 ：P
另外一个反例也可以证明amazon的平台很好，他的turnover很高，员工很少呆满4年，
结果系统还能运行得不错，新员工很快能上手，AWS的quality不错，就证明了他的架构
很好。
下面的blog是一个在amazon呆了六年的googler写的，what he wrote is damn right。
。。Amazon is a real service oriented company。。。
https://plus.google.com/112678702228711889851/posts/eVeouesvaVX（英文）
http://coolshell.cn/articles/5701.html （中文版） |
g**e
发帖数: 6127 | 26 最后这句Jeff Wilke肯定不同意
【在 p********r 的大作中提到】
: retail部分毛利率就低，profit就更低了，具体的可以看财务报表，目前和以后一段时
: 间内肯定亏钱不解释；从amazon发展战略来看，他们也不指望retail做利润增长点
|
x*****s
发帖数: 125 | 27 Steve Yegge可是大名鼎鼎啊
陈皓也是在亚马逊混了好多年的大牛
google
【在 o******g 的大作中提到】
: To Avenssi, 第一点可能在有些小公司不算啥，小公司的service不多，专门做一个定
: 制性很强的很好用的可能并不困难。但是想想Amazon那么多service，多种多样，都能
: 很简单的运用好。那就是challenge的地方。我work/intern过的这几个公司除了google
: 的可以比比外，其他都不行。
: 并且大家不要小看了这几个东东的作用，没有它们，什么agile，迭代，move fast都是
: 空话。。。 有了它们，不怕你code写得烂，很快能定位，然后改好。说实在的，
: Amazon的oncall因为infrastructure做得好，技术难度比其他几家轻松多了，我过了半
: 年后，oncall收到pager基本上是几分钟到半个小时搞定，然后回去睡觉，第二天看心
: 情决定在家发呆还是去公司写postmorterm。其他公司的pager来了，因为不特别
: service oriented，找dependancy都要找会，乱七八糟，所以经常要抓很久头发才能有
|
p********r
发帖数: 1465 | 28 电商现在竞争越来越激烈了，而且amazon也没有以往的免税优势了，如果之前就不赚钱
的话，之后想从这上面获取高利润只会更难
【在 g**e 的大作中提到】
: 最后这句Jeff Wilke肯定不同意
|
s*****r
发帖数: 43070 | 29 不免税是一大打击，WalmartLab也来势汹汹，Amazon的好日子恐怕难持久
【在 p********r 的大作中提到】
: 电商现在竞争越来越激烈了，而且amazon也没有以往的免税优势了，如果之前就不赚钱
: 的话，之后想从这上面获取高利润只会更难
|
g****r
发帖数: 1589 | 30 微软的online系统确实挺烂的，软件公司的本质决定的，做了这么多年还是软件公司那
一套体系结构
多
【在 o******g 的大作中提到】
: zhanmajia童鞋的感受基本属实，amazon的名声很好，但是比较好进，在里面呆两三年
: 正好去FLG。
: Amazon的主要问题就是Retail的margin太低，确实开不出好的福利，所以大家容易
: turnover，然后turnover又造成oncall的load特重。其实Facebook，Google的也有
: oncall，不过由于人员稳定些，系统的bug修好了，所以load不是那么重，然后公司的
: 福利又好，大家就不complain，形成正循环。这是为啥Amazon的oncall complain特多
: ，而其他online company的oncall complain较少的原因。
: 另外提提amazon的技术，amazon的很多business logic的code确实质量不高，但是
: amazon的整个platform和dev resource水平是相当相当相当的高（请原谅我用了3个相
: 当），amazon有这些东西：
|
|
|
p********r
发帖数: 1465 | 31 嗯，确实。不过amazon钱多的是啊，以后发展好了完全可以用service来养retail，拖
垮零售业的竞争对手
【在 s*****r 的大作中提到】
: 不免税是一大打击，WalmartLab也来势汹汹，Amazon的好日子恐怕难持久
|
C*******l
发帖数: 1198 | 32 羡慕你在M家工作。可惜我不在西岸啊。
【在 b***m 的大作中提到】
: 真心支持楼主，微软的在线产品deployment实在是太坑爹了。昨晚指导OP team来
: deploy我们组的小产品，如果是我亲自操作，最多十分钟搞定，结果两个三姐活活折腾
: 了四个小时啊！我就不明白为什么非要通过他们？
|
z****e
发帖数: 54598 | 33 wl如果要杀入这一行，对码农来说是好事，机会又多了
【在 s*****r 的大作中提到】
: 不免税是一大打击，WalmartLab也来势汹汹，Amazon的好日子恐怕难持久
|
A*****i
发帖数: 3587 | 34 呵呵，谦虚一下说小公司还真以为就是小公司了
也罢，做云计算的公司如果dev tool没有竞争力会直接影响产品效率，我觉得亚马逊这
些工具是必须的，否则一定早就被淘汰了
google
【在 o******g 的大作中提到】
: To Avenssi, 第一点可能在有些小公司不算啥，小公司的service不多，专门做一个定
: 制性很强的很好用的可能并不困难。但是想想Amazon那么多service，多种多样，都能
: 很简单的运用好。那就是challenge的地方。我work/intern过的这几个公司除了google
: 的可以比比外，其他都不行。
: 并且大家不要小看了这几个东东的作用，没有它们，什么agile，迭代，move fast都是
: 空话。。。 有了它们，不怕你code写得烂，很快能定位，然后改好。说实在的，
: Amazon的oncall因为infrastructure做得好，技术难度比其他几家轻松多了，我过了半
: 年后，oncall收到pager基本上是几分钟到半个小时搞定，然后回去睡觉，第二天看心
: 情决定在家发呆还是去公司写postmorterm。其他公司的pager来了，因为不特别
: service oriented，找dependancy都要找会，乱七八糟，所以经常要抓很久头发才能有
|
a********n
发帖数: 1287 | 35 偶们看来太落后了，写好了以后自己写个component test， 过了以后push 到gerrit
做code review。等大家和buildy都happy以后，就可以merge了。至于怎么测试，QA
checkout master branch。 |
a********n
发帖数: 1287 | 36 偶们看来太落后了，写好了以后自己写个component test， 过了以后push 到gerrit
做code review。等大家和buildy都happy以后，就可以merge了。至于怎么测试，QA
checkout master branch。 |
s********k
发帖数: 6180 | 37 陈皓已经不再A了，去阿里巴巴了
【在 x*****s 的大作中提到】
: Steve Yegge可是大名鼎鼎啊
: 陈皓也是在亚马逊混了好多年的大牛
:
: google
|
o**********t
发帖数: 406 | 38 A huge surprise that these even worth mentioning ... sure these are MUST
HAVE and having them means excellent engineering and maturity... but saying
amzn is great because of these seems quite odd.
就好像一个厨子说，我的锅和炉子都好，好得不得了，所以我是好厨师 ...
What do those even mean for end users or competitors ...
多
【在 o******g 的大作中提到】
: zhanmajia童鞋的感受基本属实，amazon的名声很好，但是比较好进，在里面呆两三年
: 正好去FLG。
: Amazon的主要问题就是Retail的margin太低，确实开不出好的福利，所以大家容易
: turnover，然后turnover又造成oncall的load特重。其实Facebook，Google的也有
: oncall，不过由于人员稳定些，系统的bug修好了，所以load不是那么重，然后公司的
: 福利又好，大家就不complain，形成正循环。这是为啥Amazon的oncall complain特多
: ，而其他online company的oncall complain较少的原因。
: 另外提提amazon的技术，amazon的很多business logic的code确实质量不高，但是
: amazon的整个platform和dev resource水平是相当相当相当的高（请原谅我用了3个相
: 当），amazon有这些东西：
|
p*****o
发帖数: 1285 | 39 同感。一键depolyment这个东西最近几年startup的SAAS公司应该都从开始就满注意的
吧。
【在 A*****i 的大作中提到】
: 为什么第一点我们公司都用了好几年了也没人觉得很牛逼……
: 我们的deploy基本上是Build＋deploy一条龙，也是只用点击一下就可以
: 我觉得如果公司大到一定规模，deploy还算个问题的话那这公司挺傻逼的，没必要用
: dev tool来拼实力，有这些东西算正常，没有才算有问题好吧
|
a***w
发帖数: 168 | 40 Engineering 的infrastructure和tools对于每个developer的个人生活还是很重要的，
如果写个feature要花个几小时整build，再花几个小时deploy，老板还要求很快上线，
这日子还好过的了么。。。
俺在M家呆过，很多时候是花>50%的时间弄这些乱七八糟的问题，但是在A家，基本上
这些事情的时间<10%.
saying
【在 o**********t 的大作中提到】
: A huge surprise that these even worth mentioning ... sure these are MUST
: HAVE and having them means excellent engineering and maturity... but saying
: amzn is great because of these seems quite odd.
: 就好像一个厨子说，我的锅和炉子都好，好得不得了，所以我是好厨师 ...
: What do those even mean for end users or competitors ...
:
: 多
|
|
|
x*****n
发帖数: 195 | 41 其实微软的TFS也可以做到了。问题是微软内部那部分组也不用TFS。。。
【在 f*******t 的大作中提到】
: 那amazon还是先进一点，已经做到checkin code后自动build、test、deploy到pre-
: prod，最终到production还是得靠人工监视
:
: deploy
|
a*****a
发帖数: 46 | 42 Amazon不只是Retail，还有Kindle和AWS。虽然我不在Kindle组，但是我一直觉得
Kindle是个很好的产品，比Nook强多了。
【在 s*****r 的大作中提到】
: 不免税是一大打击，WalmartLab也来势汹汹，Amazon的好日子恐怕难持久
|
a*****a
发帖数: 46 | 43 我不知道锅和炉子对厨师有多重要。对于SDE，良好的开发平台是很重要的，试想如果
程序提交后就可以自动编译分段测试deploy到prod，省下来的大把时间都可以去设计新
的feature了，好的开发平台可以让SDE更focus在改进自己的service而不是一遍遍重复
没必要重复的琐事。而且即使换到另外一个组，换了编程语言，也不需要重新学习怎么
build，怎么deploy，对于新人也是有帮助的吧。
顺便纠正一点fantasist说的，deploy到Prod也不需要人工监控吧，如果metrics
monitor设置好的话。 :D
saying
【在 o**********t 的大作中提到】
: A huge surprise that these even worth mentioning ... sure these are MUST
: HAVE and having them means excellent engineering and maturity... but saying
: amzn is great because of these seems quite odd.
: 就好像一个厨子说，我的锅和炉子都好，好得不得了，所以我是好厨师 ...
: What do those even mean for end users or competitors ...
:
: 多
|
z****e
发帖数: 54598 | 44 看swjuter的意思是沃尔玛打算抄袭aws
【在 a*****a 的大作中提到】
: Amazon不只是Retail，还有Kindle和AWS。虽然我不在Kindle组，但是我一直觉得
: Kindle是个很好的产品，比Nook强多了。
|
s*****r
发帖数: 43070 | 45 walmart也不差钱，策略是用retail来养service，而且walmartlab在湾区，比amazon更
容易找到牛人
【在 p********r 的大作中提到】
: 嗯，确实。不过amazon钱多的是啊，以后发展好了完全可以用service来养retail，拖
: 垮零售业的竞争对手
|
a*******r
发帖数: 510 | 46 我们组是写完代码在测试系统里测完之后才提交code review. Check in之后直接就走
pipeline deploy到pre-prod了
我知道ordering odss代码check in之后直接进prod。他们对pipeline里的测试相当有
自信啊
那问题是，如果有错误怎么办？checkin后都没有code review？自己checkin的东西保
证能look good 对所有人？
【在 A*****i 的大作中提到】
: 那问题是，如果有错误怎么办？checkin后都没有code review？
: 自己checkin的东西保证能look good 对所有人？
|
s*****r
发帖数: 43070 | 47 Amazon购物平台里最有价值就是recommendation engine和payment，属于看家本领，比
kindle的价值高多了。
【在 a*****a 的大作中提到】
: Amazon不只是Retail，还有Kindle和AWS。虽然我不在Kindle组，但是我一直觉得
: Kindle是个很好的产品，比Nook强多了。
|
l****o
发帖数: 315 | 48 你的头像实在太养眼...导致特别容易关注你的留言.
话说你没在A家干过吧? 怎么感觉分析的都是A家各种不好. 别人只要说句好你也会马上
驳回去.
话说真正应该complain的应该是我们这些整天被call的要死工资还没新人高的人吧.
【在 s*****r 的大作中提到】
: Amazon购物平台里最有价值就是recommendation engine和payment，属于看家本领，比
: kindle的价值高多了。
|
j******f
发帖数: 825 | 49 amazon定级别工资不看经验，只看面试表现，这样造成很多fresh grad赚得比很多
senior的人还多，senior的人自然留不住，fresh grad更是跑得快，福利那么差，工作
那么累，出去找工作那么容易，显然留不住人。不过他家好像也不在乎，就是一直招人
。 |
f*******t
发帖数: 7549 | 50 因为A家平台无敌，每个人真成了螺丝钉，经常换换无压力
【在 j******f 的大作中提到】
: amazon定级别工资不看经验，只看面试表现，这样造成很多fresh grad赚得比很多
: senior的人还多，senior的人自然留不住，fresh grad更是跑得快，福利那么差，工作
: 那么累，出去找工作那么容易，显然留不住人。不过他家好像也不在乎，就是一直招人
: 。
|
|
|
C*******l
发帖数: 1198 | 51 原来是这样。受教了。谢谢你。
【在 j******f 的大作中提到】
: amazon定级别工资不看经验，只看面试表现，这样造成很多fresh grad赚得比很多
: senior的人还多，senior的人自然留不住，fresh grad更是跑得快，福利那么差，工作
: 那么累，出去找工作那么容易，显然留不住人。不过他家好像也不在乎，就是一直招人
: 。
|
g*****g
发帖数: 34805 | 52 I think you exaggerate, there's an entire stack of open source tools for CI
and deployment. e.g. Jenkins for CI and Asgard for deployment to AWS, Maven
for package dependency management.
These tools provide fully automatic CI and deployment by your rules. One
click rollback too. The difficulty is really whether the company embraces
SOA and the ability to execute. For an established company, it can be
painful to migrate to SOA architecture and they chose not to。
AWS
【在 f*******t 的大作中提到】
: 小公司情况可能不太一样。我对deployment系统问题的观点比较接近楼主，在这里补充
: 一下我的认识吧。
: 大公司里不同部门使用的技术，部署需求都不一样，想实现一个能满足所有人的系统极
: 其困难，跟小公司或单个网站实现一键部署肯定不能混为一谈。Amazon apollo很好地
: 解决了这个问题，而我看到其它公司里不同的组都是各自为战。把new binary安装到每
: 台server上是肯定有的，所以差距体现在如何automate版本更新和rollback过程。
: A的deployment系统与package dependency管理系统紧密合作，让几乎所有不同性质的
: 程序都能一键化。据我所知只有更新mysql database时需要很多手工操作，当然数据库
: 本身实在太复杂了，改变版本风险巨大。
: 不清楚你的公司部署时多样化的程度是不是很高。在A，retail website、kindle、AWS
|
rh
发帖数: 3901 | 53 Amazon的retail margin怎么会低？
感觉他们很赚钱啊
多
【在 o******g 的大作中提到】
: zhanmajia童鞋的感受基本属实，amazon的名声很好，但是比较好进，在里面呆两三年
: 正好去FLG。
: Amazon的主要问题就是Retail的margin太低，确实开不出好的福利，所以大家容易
: turnover，然后turnover又造成oncall的load特重。其实Facebook，Google的也有
: oncall，不过由于人员稳定些，系统的bug修好了，所以load不是那么重，然后公司的
: 福利又好，大家就不complain，形成正循环。这是为啥Amazon的oncall complain特多
: ，而其他online company的oncall complain较少的原因。
: 另外提提amazon的技术，amazon的很多business logic的code确实质量不高，但是
: amazon的整个platform和dev resource水平是相当相当相当的高（请原谅我用了3个相
: 当），amazon有这些东西：
|
o******1
发帖数: 275 | 54 for all successfully company, they have special technology advantage which
is well established, those advantage won't directly convert into benefits
for employees. Amazon ' engineering infrastructure seems pretty impressive
in large online deployment, but what really made amazon different from
competitor is their business model.
I am not sure amazon is really outstanding in terms of technology,
employees mostly care how company treat their employees, and prospects of
the company. In terms of this, I am not sure Amazon is right company you
should invest your career on it.
g (Obesepig) 的大作中提到: 】
多 |
c****7
发帖数: 4192 | 55 赞
多
【在 o******g 的大作中提到】
: zhanmajia童鞋的感受基本属实，amazon的名声很好，但是比较好进，在里面呆两三年
: 正好去FLG。
: Amazon的主要问题就是Retail的margin太低，确实开不出好的福利，所以大家容易
: turnover，然后turnover又造成oncall的load特重。其实Facebook，Google的也有
: oncall，不过由于人员稳定些，系统的bug修好了，所以load不是那么重，然后公司的
: 福利又好，大家就不complain，形成正循环。这是为啥Amazon的oncall complain特多
: ，而其他online company的oncall complain较少的原因。
: 另外提提amazon的技术，amazon的很多business logic的code确实质量不高，但是
: amazon的整个platform和dev resource水平是相当相当相当的高（请原谅我用了3个相
: 当），amazon有这些东西：
|
j********x
发帖数: 2330 | 56 倒不如说oncall到最后大家都习惯build傻逼系统
如果问题简单到page之后1／2小时就解决 那本来问题就不该是oncall解决而应该系统
自己处置
a的问题就是不给好的engineer活路 劣币太多。。。
google
【在 o******g 的大作中提到】
: To Avenssi, 第一点可能在有些小公司不算啥，小公司的service不多，专门做一个定
: 制性很强的很好用的可能并不困难。但是想想Amazon那么多service，多种多样，都能
: 很简单的运用好。那就是challenge的地方。我work/intern过的这几个公司除了google
: 的可以比比外，其他都不行。
: 并且大家不要小看了这几个东东的作用，没有它们，什么agile，迭代，move fast都是
: 空话。。。 有了它们，不怕你code写得烂，很快能定位，然后改好。说实在的，
: Amazon的oncall因为infrastructure做得好，技术难度比其他几家轻松多了，我过了半
: 年后，oncall收到pager基本上是几分钟到半个小时搞定，然后回去睡觉，第二天看心
: 情决定在家发呆还是去公司写postmorterm。其他公司的pager来了，因为不特别
: service oriented，找dependancy都要找会，乱七八糟，所以经常要抓很久头发才能有
|
