百度sre实习面经(oc)
上上周面了百度sre二面给挂了,竟然还有机会打复活赛。面了五轮sre了。
一面(40min)
介绍实习经历
说一下你们公司项目发布流程
你有一段实习经历,看得出来公司内部自动化程度不够高,要你改善整体自动化情况你怎么改,会设计哪些平台。
如果要你设计一个自动化运维平台,主要功能是方便用户直接编写各类语言脚本,到相关服务器上运行,你会怎么设计,说一下设计架构。
对sre的理解,主要发展方向希望是哪方面。
mysql慢查询原因
mysql有哪些锁
行级锁和表级锁竞争会导致什么
零拷贝
CPU负载高可能是什么原因导致的
tcp内核参数了解哪些,半连接队列和全连接队列
无手撕
面完不到一个小时约二面
二面(40min)
大部分时间都在问实习
实习经历,实习项目。
监控一个代理服务器,你会监控哪些指标。
kafka消费者怎么保证消息消费不丢失的,如何进行集群消费的
touch命令用处,在什么情况下无法执行
算法:
大概就是 力扣77.组合。 暴力过了,问我能不能通过位运算优化一下,不会。
第二天过了,约三面。
三面(1h)
一个八股没有,从实习经历的某个点切入,全程素养和场景题,一直往下问,基本都是稳定性 分布式 高可用 容灾相关的。
介绍实习,介绍开源
不好说面经,基本就从实习某个点开始一直往下问。大概就类似于这种吧:
我看你做了故障注入,故障注入的爆炸半径是怎么控制的。 (看过相关技术文档,开始背公司内的的故障注入实现方式)
故障注入的话不会抛相关异常嘛,不会导致线上服务的熔断嘛。
你设计一个思路,故障注入相关流量错误率过高导致熔断,但是不会对线上正常流量产生影响。
如果上海的某个机房因为某些原因不可用了,这个时候你会怎么办。(同城多活,异地多活架构 切流)
那你是怎么定位是上海机房出问题的呢?
我看你线上巡检是在数据库层面进行校验的,为什么不在流量打进来之前进行校验。
线上巡检相关,你这个是直接巡检数据库的,为什么不在流量层面巡检,如果要在流量层面巡检你会怎么做。(我说可以考虑类似于service mesh的那种sidecar模式,将相关的巡检逻辑解耦到sidecar里面,这样开发那边心智负担也小一点)
那假如说有很多的平台,你sidecar也很多,怎么管理sidecar配置以及相关逻辑。(我说可以参考 类似于服务网格控制面和数据面的架构)
假如说你某个sidecar发布后,无法正常使用,拦截了所有的流量导致业务受损,那咋办。(说了下冗余或者回滚)
.......
还问了下我的个人项目(分布式im),问我是如何保证你这个系统的高可用的,服务实例状态转移是怎么做的,如何保证流量不打到异常运行的服务实例的。
流程卡了四天后发offer,无法理解为何sre岗位要面三轮,而且offer审批会卡四天的。