h*******e
发帖数: 9 | 1 最近的一个面试题,没有什么思路。大家讨论一下吧，多谢。
We have 20 physical machines for a distributed service.
After a recent release, we often observe that a random machine is down. For
example, machine 7 was down on Monday, machine 2 was down on Tuesday,
machine 15 was down on Friday, etc.
What could be the possible reason? |
d*******n
发帖数: 43 | 2 这种题最容易挂人/放水了。
保健觉得先问问细节吧，访问pattern是啥，时间多久，单点还是多个坏，坏了之后咋
修好的。
For
【在 h*******e 的大作中提到】
: 最近的一个面试题,没有什么思路。大家讨论一下吧，多谢。
: We have 20 physical machines for a distributed service.
: After a recent release, we often observe that a random machine is down. For
: example, machine 7 was down on Monday, machine 2 was down on Tuesday,
: machine 15 was down on Friday, etc.
: What could be the possible reason?
|
s***5
发帖数: 2136 | 3 这种面试题才叫有意思，有没有相关水平，一目了然。 |
n********t
发帖数: 21 | 4 memory leak
memory usage hike
load balancer把同一个IP的requests发给同一个server，但那个人一直crawl你的资源。
For
【在 h*******e 的大作中提到】
: 最近的一个面试题,没有什么思路。大家讨论一下吧，多谢。
: We have 20 physical machines for a distributed service.
: After a recent release, we often observe that a random machine is down. For
: example, machine 7 was down on Monday, machine 2 was down on Tuesday,
: machine 15 was down on Friday, etc.
: What could be the possible reason?
|
F****n
发帖数: 3271 | 5 这题还要什么思路，新的release有bug呗，面试官真是个弱智。
For
【在 h*******e 的大作中提到】
: 最近的一个面试题,没有什么思路。大家讨论一下吧，多谢。
: We have 20 physical machines for a distributed service.
: After a recent release, we often observe that a random machine is down. For
: example, machine 7 was down on Monday, machine 2 was down on Tuesday,
: machine 15 was down on Friday, etc.
: What could be the possible reason?
|
b*********8
发帖数: 985 | 6 有趣。如果是我进行debug, 第一步卸掉new release软件，装回前一版，看死机是否还
有发生。这叫故障隔离。如果死机不再发生，再对比最新版都改了什么东西。惹麻烦的
code 就在改的地方。常常新code解决一个老问题，但因为考虑不周，会惹新麻烦。不
是码工，但解决问题思路是一样的。
For
【在 h*******e 的大作中提到】
: 最近的一个面试题,没有什么思路。大家讨论一下吧，多谢。
: We have 20 physical machines for a distributed service.
: After a recent release, we often observe that a random machine is down. For
: example, machine 7 was down on Monday, machine 2 was down on Tuesday,
: machine 15 was down on Friday, etc.
: What could be the possible reason?
|
b*********8
发帖数: 985 | 7 下一步是在新代码可能发生故障的地方加入“报平安”码,看看死机前最近的现场是哪
里，各机的死相是否相似。
因为有时可能有超过一个原因至机器死机。一个原因可能掩盖另一个。菜鸟可能解决了
一个问题，但依旧死机，会很沮丧，以为自己没改对程序。其实继续查下去，把第二个
问题给改好了，就全解决了。
【在 b*********8 的大作中提到】
: 有趣。如果是我进行debug, 第一步卸掉new release软件，装回前一版，看死机是否还
: 有发生。这叫故障隔离。如果死机不再发生，再对比最新版都改了什么东西。惹麻烦的
: code 就在改的地方。常常新code解决一个老问题，但因为考虑不周，会惹新麻烦。不
: 是码工，但解决问题思路是一样的。
:
: For
|
f*******t
发帖数: 7549 | 8 这种rabbit hole题挺有意思的，可以轻松聊满一小时。
具体思路是：
communication方面，首先要问清"down"到底是什么情况，这个词太笼统。
debug方面，首先得查log，看机器为什么挂。因为有可能是别的东西坏了，与release
的service并没有直接关系。比如其它infra组正好在同一时间段往机器上deploy了某个
bad software；或者上游traffic pattern改变。如果是真的跟release有关，再看具体
是什么bug。挂掉可能有OOM，deadlock之类的各种原因。如果跟架构有关，比如不能
horizontally scale，需要re-architect。
operation方面，要考虑这个service是不是fault tolerant。如果短期内挂一台机器不
影响production，可以慢慢investigate。如果比较严重，考虑首先roll back。为了避
免未来再出这种问题，考虑通过加入integration test或者canary等方式提高
deployment的reliability。
observability方面，如果dashboard和monitor没有能快速帮助确定这类问题的metrics
，需要加上。 |
d*******n
发帖数: 43 | 9 深得pirate x 精髓 e6 bar 过了！
release
【在 f*******t 的大作中提到】
: 这种rabbit hole题挺有意思的，可以轻松聊满一小时。
: 具体思路是：
: communication方面，首先要问清"down"到底是什么情况，这个词太笼统。
: debug方面，首先得查log，看机器为什么挂。因为有可能是别的东西坏了，与release
: 的service并没有直接关系。比如其它infra组正好在同一时间段往机器上deploy了某个
: bad software；或者上游traffic pattern改变。如果是真的跟release有关，再看具体
: 是什么bug。挂掉可能有OOM，deadlock之类的各种原因。如果跟架构有关，比如不能
: horizontally scale，需要re-architect。
: operation方面，要考虑这个service是不是fault tolerant。如果短期内挂一台机器不
: 影响production，可以慢慢investigate。如果比较严重，考虑首先roll back。为了避
|
g****y
发帖数: 2810 | 10 真是胡扯的问题，服务挂了看日志，没有日志了就加日志。如果是机器重启那就去找
devops来看，什么randomly down，肯定是代码有毛病。
For
【在 h*******e 的大作中提到】
: 最近的一个面试题,没有什么思路。大家讨论一下吧，多谢。
: We have 20 physical machines for a distributed service.
: After a recent release, we often observe that a random machine is down. For
: example, machine 7 was down on Monday, machine 2 was down on Tuesday,
: machine 15 was down on Friday, etc.
: What could be the possible reason?
|
h*h
发帖数: 845 | 11 这个才是做过ops的。一帮纯developer的傻逼瞎几把BB半天没一个人提看log的。
【在 g****y 的大作中提到】
: 真是胡扯的问题，服务挂了看日志，没有日志了就加日志。如果是机器重启那就去找
: devops来看，什么randomly down，肯定是代码有毛病。
:
: For
|
e****i
发帖数: 393 | 12 ops在这显摆呢，白痴都会看日志。设计上的原理屁都不懂，下次还会再出问题。
【在 h*h 的大作中提到】
: 这个才是做过ops的。一帮纯developer的傻逼瞎几把BB半天没一个人提看log的。
|
f*******t
发帖数: 7549 | 13 日志也不是万能的，机器尤其是container“挂掉”可能日志也没了，或者信息不足以
直接判断故障原因，还得配合metrics去debug。
【在 e****i 的大作中提到】
: ops在这显摆呢，白痴都会看日志。设计上的原理屁都不懂，下次还会再出问题。
|
g****y
发帖数: 2810 | 14 你连这个服务是啥都不知道，还说什么设计原理，设计的啥啊？
【在 e****i 的大作中提到】
: ops在这显摆呢，白痴都会看日志。设计上的原理屁都不懂，下次还会再出问题。
|
g****y
发帖数: 2810 | 15 container挂了没有日志就加日志，日志丢了就在term之前flush一次，总有办法，没有
log盲人摸象才是真奇葩
【在 f*******t 的大作中提到】
: 日志也不是万能的，机器尤其是container“挂掉”可能日志也没了，或者信息不足以
: 直接判断故障原因，还得配合metrics去debug。
|
y****w
发帖数: 3747 | 16 我感觉你们PE角色的系统设计不如改成聊这种天
release
【在 f*******t 的大作中提到】
: 这种rabbit hole题挺有意思的，可以轻松聊满一小时。
: 具体思路是：
: communication方面，首先要问清"down"到底是什么情况，这个词太笼统。
: debug方面，首先得查log，看机器为什么挂。因为有可能是别的东西坏了，与release
: 的service并没有直接关系。比如其它infra组正好在同一时间段往机器上deploy了某个
: bad software；或者上游traffic pattern改变。如果是真的跟release有关，再看具体
: 是什么bug。挂掉可能有OOM，deadlock之类的各种原因。如果跟架构有关，比如不能
: horizontally scale，需要re-architect。
: operation方面，要考虑这个service是不是fault tolerant。如果短期内挂一台机器不
: 影响production，可以慢慢investigate。如果比较严重，考虑首先roll back。为了避
|
p***s
发帖数: 124 | 17 厉害 这种是经验积累的还是educative io 那种速成的？
release
【在 f*******t 的大作中提到】
: 这种rabbit hole题挺有意思的，可以轻松聊满一小时。
: 具体思路是：
: communication方面，首先要问清"down"到底是什么情况，这个词太笼统。
: debug方面，首先得查log，看机器为什么挂。因为有可能是别的东西坏了，与release
: 的service并没有直接关系。比如其它infra组正好在同一时间段往机器上deploy了某个
: bad software；或者上游traffic pattern改变。如果是真的跟release有关，再看具体
: 是什么bug。挂掉可能有OOM，deadlock之类的各种原因。如果跟架构有关，比如不能
: horizontally scale，需要re-architect。
: operation方面，要考虑这个service是不是fault tolerant。如果短期内挂一台机器不
: 影响production，可以慢慢investigate。如果比较严重，考虑首先roll back。为了避
|
