z*******a
发帖数: 858 | 1 先说Oncall：
没钱，“义务的”，想多拿钱的少年们醒醒；也不要认为oncall多了老板会减少你的工
作量，老板也要吃饭、升职，欢迎来到oncall的亚马逊；
每个组不一样，有些组没有oncall，有些有一点，有些非常重，累到死；
7-24，想想如果半夜1点叫你起来，一直弄到凌晨5点，第二天还得上班……；
oncall的必要性在于，亚马逊零售以及AWS都是24小时运转的，而且零售部分在中国、
日本、欧洲的部分也由美国支持，所以几点都有被call到的概率；
oncall的源头在于亚马逊没有比较完善的operational layer，所以仓库出了问题，那
边工人直接通过oncall跟SDE联系，效率高、还省了operational layer的雇人的钱，但
是代价是SDE累、压力大；
oncall非常伤，主要是一方面压力大必须尽快解决，另一方面是时间可能是在半夜，而
且还必须在短时间内（15分钟）开始work；节假日全年无休，不过本身亚马逊假日只有
最minimum的6天，所以倒也无妨，哈哈！
有些oncall很扯淡，但是你没办法，因为SDE在这个公司实际上地位很低；
oncall和turnover rate高组合，会产生雪崩效应。一个组有10个人，两个多月才轮到
oncall一周，尚可以接受；结果后面经济形式好了，10个人跑了6个，剩下四个就一个
月轮一周oncall了——老板或是亚马逊不会为你考虑的。当然，如果之后跑掉的是你，
万事大吉；如果“可惜不是你”，那么就只能三周就有一周oncall了——很惨；
再说Bar Raiser
Bar Raiser出身于技术类的manager或是资深的SDE，一般多是级别高、经验丰富的人；
需要内部特殊认证；
Bar Raiser拥有一票否决权，说你不行基本就挂 （偶尔有例外）；一般他都说你行，
别人更不可能说你不行；
Bar Raiser理论上看的是你整体的技术理解，和以后的技术发展潜力；
Bar Raiser在onsite时必定会出现；如果没碰到……恭喜你，赶紧跟他们联系，还得重
新面；
Bar Raiser问题一般较为开放、原创性。比如：设计亚马逊的“recommended items
for you”的结构；或是问题很基础，但是要求你对scalability、distrubted system
（假设你有此背景）有一定的敏感性；
Bar Raiser不是故意为难人的，而是在看你的“潜力”，或是说能力极致在哪里；
Bar Raiser的问题不是固定的，有写code的，有设计的，有OOD的，貌似什么都有，但
是一般问题开放而且相对有些难度；
面对Bar Raiser不要觉得写出code就完事儿，尽量多讨论、多从技术上完善，多结合实
际经验；
如果Bar Raiser拿下，HM也同意，基本上被录用无压力；
亚马逊招到的人质量不错，Bar Raiser功不可没。 |
f*******3
发帖数: 206 | 2 大牛您莫非就是人称山东忽保义及时雨的宋公明哥哥，请受小弟一拜！
你的两个关于amazon的post给我这种刚要进去的菜鸟太多有用信息了。 |
A*****i
发帖数: 3587 | 3 亚麻每年都要调戏老子一次，从两年前毕业开始，当时觉得这么大的公司薪水还高确实
是dream company
今年知道我们组烙印是从亚马逊SDEIII跳来我们公司的才发觉亚马逊也就那样
不过话说回来当年要是进了亚马逊，现在情况应该会好很多，至少应该在一个比现在高
一些的水平线上
纯YY而已 |
f*******t
发帖数: 7549 | 4 oncall和turnover rate高组合，会产生雪崩效应。一个组有10个人，两个多月才轮到
oncall一周，尚可以接受；结果后面经济形式好了，10个人跑了6个，剩下四个就一个
月轮一周oncall了——老板或是亚马逊不会为你考虑的。当然，如果之后跑掉的是你，
万事大吉；如果“可惜不是你”，那么就只能三周就有一周oncall了——很惨
这段写的太好了，我看着都快哭了 |
z*******o
发帖数: 4773 | 5 那些call是怎么分配过来的呢? 每个组都有, 出了问题谁知道是哪个组的? |
x*********n
发帖数: 28013 | |
z*******a
发帖数: 858 | 7 靠猜。call你的人你可以认为是你的程序的user。
比如A组被call了，然后发现是B组问题，B组被oncall，然后又发现是C组的程序，最后
C组再发现是数据库问题，然后DBA再出来。
所以一个简单oncall可能走好几个组。
【在 z*******o 的大作中提到】
: 那些call是怎么分配过来的呢? 每个组都有, 出了问题谁知道是哪个组的?
|
z*******a
发帖数: 858 | 8 你是大牛。
我是正常人。
【在 x*********n 的大作中提到】
: 3星期1次on call的路过表示没有压力。
|
z****e
发帖数: 54598 | 9 aws因为有个cloud概念，最早这个概念就是a提出来的
所以跳槽时候，是个很好的筹码，至少可以说你做过cloud
类似mapreduce这个概念其实是g提出来的一样
这两个算是最近比较红火的领域
还有一个是nosql |
P**l
发帖数: 3722 | |
|
|
l***i
发帖数: 1309 | 11 不是所有web公司，FLG都有oncall的么，不过G有SRE，L和F怎么解决oncall？
【在 f*******t 的大作中提到】
: oncall和turnover rate高组合，会产生雪崩效应。一个组有10个人，两个多月才轮到
: oncall一周，尚可以接受；结果后面经济形式好了，10个人跑了6个，剩下四个就一个
: 月轮一周oncall了——老板或是亚马逊不会为你考虑的。当然，如果之后跑掉的是你，
: 万事大吉；如果“可惜不是你”，那么就只能三周就有一周oncall了——很惨
: 这段写的太好了，我看着都快哭了
|
x*********n
发帖数: 28013 | 12 我是被老板压榨的民工。
【在 z*******a 的大作中提到】
: 你是大牛。
: 我是正常人。
|
M********5
发帖数: 715 | |
z*******a
发帖数: 858 | 14 你在Linkedin？
【在 M********5 的大作中提到】
: 文笔很好！！！
|
f*******t
发帖数: 7549 | 15 F也靠SRE team，L多半类似。
【在 l***i 的大作中提到】
: 不是所有web公司，FLG都有oncall的么，不过G有SRE，L和F怎么解决oncall？
|
z****e
发帖数: 54598 | 16 运来sre的意思就是运维啊
难怪很多人不愿意去
【在 f*******t 的大作中提到】
: F也靠SRE team，L多半类似。
|
f*******t
发帖数: 7549 | 17 F叫production engineer。有选择的话尽量别做测试、运维
【在 z****e 的大作中提到】
: 运来sre的意思就是运维啊
: 难怪很多人不愿意去
|
M********5
发帖数: 715 | 18 我就是混日子的，在哪都是混日子，所以在哪都不重要。。。
【在 z*******a 的大作中提到】
: 你在Linkedin？
|
z*******a
发帖数: 858 | 19 还以为是我认识的一个人……
【在 M********5 的大作中提到】
: 我就是混日子的，在哪都是混日子，所以在哪都不重要。。。
|
s*v
发帖数: 44 | 20 感谢分享，楼主好人
【在 z*******a 的大作中提到】
: 先说Oncall：
: 没钱，“义务的”，想多拿钱的少年们醒醒；也不要认为oncall多了老板会减少你的工
: 作量，老板也要吃饭、升职，欢迎来到oncall的亚马逊；
: 每个组不一样，有些组没有oncall，有些有一点，有些非常重，累到死；
: 7-24，想想如果半夜1点叫你起来，一直弄到凌晨5点，第二天还得上班……；
: oncall的必要性在于，亚马逊零售以及AWS都是24小时运转的，而且零售部分在中国、
: 日本、欧洲的部分也由美国支持，所以几点都有被call到的概率；
: oncall的源头在于亚马逊没有比较完善的operational layer，所以仓库出了问题，那
: 边工人直接通过oncall跟SDE联系，效率高、还省了operational layer的雇人的钱，但
: 是代价是SDE累、压力大；
|
|
|
l***i
发帖数: 1309 | |
z*******o
发帖数: 4773 | 22 直接就debug改codes? 然后就发布? 太不靠谱了吧? 改坏了其他功能怎么办?
还是就这个客户的transaction处理一下?
【在 z*******a 的大作中提到】
: 靠猜。call你的人你可以认为是你的程序的user。
: 比如A组被call了，然后发现是B组问题，B组被oncall，然后又发现是C组的程序，最后
: C组再发现是数据库问题，然后DBA再出来。
: 所以一个简单oncall可能走好几个组。
|
q*c
发帖数: 9453 | 23 这是变态自虐，哈哈
【在 z*******a 的大作中提到】
: 你是大牛。
: 我是正常人。
|
v***n
发帖数: 5085 | |
b******y
发帖数: 9224 | 25
个人的生活个人选择，有的人不care oncall啥的，无所谓。我有个亚麻的朋友，说
oncall简直像死了似的，半夜叫起来干活儿，一会儿完事儿又睡不着了。这哥们儿现在
已经离开亚麻，去了软软了
【在 v***n 的大作中提到】
: 小饭好奇了 亚麻没有人生个娃养个家啥的吗
|
a*******r
发帖数: 510 | 26 提供这种web服务的公司应该都有oncall吧 fb，google啥的 |
z****e
发帖数: 54598 | 27 已经有人说了，f靠production engineer，g靠sre
其实很多公司都有类似问题，但是一般是运维组解决
让开发on call的其实不多，但是不多归不多，多数公司都有on call的policy
只不过不象a这么常用罢了，比如g，稍微错一点，客户不那么敏感
不会马上投诉，也不会要求你马上就解决，除非机器彻底崩了
那这个也是sre来搞定，f类似，我发现facebook上那个places地图经常出问题
【在 a*******r 的大作中提到】
: 提供这种web服务的公司应该都有oncall吧 fb，google啥的
|
g**e
发帖数: 6127 | 28 FB developer API三天两头出问题。隔几天就能收到他们的信说有什么什么问题正在解
决，过几个小时又来一封信说一句修好
【在 z****e 的大作中提到】
: 已经有人说了，f靠production engineer，g靠sre
: 其实很多公司都有类似问题，但是一般是运维组解决
: 让开发on call的其实不多，但是不多归不多，多数公司都有on call的policy
: 只不过不象a这么常用罢了，比如g，稍微错一点，客户不那么敏感
: 不会马上投诉，也不会要求你马上就解决，除非机器彻底崩了
: 那这个也是sre来搞定，f类似，我发现facebook上那个places地图经常出问题
|
a*******r
发帖数: 510 | 29 看Log吧，靠猜的话把a也说的太低端了。
我还没见到过要靠猜的ticket
靠猜。call你的人你可以认为是你的程序的user。比如A组被call了，然后发现是B组问
题，B组被oncall，然后又发现是C组的程序，最后C组再发现是数据库问题，然后DBA..
......
【在 z*******a 的大作中提到】
: 靠猜。call你的人你可以认为是你的程序的user。
: 比如A组被call了，然后发现是B组问题，B组被oncall，然后又发现是C组的程序，最后
: C组再发现是数据库问题，然后DBA再出来。
: 所以一个简单oncall可能走好几个组。
|
f*******t
发帖数: 7549 | 30 非技术部门经常cut错组，因为他们不懂技术，没办法判断到底哪里出了问题
..
【在 a*******r 的大作中提到】
: 看Log吧，靠猜的话把a也说的太低端了。
: 我还没见到过要靠猜的ticket
:
: 靠猜。call你的人你可以认为是你的程序的user。比如A组被call了，然后发现是B组问
: 题，B组被oncall，然后又发现是C组的程序，最后C组再发现是数据库问题，然后DBA..
: ......
|
|
|
x*****0
发帖数: 452 | |
p*******i
发帖数: 1181 | 32 也没那么大压力啦，响了以后拿手机回个Looking Into it，丢那等两个小时也成，或
者简单扫一眼直接assign给负责的人就行了，也就只有tt的内容刚好是你自己负责的方
向比较烦啦，不过回复一下拖个几小时到上班时间或者白天再处理一般无所谓的 |
