我当了三年SRE也面过几十个校招生聊聊这个岗位的面试到底考什么说实话SRE这个岗位前几年在校招里还是比较小众的很多同学第一次听到这个词会下意识问一句“这是不是就是运维做备份、发版本、看监控”如果面试的时候你也这么回答大概率第一印象就减分了。我做了三年SRE也作为面试官参与过几十场校招面试最直观的感受是SRE不缺简历缺的是真正理解这个岗位在干什么的人。校招不像社招没有人指望你刚毕业就能独当一面扛下一条业务线但面试官一定会通过层层提问确认你有没有那个“底子”和“思维方式”——基础的计算机功底、对稳定性和可靠性问题的敏感度以及遇到线上故障时不慌不乱的拆解能力。这篇文章我想以面试官的视角把校招SRE面试涉及的基础理论、技能考察、实战场景和常见失分点一次说透。内容不会太玄乎都是我在真实面试中反复问到的东西也是候选人最容易翻车的地方。1. 先理解SRE到底是个什么岗位面试官的考察逻辑才说得通1.1 不是“升级版运维”而是“用工程手段解决可靠性问题”的岗位很多面试题答不好根源在于对岗位定位的理解是偏的。SRE全称Site Reliability Engineering站点可靠性工程这个概念最早是Google在2003年提出的。它的核心思路很简单当系统规模大到一定程度靠人工盯监控、手工扩机器、人肉传话式的变更操作一定会出问题所以要用软件工程和自动化的方式把“运维”这件事本身变成可编码、可度量、可持续优化的系统。注意这里的关键词可度量。SRE和传统运维最大的区别不是“做的事情不同”而是“做事的依据不同”。传统运维往往靠经验判断“好像有点慢”“最近不太稳定”而SRE必须要用量化指标回答“可用性是多少”“性能是否达标”“容量还能撑多久”。面试官考察一个校招候选人时并不指望你能说出Google SRE内部某套系统的实现细节但至少你要本能地知道一切稳定性工作最终都要落到数字上。另外要分清SRE和运维的另一个区别SRE需要具备一定的开发能力。Google当年对SRE有一个著名的说法SRE团队预算中最多允许50%的时间投入到运维相关的琐碎事务中剩下50%必须用来做开发。因为如果SRE整天在做重复劳动说明这个系统的自动化程度不够团队应该写代码去消灭这些重复劳动而不是加人来做。校招面试问到编程题、要求你写脚本或简单算法背后的动机也来源于此。1.2 校招面试官真正想确认的三样东西基础、敏感度、沟通校招候选人没有太多真实生产经验这个面试官心知肚明所以不会用社招的标准卡你。我参与校招面试时基本上在每一轮都会观察三个方面。第一是基础。这里包括计算机基础操作系统、网络、数据结构也包括SRE领域的基础概念SLO、监控、容量、灾备等。基础不牢后面所有问题都会谈飘因为SRE的日常就是和这些底层的家伙打交道。第二是稳定性敏感度。简单说就是看到一个系统现象时能不能迅速意识到“这可能是一个可靠性问题”。比如给你一个场景某服务在流量高峰期请求变慢你会想到什么是先去抓代码bug还是先看机器负载、连接数、慢日志SRE的思维习惯是第一时间从“系统整体健康度”出发而不是钻进某个局部细节出不来。这个敏感度可以通过平时阅读故障案例、自己动手搭建小系统来培养。第三是沟通与协作。SRE经常处在开发、运维、产品、客服的交叉点上。线上告警了SRE要能冷静地拉群、说明现状、协调相关人员而不是自己闷头查。面试中会有一些场景题专门考察这一点比如“线上P1事故你只有10分钟会怎么处理”这个时候说的每一句话其实都在暴露你的沟通和取舍能力。1.3 简历上什么内容加分什么内容会让面试官皱眉这点额外提一下因为校招简历我见过太多“假大空”的写法。比如“熟悉Linux操作系统”“了解Docker和Kubernetes”“对高可用有深入理解”这些词本身没有问题但如果你不能在后续面试中接住追问它们反而会成为减分项。面试官看到一个“深入理解”下意识就会往深里问一旦发现你连基础命令、核心组件原理都讲不清印象会非常差。更好的方式是量化场景化。比如不要写“熟悉Python”而是写“使用Python编写过自动化拨测脚本每日定时监测API接口可用性曾发现并定位3次服务异常”不要写“了解监控系统”而是写“基于Prometheus和Grafana搭建过个人项目的监控面板配置过CPU、内存、流量等指标的告警规则”。这样的表述既证明你会也证明你真正用过。用简短的“为什么”串起来为什么选这个工具、解决了什么问题、结果如何这就是面试时最好的自我介绍素材。2. 基础理论盘底SRE的核心概念怎么答才不飘2.1 SLI / SLO / SLA这三兄弟的关系千万不能讲糊SRE面试中出现频率最高的概念可能就是这个了。面试官一般会问SLI、SLO、SLA分别是什么它们有什么关系如果只答“SLI是指标SLO是目标SLA是协议”可以拿到基础分但拿不到高分。要拿高分你需要把这三者的链路讲清楚。SLI就是Service Level Indicator服务等级指标是可量化的测量结果比如请求成功率99.9%、请求平均延迟100ms。SLO是Service Level Objective服务等级目标是你给系统定的目标线比如“季度可用性SLO为99.95%”。SLA是Service Level Agreement服务等级协议也是对外签订的合同达不到是要赔钱的。关键点在于SLA的数值必须大于等于SLO的数值因为对外承诺要留有余量。比如你内部定SLO是99.99%对外SLA可能签99.9%中间这0.09%就是风险缓冲。我曾面试过一个候选人他把SLO讲成“对外承诺”把SLA讲成“内部标准”差点把方向搞反了。这一下就能看出理论与实践是否结合过。另外SRE有一个相关概念叫Errors Budget错误预算也就是1减去SLO后的比例。比如SLO是99.9%错误预算就是0.1%意味着一个季度里大约可以有43分48秒的不可用时间。这个额度不是用来“尽量不花”的而是允许开发和发布风险操作的。只要错误预算还没烧完团队就可以正常迭代、发布新功能预算快烧完了就要收紧变更节奏优先做稳定性工作。这个逻辑本质上是把“发布速度”和“系统稳定”的冲突变成了一个可计算、可协商的工程问题。面试时如果你能主动提到错误预算的应用面试官基本会眼睛一亮。2.2 监控体系四个黄金信号、USE方法、告警分级监控是SRE的地基也是面试必问题。我曾经问过一个候选人“你收到一条告警说某台机器的CPU使用率到了95%你下一步做什么”他说“马上排查是什么进程占用的CPU。”这个回答对吗方向对但不够SRE——他缺少一个前置动作确认这条告警的级别并评估它对业务的实际影响。SRE视角的监控体系可以拆成三个层次指标采集、告警规则、响应流程。指标方面业界常用的框架有两个。一个是Google提出的四个黄金信号延迟Latency、流量Traffic、错误Errors、饱和度Saturation。延迟包括请求处理时间和响应时间流量反映当前请求量错误指请求失败率、错误返回码等饱和度看资源或者服务接近满载的程度。另一个是Brendan Gregg的USE方法主要用于基础设施使用率Utilization、饱和度Saturation、错误Errors可以用它快速排查CPU、内存、磁盘、网络等资源问题。告警分级也很重要。P1指核心业务完全不可用或资金损失风险极高需要立即响应P2指系统部分功能异常但核心链路可用P3是一般性问题可以在工作时间内处理。我记得有位候选人回答告警分级时把P1定义成“影响超过10%用户”其实这个数字本身不是关键也不存在一个通行的统一标准每个团队会根据自己的业务制定。面试时与其硬背阈值不如说清楚“分级依据是业务影响范围和紧急程度”这反而显得你有判断力。2.3 容量规划不是“估个数字”而是“有依据地预估”容量规划也是SRE的高频考点但校招候选人往往答得很虚。有同学会说“提前加机器”“用云上弹性伸缩”听着没错但面试官更希望看到你脑子里有一条完整的计算链路。容量规划的基本思路是预测未来的负载压力评估当前系统的承载上限再决定什么时候扩容、扩多少。预测思路主要有三类基于历史趋势外推、基于业务目标倒推比如新增活动预计带来多少流量、基于关键事件假设比如大促、年终结算。评估系统承载上限则需要做压测最常见的是用工具模拟高并发流量观察系统在多大并发下出现性能拐点。举个例子你当前集群每台机器能支撑2000 QPS日常总流量是8000 QPS4台机器就能扛住但考虑到某台机器挂掉时需要冗余至少要保留1.5到2倍冗余于是规划为6到8台。这个过程中你还得关注单机瓶颈是CPU、内存还是带宽扩容方向和缩容策略也随之不同。面试中如果能现场写出类似的估算过程会很加分因为这证明你不是只知道“弹性扩容”这个词。2.4 幂等、重试、超时、限流分布式可靠性的基础四件套这四件事在校招面试里会被反复交叉问到因为它们几乎是所有分布式系统稳定性方案的基石。先说幂等核心是“同一个请求执行多次和执行一次效果相同”所以接口设计里要有唯一请求号去重、数据库里要有唯一约束、消息队列消费逻辑要能容忍重复消息。如果你只说“幂等就是重复提交不产生重复数据”面试官通常还会追问“那你觉得幂等可以怎么实现”能答出接口加去重表、数据库唯一键、Redis分布式锁说明真有落地的概念。重试必须配合超时。没有超时的重试是危险的一个下游接口如果长时间不返回重试只会把系统拖死。常见的做法是先设置合理的连接超时和读取超时再配置有限次重试同时配合指数退避加抖动避免所有客户端在同一时间涌入。限流则是保护系统不被突发流量冲垮常见的算法有固定窗口、滑动窗口、漏桶、令牌桶。面试时最好能说清“固定窗口的临界问题”——比如每分钟限100个请求第59秒来了100个第60秒又来了100个实际上一秒内已经突破了限流。这个问题一说出来面试官就知道你不是背的。3. 技能类面试Linux、网络、编程与工具链每一类都有一套固定问法3.1 Linux和系统原理不是背命令是看你会不会用它定位问题Linux是SRE最常接触的战场面试里考察的方式通常很直接给你一个故障场景让你说说用什么命令定位。比如服务变慢了你要能想到用uptime看负载用top看CPU和内存占用最高的进程用vmstat看CPU上下文切换和等待队列用iostat看磁盘IO是否打满再用ss或netstat看连接数状态。这是一个标准的排查链路比单独被问“top命令怎么看”要高级得多。有几个细节我提醒一下。第一top里看出的负载和CPU使用率不是一回事负载是当前正在运行和等待运行的进程数高负载不代表CPU忙也可能是大量D状态不可中断sleep进程阻塞在IO上。第二ss和netstat都能查端口但ss更快信息也更全面试时提一句“一般用ss”显得你跟得上实践。第三查看系统日志用journalctl看内核日志用dmesg看历史登录记录用last。这些命令本身不难但组合起来就代表了你定位问题的效率。另外还有几个高频系统参数值得提前准备文件描述符上限ulimit -n、TCP连接状态重点掌握TIME_WAIT和CLOSE_WAIT的含义、内存分配和Swap的关系、僵尸进程的成因与处理。校招经常考TIME_WAIT因为它直接和连接关闭、大量短连接场景相关。解释清楚TIME_WAIT是主动关闭方在发送完最后一个ACK后进入的状态用来防止旧连接的数据包污染新连接通常等待2MSL约1到4分钟这就算过关。如果再补充一句“高并发短连接场景下会出现大量TIME_WAIT一般从连接复用或调整内核参数两个方向优化”基本可以拿满分了。3.2 网络基础TCP三次握手、DNS解析链路、HTTP状态码SRE每天面对的都是通过网络来访问的复杂系统所以网络基础也是一道必过的门槛。TCP三次握手和四次挥手是基本功不建议只背“三次握手建立连接”这句话而是要知道为什么要三次客户端发送SYN、服务端返回SYNACK、客户端再回ACK这个流程保证了双方都能确认自己和对方的收发能力正常。四次挥手则是由于TCP是全双工的每一方向都需要单独关闭。DNS解析链路也非常重要。从浏览器输入域名到发起请求中途要经过本地DNS缓存、系统hosts文件、Local DNS服务器、根域名服务器、顶级域名服务器、权威域名服务器等环节。SRE在排查“用户反馈网站偶尔打不开”时经常需要顺着DNS这条链路找问题比如某个地域的Local DNS缓存了旧IP或者域名解析出现了轮询异常。校招面试如果能把DNS迭代解析和递归解析的区别讲出来已经是很不错的表达了。HTTP状态码也爱考。大原则是2xx正常、3xx重定向、4xx客户端错误、5xx服务端错误。401和403要分清一个是未认证一个是无权限404表示资源不存在429表示请求太多被限流500是服务端通用错误502是网关收到上游无效响应503是服务不可用504是网关超时。其中SRE最需要重视的是502、503、504因为它们经常指向网关配置、后端实例异常或上游超时。考生如果能主动把状态码和“故障定位方向”联系起来就已经超过了单纯背状态码的同学。3.3 编程能力SRE侧写代码更看重“能用、够稳、能自动化”很多人以为SRE面试的编程题会比开发岗简单其实不然。SRE的核心编程场景是脚本自动化、工具开发、数据处理和分析因此面试中常见的题包括用你熟悉的语言写一个批量日志解析脚本、实现一个简单的限流器、写一个健康检查工具、或者实现一个接口的断点续传。语言方面Python、Go、Shell都比较常见。校招我不建议只准备Shell因为Shell写复杂逻辑时非常容易出bug至少要有Python或Go之一能够熟练使用。编程题层面SRE更看重代码的健壮性。比如让你写一个从日志文件里统计错误数量的脚本你不仅要写得快还要考虑日志文件很大怎么办是逐行读取还是全部读入内存空文件怎么处理编码异常怎么办如果日志格式不统一解析出错时程序会不会直接崩掉这些边界条件其实就是生产环境的真实需求因为SRE写的工具要长期运行在复杂的线上环境中凡是没考虑异常情况的代码上线后大概率成为新的故障源。我建议校招同学在面试前自己动手写一两个小工具练手比如“定时拉取HTTP接口状态并推送到钉钉/企业微信的脚本”“自动清理过期日志的脚本”“扫描所有可用IP端口的小工具”。写完放到自己的GitHub或博客上面试时直接作为一个真实案例讲比背任何八股都管用。这就是“为什么做”“怎么做”“踩了什么坑”的完整闭环面试官特别喜欢听这类真实经历。3.4 工具链考察Docker、K8s、CI/CD、监控组件现在的SRE面试几乎绕不开容器化和自动化运维生态但校招候选人往往只是知道名字没有真正理解它们解决什么问题。Docker最核心的概念是镜像和容器镜像是一个只读模板容器是镜像运行时的实例。面试官喜欢问“镜像和容器的区别”“Dockerfile常见指令”“容器和虚拟机的区别”。你要抓住的本质是容器共享宿主机内核通过命名空间做资源隔离通过cgroups做资源限制所以它比虚拟机更轻、启动更快但隔离性不如虚拟机。Kubernetes的问题通常会围绕基础对象展开Pod、Deployment、Service、Ingress、ConfigMap、Secret。Pod是K8s的最小调度单位Deployment负责管理无状态应用的副本数和滚动更新Service提供稳定的访问入口Ingress负责外部流量的七层转发。面试官常问的一个点Pod挂了K8s是怎么恢复的这就涉及Deployment里的ReplicaSet和Kubelet、apiserver的协作机制能把这个闭环讲清楚说明你真理解了控制器模式。CI/CD一般会问流水线的经典阶段代码提交触发构建、单元测试、镜像打包、推送到镜像仓库、部署到测试环境、自动化测试、灰度发布、全量发布。面试时如果能讲一个自己用GitHub Actions或Jenkins搭过流水线的经历非常加分。监控组件则以Prometheus和Grafana最为常见需要知道Prometheus的数据模型、指标拉取方式Pull vs Push、告警规则配置Grafana负责可视化Alertmanager负责告警路由和通知。4. 实战场景题故障排查、系统设计、应急响应拿到题先别急着开口4.1 故障排查题的标准解从现象到根因的排查链路校招面试的实战题一般不指望你真修好一个线上故障而是看你有没有一套科学的排查思路。我给大家一个可以反复使用的标准思考框架叫做“现象—影响—链路—定位—恢复—复盘”。收到故障反馈后先别慌第一步确认现象是什么服务超时成功率下降延迟升高第二步评估影响范围涉及哪些用户、哪些地域、哪些接口第三步沿着调用链逐步缩小范围第四步定位根因并做临时恢复第五步才是长期修复和复盘。举一个面试真例。面试官问“某核心接口在高峰期P99延迟从50ms涨到2s你怎么办”一个合格的SRE式回答应该是先确认告警级别如果P1就启动应急响应登录监控系统查看延迟曲线和成功率观察是全局限流还是单机抖动接着查应用日志有没有慢SQL、外部依赖是否超时再看底层资源比如CPU、内存、磁盘IO、GC是否异常如果是数据库慢查询先通过索引优化或读写分离恢复后续再分析慢SQL产生的原因。整个过程不要一条道走到黑而要会分层从接入层、应用层、依赖层、存储层四个方向同时排查。这个回答好在哪好在它不是“猜答案”而是“有逻辑地排查”。面试官最怕听到的回答是“我先看一下代码”因为线上问题的第一要务是恢复不管理由是什么先把流量切走、降级、扩容然后再查根因——恢复优先于根因这是SRE和研发在故障处理上最大的思维差异。4.2 系统设计题设计一个高可用架构校招要答到这个程度SRE的校招系统设计题比开发的更多偏向高可用和稳定性常见的有设计一个短链接系统、设计一个接口限流模块、设计一个监控告警系统、设计一个支持百万人同时在线的抢票系统。很多同学一听到“设计”两个字就头大其实校招不需要你设计出完整的大型架构主要考察你有没有架构思维和取舍能力。我建议按ACE原则来回应这类题目Availability可用性、Capacity容量、Elasticity弹性、Efficiency效率。先明确系统SLO可用性要达到几个9再估算容量QPS、数据量、带宽考虑冗余和故障转移方案主从、多副本、多可用区最后再讨论监控和自动化扩缩容。以“设计一个短链接系统”为例你可以说核心功能是长链接转短链、访问跳转、过期管理读多写少所以存储可以选用KV数据库或MySQL加缓存短码生成要保证全局唯一可以用发号器或哈希加冲突检测跳转接口需要高可用至少部署多副本放在负载均衡后面监控要关注短链点击量、跳转成功率、缓存命中率等指标。不需要你做到面面俱到但要说清楚“这个系统有什么风险点、你用什么方案规避、为什么选它”。比如有人一上来就要上Kafka消息队列、上分库分表、上K8s结果连业务场景都没分析——这反而暴露了对技术选型的不解。记住SRE的系统设计题本质上考的是“用最合适的方案达到可靠性目标”而不是“堆尽可能多的新技术”。4.3 应急响应与事后复盘线上一分钟线下基本功应急响应是SRE区别于其他技术岗位的一个标志性场景。面试中会经常给一个突发事故让你推演比如“凌晨两点支付接口成功率为0在线客服电话被打爆你接到告警怎么做”。这类题的考察点不在技术细节而在于你的响应流程、优先级判断和信息同步能力。一个标准的响应流程包含第一步确认影响面有多大比例流量失败、涉及哪些产品第二步止血优先恢复而非定位根因常见止血手段包括回滚最近变更、切流到备用集群、降级非核心功能、限流保护核心链第三步定位根因基于监控、日志、链路追踪分析第四步持续运营恢复后仍需观察一段时间确认稳定第五步写复盘报告。整个过程中还要不断同步进展到相关群用“现状—影响—已采取措施—下一步计划”这样的结构发布消息不夸张、不隐瞒。面试官会观察你是否沉稳、是否能同时做好“技术处理”和“信息同步”两条线。复盘环节也是高频考点。SRE的复盘不是追责大会而是重在改进。常用的方法有5 Whys也就是连续问五个“为什么”直到找到系统层面的根因。比如“为什么支付成功率是0”答案可能是“因为数据库连接池被耗尽”继续问“为什么连接池会耗尽”可能是“有慢SQL长时间占用连接”继续问“为什么有慢SQL”可能是“新发布的索引变更没有覆盖到这张表”继续问“为什么索引变更没覆盖”可能是“发布流程缺少自动审核”。你看追到这一步改进项就变成了“在变更管理里增加自动检查索引覆盖的规则”而不是“开掉那个写SQL的人”。面试时如果你能说出“复盘是为了改进流程而不是追责”绝大概率能戳中面试官的心。5. 校招常见失分点淘汰重灾区都是有迹可循的5.1 背了一堆概念却换算不成实际行动失分最严重的一类就是口号型候选人。一开口就是“我们系统用了微服务、容器化、DevOps”再一追问“你们怎么做容量规划的”答不上来。背概念不是没用但面试官一定会用追问的方式把概念和你可能的实际操作串联起来。这里给你的建议是不要只背“概念的名词解释”每个概念都要准备一个使用场景和一条排查链路。比如学SLO就要想一想“如果线上成功率从99.99%降到99%错误预算消耗了多少我该怎么跟老板汇报”。这才是将知识内化的方式。5.2 东西讲不清边界一谈全是“一把梭”有些候选人基础其实很好但回答问题“无边无际”。面试官问“怎么提高系统可用性”他能从数据库聊到前端CDN从网络聊到机房UPS最后连一个可落地的方案都没有。这种答法在面试里其实很扣分因为SRE非常强调“优先级”和“灰度”不可能同时对全系统动刀。更好的答法是先给结论再说理由按优先级列出改进项。比如“我认为当前系统最大的可用性风险是单点数据库所以第一步要做主从切换第二步是给核心接口加缓存降低数据库压力第三步才是补充自动化巡检和混沌工程验证系统韧性。”这种结构会让面试官觉得你思路清楚、做事有节奏感。5.3 没有量化意识谈SRE就差点意思SRE的本质是“用数据说话”所以量化意识是面试官一定会关注的。我遇到过一个候选人说自己优化了一个接口从“很快”变成“更快了”。我追问“快了具体多少QPS上有什么变化优化前P99是多少优化后是多少”他一问三不知。这就是典型的缺乏量化意识。平时在看技术文章或做项目时建议有意识地记录数字并发量、响应时间、资源使用率、故障时长、自动化覆盖率。面试时说的每一个效果尽量落实到具体数字上可信度完全不一样。5.4 沟通方式会直接影响面试官的评价SRE的沟通能力在面试中不是“加分项”而是“必需品”。我见过不少候选人技术很扎实但一遇到追问就慌了开始绕圈子或者跟面试官争辩“这个场景不可能发生”。这些表现都容易被减分。一个推荐的回应模式是复述确认—分步拆解—清晰输出。面试官问完问题先用自己的话确认一遍“您是想问在XX情况下我应该怎么处理对吗”这既给自己留出思考时间也让对方知道你没有跑偏。然后分条回答用“第一点、第二点、第三点”组织让对方容易跟上你。如果发现自己答错了大方承认并纠正比硬撑着好得多一个懂合作、有复盘能力的人才是SRE团队最需要的人。6. 面试之外校招SRE的长期成长路径写完面试考点我还想多说一点面试之外的东西因为校招面试只是起点入职之后要面对的是真实的复杂系统和不眠夜。如果你正在准备SRE校招我的建议是不要只以“通过面试”为目标而是趁这段时间真正建立一套完整的技术认知体系。具体来说可以按优先级做三件事。第一打好Linux和网络基本功能在服务器上熟练地排查各种问题。第二选择一个方向深入实践比如用Docker和K8s搭一套自己的应用和服务发现然后故意把它弄挂再想办法定位恢复。这个过程比看十篇文章都有效因为故障经验永远是SRE最好的老师。第三系统阅读一些经典资料比如Google SRE前三本书也就是《Site Reliability Engineering》《The Site Reliability Workbook》和《Building Secure and Reliable Systems》不需要逐字读完但里面的核心理念、真实案例和复盘模板对你的思维训练非常有帮助。在我带过的校招新人里成长最快的普遍不是基础最扎实的人而是敢动手、会查文档、能清晰表达问题的那些人。技术可以慢慢积累但这几个习惯越早养成越好。最后分享一个我自己面试常用的压轴问题“如果让你给一个完全不懂技术的朋友解释什么是SRE你会怎么说”这个问题没有标准答案但答得好的人往往才是真正理解了SRE的人。我的版本是SRE就是一群喜欢把复杂系统收拾得井井有条、出了问题能第一时间想办法让它恢复并且能从事故里总结出规律、让系统以后不再犯同样毛病的人。如果你听完这个描述觉得“这说的就是我”那SRE大概率是适合你的方向。