---
name: infra-sre
description: 基础架构与 SRE 怎么面：Linux 与网络排查、容器编排、CI/CD、SLO、故障。运维岗读。
keywords: [sre, devops, 运维, 运维开发, 基础架构, 平台工程, 云原生, cloud, aws, linux, docker, ci/cd, terraform, prometheus, slo]
layer: domain
---

## 面试官在意什么

SRE / 基础架构 / DevOps 岗位的日常是让业务系统"可靠、可观测、可变更、可负担"：维护 Linux 与网络底座、容器与编排平台、CI/CD 流水线、监控告警体系，做容量规划与成本治理，值班处理故障并推动复盘。真实面试里最常被问的不是命令怎么敲，而是"这个现象你怎么查""这个改动怎么安全上线""这个告警为什么误报"。面试官最在意三件事：一是有没有独立处理过真实故障并能复述完整时间线（发现、定位、止血、根因、改进），二是排查思路是否系统（从现象到分层缩小范围，而不是凭经验猜），三是有没有"以工程手段消灭重复劳动"的意识——写脚本、做平台、定 SLO，而不是当人肉工单机。

校招侧重 Linux、网络、操作系统基础与动手能力：进程与文件系统、TCP 握手挥手与常见状态、能写 shell/Python 脚本、理解容器隔离原理；社招侧重工程判断与体系建设：K8s 集群治理、可观测体系设计、SLO 与错误预算、变更管理流程、多云与成本、大规模故障的指挥。国内一线厂近年的 SRE 面试普遍加入"给你一段告警和监控截图现场分析"与"设计一个发布系统"两类题，纯背命令题减少。

怎么问才像这个方向的面试官：
- 每道题从现象切入而不是从概念切入：给一段告警、一组指标或一个用户反馈，要求候选人给排查顺序与验证方法；只会给结论不会给验证的要追问。
- 故障必问且要完整时间线：没有处理过真实故障的候选人不管工具多熟都要标记为经验不足；有故障经历的要追"重来一次最早能在哪缩短恢复"。
- 结合规模出题：管理 10 台机器与 10000 台的问题完全不同，先问清规模，再决定问单机调优还是平台治理。
- 不考命令参数的记忆与特定云厂商的产品名，考的是分层排查思路、止血优先意识与把重复工作工程化的能力。
- 2026 年 SRE 与平台岗的新一轴是 AI 负载：GPU 集群的调度与利用率、训练与推理服务的 SLO、模型调用的 token 延迟与缓存命中当可观测指标、OpenTelemetry 成为默认采集层。候选人没接触过 GPU 负载不扣分，但被问到时要能用同一套可靠性方法推演。

## 项目 / 实习怎么深挖

简历上出现下面这类经历时从哪里切、追什么。追到候选人能说出机制、数字的来源与一次真实的故障或取舍才算实；只有框架名与结论、说不出自己那一段的，记为危险信号。通用的追问方法见 project-deep-dive。

- 简历出现"负责 XX 系统运维" → 追它的规模（节点数、QPS、服务数）、最严重的一次故障与时间线、你做了什么系统性改进
- 简历出现 Kubernetes 集群建设 → 追集群数量与版本、升级过几次、遇到过什么调度或网络问题、request/limit 怎么治理
- 简历出现监控体系 / Prometheus / Grafana → 追指标数量与基数、告警日均多少条、误报率、最有用的一个告警怎么设计的
- 简历出现 CI/CD 平台 → 追服务数、平均发布时长、回滚过几次、灰度怎么判定、有没有出过发布事故
- 简历出现 SLO / 可用性 99.9x% → 追分子分母定义、怎么采集、有没有因为预算耗尽拒绝过发布
- 简历出现降本 X 万 / X% → 追怎么找到浪费、动了哪些资源、有没有引发可靠性问题、业务方怎么配合
- 简历出现 Terraform / Ansible → 追覆盖范围、state 管理、漂移怎么处理、出过误删吗
- 简历出现"值班 / on-call" → 追值班频率、最长一次故障、有没有推动过告警治理或 runbook

## 常见失守与危险信号

- Linux 系统排查：只会 top；不知道 D 状态进程；把 buffer/cache 当内存泄漏；不知道 OOM killer 的选择逻辑
- 网络与 TCP/HTTP 排查：CLOSE_WAIT 大量堆积说不出是应用没关连接；把 TIME_WAIT 当故障并只会调 tw_reuse；不会 tcpdump/ss
- 容器原理与镜像治理：认为 Docker 就是轻量虚拟机；不知道 cgroup v1/v2 差异；镜像用 latest 且无扫描
- CI/CD 与发布系统：发布靠脚本手工执行；不知道制品与源码版本的绑定；没有回滚演练过
- 监控指标与告警设计：CPU 超 80% 就告警；不知道 label 基数会打爆 Prometheus；告警没有 runbook
- SLO、错误预算与可靠性工程：SLO 就是"99.9%"却说不出分子分母；把基础设施指标当 SLI；SLO 只写在文档里不驱动任何决策
- 故障响应与复盘：讲不出时间线；"重启就好了"没有根因；复盘只有人的失误没有系统改进
- 变更管理与安全生产：所有变更一个流程；配置改动不算变更；没有变更与告警的关联视图

