N*****m
发帖数: 42603 | |
f*******t
发帖数: 7549 | |
g*****g
发帖数: 34805 | 3 We have 99.95 availability for last few years, that's about 4 hours down
time every year. It's not perfect but better than most companies.
Some service update caused one hour outage today.
【在 N*****m 的大作中提到】
: all region
: HA不行啊
|
w**z
发帖数: 8232 | 4 software bug?
【在 g*****g 的大作中提到】
: We have 99.95 availability for last few years, that's about 4 hours down
: time every year. It's not perfect but better than most companies.
: Some service update caused one hour outage today.
|
s***o
发帖数: 77 | 5 是啊 本来还剩下一个小时下班 说看片儿吧 结果还不给力
【在 N*****m 的大作中提到】
: all region
: HA不行啊
|
g*****g
发帖数: 34805 | 6 Every time, I don't think we have any single point of failure. But a global
service update can cause global outage.
【在 w**z 的大作中提到】
: software bug?
|
w**z
发帖数: 8232 | 7 那怎么会down 一个小时？稍微长了点。
global
【在 g*****g 的大作中提到】
: Every time, I don't think we have any single point of failure. But a global
: service update can cause global outage.
|
g*****g
发帖数: 34805 | 8 几百个服务，trigger alert 5分钟，确认是哪个服务引发的大约半小时，Roll back启
动千把instance本身要10分钟，让用户量慢慢恢复也得半小时，一下子全上来撑不住。
【在 w**z 的大作中提到】
: 那怎么会down 一个小时？稍微长了点。
:
: global
|
w**z
发帖数: 8232 | 9 那个service, 不就是single point of failure?
【在 g*****g 的大作中提到】
: 几百个服务，trigger alert 5分钟，确认是哪个服务引发的大约半小时，Roll back启
: 动千把instance本身要10分钟，让用户量慢慢恢复也得半小时，一下子全上来撑不住。
|
g*****g
发帖数: 34805 | 10 single point of failure是说逻辑正确，一个节点当了还有Availability。如果每个
节点都有同样的逻辑错误导致queue无限拉长，整个service当是没办法的事情，测试不
能保证绝对不出错。这就是
红黑push和alert的必要性。如果改动大没有把握，可以做Canary, 拿一小部分用户来
实测一阵子再把feature放出去。
【在 w**z 的大作中提到】
: 那个service, 不就是single point of failure?
|
|
|
w**z
发帖数: 8232 | 11 你们那个啥hystrix不是为了防止这种情况的吗？你们那个down 的service 是个核心的
吧。没那个就啥也干不了。
【在 g*****g 的大作中提到】
: single point of failure是说逻辑正确，一个节点当了还有Availability。如果每个
: 节点都有同样的逻辑错误导致queue无限拉长，整个service当是没办法的事情，测试不
: 能保证绝对不出错。这就是
: 红黑push和alert的必要性。如果改动大没有把握，可以做Canary, 拿一小部分用户来
: 实测一阵子再把feature放出去。
|
g*****g
发帖数: 34805 | 12 对，一个管playback的服务当了。
【在 w**z 的大作中提到】
: 你们那个啥hystrix不是为了防止这种情况的吗？你们那个down 的service 是个核心的
: 吧。没那个就啥也干不了。
|
N*****m
发帖数: 42603 | 13 你们居然没有AB testing？
【在 g*****g 的大作中提到】
: 几百个服务，trigger alert 5分钟，确认是哪个服务引发的大约半小时，Roll back启
: 动千把instance本身要10分钟，让用户量慢慢恢复也得半小时，一下子全上来撑不住。
|
g*****g
发帖数: 34805 | 14 这跟AB test没有关系。
【在 N*****m 的大作中提到】
: 你们居然没有AB testing？
|
N*****m
发帖数: 42603 | 15 为啥不能一部分nodes用新服务，一部分还用旧服务？
【在 g*****g 的大作中提到】
: 这跟AB test没有关系。
|
g*****g
发帖数: 34805 | 16 Canary test是会延缓周期的，任何改动都那么做太慢。show stopper一般是靠自动化
测试来保证没有，而不是Canary。
【在 N*****m 的大作中提到】
: 为啥不能一部分nodes用新服务，一部分还用旧服务？
|
N*****m
发帖数: 42603 | 17 问题是你昨天说这个是核心服务，这个难道不应该做？
【在 g*****g 的大作中提到】
: Canary test是会延缓周期的，任何改动都那么做太慢。show stopper一般是靠自动化
: 测试来保证没有，而不是Canary。
|
g*****g
发帖数: 34805 | 18 核心服务至少有10几个，一般大feature release才会那么做，否则平均两周一个
release，中间还有hotfix，哪能忙得过来。
【在 N*****m 的大作中提到】
: 问题是你昨天说这个是核心服务，这个难道不应该做？
|
N*****m
发帖数: 42603 | 19 still not buy it
这些release都可以自动和各种测试一起做，不存在忙不忙得过来的问题
【在 g*****g 的大作中提到】
: 核心服务至少有10几个，一般大feature release才会那么做，否则平均两周一个
: release，中间还有hotfix，哪能忙得过来。
|
g*****g
发帖数: 34805 | 20 有的问题要上量才能显示，有的问题跟每天更新的数据有关。没有测试能绝对保证不出
问题的，就是个概率问题。快速迭代很难达到4个9。
【在 N*****m 的大作中提到】
: still not buy it
: 这些release都可以自动和各种测试一起做，不存在忙不忙得过来的问题
|
|
|
N*****m
发帖数: 42603 | 21 那你们昨天这事的结论是啥？下次还会出现？
【在 g*****g 的大作中提到】
: 有的问题要上量才能显示，有的问题跟每天更新的数据有关。没有测试能绝对保证不出
: 问题的，就是个概率问题。快速迭代很难达到4个9。
|
g*****g
发帖数: 34805 | 22 还没结论，只知道可能跟数据相关。99.95是现状，99.99是目标。再出现很正常。
【在 N*****m 的大作中提到】
: 那你们昨天这事的结论是啥？下次还会出现？
|
N*****m
发帖数: 42603 | 23 管理层不高兴吧
【在 g*****g 的大作中提到】
: 还没结论，只知道可能跟数据相关。99.95是现状，99.99是目标。再出现很正常。
|
f*******t
发帖数: 7549 | 24 不高兴有啥用，大不了把出事的组砍了，但该挂的系统照样挂
【在 N*****m 的大作中提到】
: 管理层不高兴吧
|
g*****g
发帖数: 34805 | 25 这有啥的，一年平均当4个小时这不才1个小时吗。我们每年到Xmas就code freeze就这
原因。
【在 N*****m 的大作中提到】
: 管理层不高兴吧
|
ET
发帖数: 10701 | 26 netflix CEO 老早就说了：we are streaming video. Nobody gonna die because of
a service outrage.
【在 N*****m 的大作中提到】
: 管理层不高兴吧
|
