SRE 面试考什么 2026：系统设计、故障排查、可靠性工程

💡 核心要点 (Key Takeaways)

• 2026 年 SRE 面试考的是四个能力支柱：Coding/Scripting、Troubleshooting（故障排查）、可靠性 System Design、Incident 响应与 on-call 文化；其中 Troubleshooting 是最有特色、也是候选人准备最少的轮次。
• SRE 的 coding 标准接近 SWE 而非纯运维——DevOps / sysadmin 转 SRE 最容易被 coding screen 卡住，「SRE 就是 bash + Terraform」是最常见的误判。
• 最容易挂的不是背不出 SRE 术语，而是：排查先猜根因不读信号、设计不报 SLO 和 error budget、on-call 故事没有检测/诊断/缓解/影响范围四个数字。
• 面试官打分看四件事：SLI/SLO/error budget 的决策能力、排查是否结构化（先 scope 后根因）、设计是否主动交代失败路径与降级、行为轮 blameless 语气与具体产出。
• 7 / 14 / 30 天三档路线：7 天保排查结构和事件故事下限，14 天补可靠性设计与 SLO 数字，30 天加 NALSD 级约束题、内核级 Linux 和两场完整混合 mock。

这篇适合谁

这篇写给准备北美 Site Reliability Engineer（SRE）面试、但还没搞清楚「每一轮到底考什么」的候选人——New Grad、社招（L4/L5，对标国内 3-5 年经验的中级），以及从 SWE、DevOps、平台/基础设施工程师转 SRE 的人。和单公司面经不同，这篇文章不深挖某一家的题库，而是直接回答准备期最核心的问题：SRE 面试考什么。它给出一张全轮次地图：每一轮考什么、哪些题型高频、候选人在哪里最容易丢分、按你的倒计时该投入多少准备。

一句话定位：2026 年 SRE 面试考四大能力支柱——Coding / Scripting、Troubleshooting（故障排查）、可靠性 System Design、Incident 响应与 on-call 文化。其中 Troubleshooting 是 SRE 最有特色、也是候选人准备最少的一轮；而很多候选人低估的是，SRE 的 coding 标准其实接近 SWE，不是「会 bash + Terraform 就行」。轮次结构基于 2026 年公开面经信号聚合和站内 SWE 专题整理，因公司、级别、地区会有出入，以你实际收到的邀请为准。读完你能带走四样东西：① 全流程轮次地图；② 五大能力方向的高频题与可执行动作；③ 最容易踩的 6 个挂点；④ 7 / 14 / 30 天三档准备路线。更完整的 SWE 岗位策略与轮次对比见 SWE 岗位解构。

整体框架：SRE 面试每一轮考什么

先给结论：2026 年 SRE 面试的主轴是「SWE 级 coding + 一轮以故障为中心的设计 + 一轮纯故障排查 + 一轮 on-call 行为」，典型 4-6 个阶段，FAANG 常到 5-7 轮，小公司压缩到 3-4 轮。典型流程长这样：

• 简历投递 / Recruiter Screen（20-30 分钟）：考察 SLI / SLO / toil / postmortem 词汇的熟练度，以及你为什么想搞可靠性而不是写 feature。投递到第一轮反馈的典型区间是 1-3 周。
• Coding / Scripting Screen（约 45 分钟）：1 道接近 LeetCode-medium 的算法题，或一道偏生产系统的 scripting 题（解析日志、流式处理、并发健康检查）。考的不是高难度算法，而是代码能不能扛住「脏输入 + 规模放大 + 中途加约束」。
• Linux / 网络基础轮（45-60 分钟，部分公司并入下一轮）：进程、内存、I/O、调度、网络栈、一个端到端追踪题（如「一个 URL 从输入到返回发生了什么」）。考的是机制理解，不是命令背诵。
• Troubleshooting（45-60 分钟，SRE 最特色的一轮）：一个模拟生产故障（延迟上升、错误率飙升、部署后部分区域 500），在共享文档里写你打算跑的命令和假设，面试官逐步给输出。核心考「先止血、后诊断」的执行顺序，而不是找到根因本身。
• 可靠性 System Design / Design under Failure（60-75 分钟）：设计一个服务，然后面试官不断注入失败（依赖挂掉、流量翻倍、某区域宕机）。考 SLO 定义、error budget 决策、容量估算、降级与过载行为、可观测性。Google 风格会额外要求 NAP（物理量）估算。
• Incident / 行为轮（30-60 分钟）：讲一个你主导或参与的事故，或现场给你「凌晨 2 点被 page」的场景。考 blameless 语气、incident command 角色分工、以及事后系统性的改进（不是「加了个告警」）。
• HM / Team Match / Hiring Committee：VO 通过后不再考技术，双向确认团队方向、level、on-call 强度和 location。整个流程从投递到 offer 的典型区间是 4-6 周。

高频题型与核心方法：6 个方向，每个都有可执行动作

按能力方向拆开讲。每个方向都给一个今天就能开始的动作，不泛泛而谈：

