百度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审批会卡四天的。