## 常考主题清单

只列名字、阶梯与答实的标志，作"问到哪一层算实"的参考；问哪些、问几道由这份 JD 与这份简历定，不是配额。

### Linux 系统排查
- 阶梯：load、CPU、内存、IO 各看什么命令 → load 高但 CPU 不高意味着什么、内存"用满"与 cache 的区别、iowait 与 steal 的含义 → 机器偶发卡顿、进程 OOM 被杀、磁盘满但 df 与 du 对不上，怎么定位 → 单机调优（内核参数、ulimit、cgroup）的收益边界与何时该换架构
- 答实的标志：区分 R/D 状态与 iowait；用 vmstat/iostat/pidstat 分层；会看 dmesg 与 cgroup 内存限制；能提到文件被删但句柄未释放导致空间不回收

### 网络与 TCP/HTTP 排查
- 阶梯：三次握手四次挥手、TIME_WAIT 与 CLOSE_WAIT 各出现在哪一侧 → 连接池、keepalive、backlog、conntrack 表的作用 → 服务间偶发超时/连接重置、DNS 解析慢、跨机房丢包怎么分层定位 → 调 TCP 参数、加代理层、改重试策略的取舍与副作用
- 答实的标志：ss 看状态分布并归因到哪一侧；LB 空闲超时与应用 keepalive 不匹配的经典案例；conntrack 满、backlog 溢出的判断；DNS 缓存与 ndots 问题

### 容器原理与镜像治理
- 阶梯：容器和虚拟机差别 → namespace、cgroup、overlay 文件系统、镜像分层 → 容器内 OOM 但宿主机内存充足、容器里看到的 CPU 核数与限制不符、镜像拉取慢 → 镜像瘦身、基础镜像统一、漏洞扫描与镜像仓库治理的成本收益
- 答实的标志：容器内存包含堆外、metaspace、线程栈与 page cache；JVM 感知容器限制的参数；多阶段构建与非 root 运行；镜像签名或扫描接入流水线

### CI/CD 与发布系统
- 阶梯：CI 和 CD 的区别、流水线阶段 → 构建缓存、制品管理、环境隔离、密钥注入 → 流水线偶发失败、构建越来越慢、发布后回滚不了，怎么治理 → 灰度、蓝绿、金丝雀各自代价与适用场景，发布系统平台化的投入产出
- 答实的标志：不可变制品、一次构建多处部署；发布与迁移分离并向前兼容；金丝雀指标自动判定；紧急变更也留痕

### 监控指标与告警设计
- 阶梯：指标、日志、trace 分别回答什么问题 → Prometheus 数据模型、四个黄金信号、RED/USE 方法、聚合与基数 → 告警太多没人看、告警来了但定位不到、指标基数爆炸拖垮监控系统，怎么治 → 告警按症状还是按原因、阈值告警与异常检测、谁被叫醒的取舍
- 答实的标志：按用户可感知症状（错误率、延迟）告警；告警带处理指引与自动降噪；有 SLO 燃烧率告警；用"告警后是否需要动作"做删减标准

### SLO、错误预算与可靠性工程
- 阶梯：SLI/SLO/SLA 的区别 → 怎么选 SLI、多少个九怎么定、错误预算怎么算 → SLO 一直达标但用户投诉、SLO 定得业务方不认，怎么办 → 错误预算耗尽时冻结发布的执行阻力，可靠性投入与业务迭代速度的谈判
- 答实的标志：SLI 从用户视角定义（成功率、延迟分位数）；有燃烧率告警；错误预算用于发布节奏决策；知道 SLO 需要迭代

### 故障响应与复盘
- 阶梯：接到告警第一步做什么 → 止血优先于根因、指挥与沟通角色、时间线记录 → 多个团队互相甩锅、根因藏在变更里没人承认、故障反复发生，怎么推动 → 无责复盘的文化建设与行动项落地的跟踪
- 答实的标志：MTTD/MTTR 有数字；止血动作（回滚、扩容、降级、切流）优先级清晰；复盘产出可验证的改进项；对"变更是故障主因"有数据感

### 变更管理与安全生产
- 阶梯：为什么大部分故障来自变更 → 变更分级、审批、窗口、可回滚性 → 紧急修复跳过流程出了事、配置中心一键推全量导致雪崩，怎么防 → 流程严格度与交付速度的平衡，自动化守门与人工审批的边界
- 答实的标志：变更风险分级；配置也走灰度与校验；变更事件打到监控时间轴；自动化检查替代大部分人审