• Coding / Scripting（标准接近 SWE，别掉以轻心）：SRE coding 不追求 LeetCode-hard，但标准不低于 SWE，高频是流式 / 日志解析、并发健康检查、token bucket 限流、脏输入处理。动作：每周 2-3 题，每题强制处理三类边界（空输入、超大输入、格式损坏），并且能一句话说清「这题在生产里为什么会出现」。
• 流式 / 日志解析题（coding 轮最高频）：「解析一个 10GB 的服务日志流，每 5 分钟输出 top N 失败端点」。考点是流式数据结构（不能用全量加载）、内存受限、malformed 行容错、滚动窗口。动作：手写一个能边读边输出、且对坏行不崩的版本，并说出时间和空间复杂度。
• 可靠性 System Design（社招必考，60-75 分钟）：高频是「多区域通知服务 99.95% 送达」「设计可观测性栈」「部署系统如何支持一天 50 次安全发布」。动作：按「SLI → SLO → error budget → 容量估算 → 核心架构 → 失败模式 → 降级 → 监控」推进，规模、降级、冷启动要主动交代；通用八步框架见 SWE System Design 专题。
• Troubleshooting（最特色、最易被低估）：固定顺序：先定影响范围（哪些用户 / 区域 / 端点 / 分位）→ 形成假设 → 用信号验证 → 止血（回滚 / 切流 / 关 flag）→ 再查根因 → 验证恢复。动作：把这套顺序练到条件反射，每次排查口述「我现在的假设是 X，用什么证据能证伪它」。
• Linux / 网络基础（机制优先）：D 态进程、OOMKilled 但堆没泄漏、conntrack 表在 SYN flood 下的行为、DNS / TCP / 内核栈追踪。动作：挑 3-5 个高频内核机制，每个能讲清「为什么会这样、用什么命令确认、坏情况怎么办」，而不是背命令。
• Incident / on-call 行为故事：按 4 个高频方向准备（主导过的一次事故、一次主动降低 toil 的自动化、一次可靠性 vs 速度的取舍、一次没跑好的 on-call 轮值）。动作：每个故事带 4 个数字——检测时间、诊断时间、缓解时间、影响范围，并讲清事后系统性的改进。

代表题型：2026 信号里反复出现的 4 类

以下是 2026 年公开面经信号里反复出现的题「类型」，只归纳题型和考点，不复刻任何人的具体原题：

• Incident 模拟排查（最高频）：「checkout 延迟翻倍，但全局错误率不变」「某区域 500，其他区域正常」。考点是先 scope（端点 / 区域 / 版本 / 分位）、再假设、再止血，而不是上来就翻 commit 历史找根因。典型 follow-up：「怎么确认告警是真的」「缓解动作的回滚条件是什么」。
• 可靠性系统设计（社招最高频）：「设计一个多区域通知服务，99.95% 送达 SLO」「设计可观测性栈」「设计支持一天 50 次发布的安全部署系统」。考点是容量、持久化、重试与去重、可观测性、降级模式，以及 NAP 物理量估算（例如 5PB 数据迁移在 10Gbps 链路上要 46 天，先做 napkin math 再画架构图）。
• SLO / Error Budget 决策题：「你的服务 SLO 是 99.9%，月中已经烧掉 80% 的 error budget，怎么办」。强答案直接给决策：冻结非关键发布、把烧预算的 incident 拉出来复盘、收紧放它跑了 20 分钟的告警、跟产品谈下个 feature 这周发还是等。弱答案开始解释 error budget 是什么。
• 流式 / 自动化题（coding 轮）：「解析 10GB 日志输出 top N 失败端点」「实现一个带突发处理的 token bucket」「并行检查 10 万台服务器健康，限制并发」。考点是流式数据结构、并发安全、脏输入容错、内存受限下的正确性。
• Linux 内核级排查（SRE 与 DevOps 的分水岭）：「进程 D 态是什么含义」「Pod 被 OOMKilled 但堆 profile 没有泄漏」「SYN flood 时 conntrack 表会怎样」。考点是机制理解 + 用什么命令确认，答不出机制就露馅。

常见挂点：中国 / 海外候选人最易失分的 6 个地方

把公开挂因信号和模拟面试复盘对照，SRE 面试的失分点集中在这 6 个：

• 闷头排查只交结论：中国候选人最典型的挂法。在共享文档里只写命令和结果，不写假设和排除过程，面试官听不到推理，代码/结论对了也给不到对应 level 的分。对策：每 5 分钟主动交代一次「我现在的假设、用什么证据验证、排除了什么」。
• 设计不报 SLO 和 error budget：上来就画架构图，不先定义用户可见的 SLI 和目标值。被追问「这个服务需要几个 nine」答不上来，基本等于告诉面试官你没真正做过可靠性工作。对策：每个设计先从用户可见的 SLI 出发，让每个 nine 都有真实预算成本（99.9% 月度约 43 分钟 downtime，99.99% 约 4 分钟）。
• on-call 故事太笼统：「我负责 on-call，响应 page 并修复问题」——面试官无法给你定位。要有 4 个数字：检测时间、诊断时间、缓解时间、影响范围。对策：把 3-4 个故事各配 4 个数字，哪怕是测试环境的大 outage 也行。
• 低估 SRE coding 难度：DevOps / sysadmin 转 SRE 最常被 coding screen 过滤，因为他们假设 SRE = bash + Terraform。SRE 的 coding 标准接近 SWE，要刷 LeetCode-medium 4 周以上，重点放在哈希、图、流式。
• SRE 词汇堆砌、追问即露馅：能背出 SLI/SLO/error budget/postmortem 的定义，被追问「为什么这么选这个 SLI」「坏情况怎么办」就散。考的是约束下的决策，不是术语表。
• 排查先猜根因：没看指标、日志、最近变更就直接说「肯定是数据库」，面试官会认为你真实 on-call 时浪费时间追错方向。高级模式是先看最明显的信号（部署、dashboard、错误率按端点），再收敛。

准备路线：7 天 / 14 天 / 30 天

按你距第一轮技术面的天数选路线。三个版本的共同原则：Troubleshooting 和 Incident 故事永远优先，可靠性 System Design 次之（社招必补），Coding 保 SWE 下限，最后两天只留 mock 和状态调整，不学新东西。

• 7 天（保下限版）：D1-D2 把排查固定顺序（scope → 假设 → 测试 → 止血 → 根因 → 验证）练成条件反射 + 做 2 道流式日志解析题；D3-D4 做 1 道 Linux 内核机制题 + 1 道 incident 模拟（口述录音回听）；D5-D6 写 3 个 on-call / incident 的 STAR 故事，每个带 4 个数字，英文口述录音；D7 完整 mock 一次（Troubleshooting 45 分钟 + Incident 10 分钟），录音复盘。这个版本只保下限：排查不跳步、故事不笼统。
• 14 天（标准版）：在 7 天基础上——D8-D10 补可靠性 System Design：按「SLI → SLO → error budget → 容量 → 架构 → 失败 → 降级 → 监控」做 2 道题（多区域通知服务、安全部署系统），每道练到能完整讲 45-60 分钟；D11-D12 把 D1-D2 的流式题重做一遍，这次强制自己第一版就写可扩展结构；D13 mock 一场完整 Onsite（Coding + Troubleshooting + 设计 + Incident 各一段）；D14 缓冲日，检查设备日程，早睡。
• 30 天（系统版）：在 14 天基础上——D15-D20 专项 NAP 与内核：做 2 道 NALSD 级约束题（带物理量估算）+ 2 道 Linux 内核级排查（D 态、OOMKilled、conntrack）；D21-D24 SLO / error budget 决策专项：把 5 个「预算已烧 N%，怎么办」的场景各写一版决策；D25-D26 on-call 故事库扩充到 6-8 个，练三层追问（approach → 细节 → reflection）；D27-D28 连续两场完整混合 mock，重点看排查顺序、SLO 决策、表达节奏；D29 复盘两场 mock，把断片点写下来各补一段；D30 缓冲日。

FAQ：SRE 面试考什么，5 个高频问题

Q1：SRE 面试一般几轮，流程走多久？
典型 4-6 个阶段：Recruiter Screen、Coding/Scripting、Linux/网络、Troubleshooting、可靠性 System Design、Incident 行为 / HM。FAANG 常到 5-7 轮，小公司压缩到 3-4 轮。从投递到 offer 的典型区间是 4-6 周，不同公司差异很大——快的三周，慢的要两个月，用区间做心理预期，不要用任何单篇面经的时间点当标准。

Q2：SRE 面试和 SWE 面试有什么区别？
主轴都是 coding + system design，但 SRE 的 coding 偏并发 / 流式 / 日志解析（标准接近 SWE，不是纯运维）；system design 是可靠性向的（SLO、error budget、失败模式、降级）；还多一轮纯 Troubleshooting 和 on-call 行为轮。更细的 SWE 轮次对比见 SWE 岗位解构。

Q3：SRE 面试要刷 LeetCode 吗？
要，但标准比 SWE 略低、方向更偏生产。重点是哈希、图、流式、并发，medium 为主。DevOps / sysadmin 转 SRE 最容易被 coding screen 卡住，别假设 SRE 就是 bash + Terraform，至少刷 4 周 medium。

Q4：SLO 和 error budget 到底怎么算？
SLI 是用户可观测的测量（如「p99 延迟 < 300ms 的请求占比」），SLO 是目标值（如 99.9%），error budget = 1 - SLO。99.9% 月度可用性约等于 43 分钟 downtime，99.95% 约 22 分钟，99.99% 约 4 分钟——每个 nine 的维护成本指数级上升。面试官想听你说明「一个没人半夜 page 的内部服务不需要 4 个 nine」，而不是背定义。

Q5：我没跑过 on-call，怎么准备 Incident 行为轮？
用最接近的真实例子：一次生产 bug、一次失败的发布、一次数据问题、一次测试环境的大 outage。坦白你的角色，然后讲清你如何改进检测、缓解、协作和预防。如果完全没有，搭一个本地 Prometheus + Grafana 的玩具栈、设一个 SLO、故意打破它、记录 p99 告警多久触发——一个下午比背任何一章都更能建立「p99 告警是什么感觉」的直觉，也给你一个真实可讲的故事。