infra-sre git:20260919.2ea5304A

Immutable. This exact content never changes and is served at /api/v1/blob/528f9a50fdcbd4c2.

---
name: infra-sre
description: 基础架构 / SRE / DevOps / 云怎么面：Linux 与网络排查、容器与编排、CI/CD、监控告警与 SLO、容量与成本、故障响应与变更管理。岗位或简历出现 SRE、运维开发、DevOps、平台工程、云原生、基础架构时加载。
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 台的问题完全不同，先问清规模，再决定问单机调优还是平台治理。
- 不考命令参数的记忆与特定云厂商的产品名，考的是分层排查思路、止血优先意识与把重复工作工程化的能力。

## 项目 / 实习怎么深挖

简历上出现下面这类经历时从哪里切、追什么。追到候选人能说出机制、数字的来源与一次真实的故障或取舍才算实；只有框架名与结论、说不出自己那一段的，记为危险信号。通用的追问方法见 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 且无扫描
- 编排平台运维（Kubernetes 视角）：只会 kubectl get pods；不知道 request 与 limit 影响调度和 QoS；探针配置照抄
- CI/CD 与发布系统：发布靠脚本手工执行；不知道制品与源码版本的绑定；没有回滚演练过
- 基础设施即代码与配置管理：手工改控制台再补代码；state 放本地；不看 plan 就 apply
- 监控指标与告警设计：CPU 超 80% 就告警；不知道 label 基数会打爆 Prometheus；告警没有 runbook
- SLO、错误预算与可靠性工程：SLO 就是"99.9%"却说不出分子分母；把基础设施指标当 SLI；SLO 只写在文档里不驱动任何决策
- 故障响应与复盘：讲不出时间线；"重启就好了"没有根因；复盘只有人的失误没有系统改进
- 容量规划与成本治理：容量靠拍脑袋；不知道 request 与实际用量的差距；降本只想到关机器
- 变更管理与安全生产：所有变更一个流程；配置改动不算变更；没有变更与告警的关联视图
- 高可用与灾备架构：高可用就是"多部署几个副本"；从未做过故障演练；RPO/RTO 说不出数字
- 自动化与平台化思维：以工单量为荣；脚本不进版本控制；自动化没有 dry-run 与审计

## 常考主题清单

只列名字、阶梯与答实的标志，作"问到哪一层算实"的参考；问哪些、问几道由这份 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 运行；镜像签名或扫描接入流水线

### 编排平台运维（Kubernetes 视角）
- 阶梯：Pod、Deployment、Service 分别解决什么 → 调度、探针、资源 request/limit、HPA 的机制 → Pod Pending/CrashLoopBackOff/Evicted 各怎么查、节点 NotReady 怎么处理 → 集群规模、多集群、升级策略与平台自治程度的取舍（细节交给 infra-k8s 包）
- 答实的标志：先回滚再排查的止血意识；describe 看事件、按节点/版本对比；探针与优雅退出的配合；对集群升级的风险有认识

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

### 基础设施即代码与配置管理
- 阶梯：为什么要 IaC → Terraform 状态文件、plan/apply、模块化，Ansible 幂等性 → 状态漂移、并发 apply 冲突、误删资源怎么防与恢复 → IaC 覆盖范围（全部还是核心）、平台团队与业务团队的权限边界
- 答实的标志：远程 state 加锁；lifecycle 保护关键资源；plan 进 PR 审核；漂移检测定期跑

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

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

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

### 容量规划与成本治理
- 阶梯：怎么知道该扩容了 → 压测方法、水位线、峰值预估、弹性伸缩 → 资源利用率只有 15% 但业务喊不够、云账单月涨 30% 没人说得清，怎么查 → 预留与按需、超卖、混部的风险收益，成本责任怎么分摊到业务
- 答实的标志：按服务维度的用量/申请比；VPA 或推荐值治理；错峰与弹性；成本可视化到团队并有考核

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

### 高可用与灾备架构
- 阶梯：单点在哪 → 多可用区、多活与主备、数据复制的一致性 → 一个可用区挂了业务却全挂、切换演练从没成功过，怎么整改 → 多活的成本与复杂度，RPO/RTO 目标怎么与业务对齐
- 答实的标志：依赖梳理与单点清单；定期演练（混沌工程）；数据层切换的一致性代价；按业务重要性分级的灾备目标

### 自动化与平台化思维
- 阶梯：哪些重复工作该自动化 → 脚本、工具、平台的演进路径 → 自动化脚本本身成为故障源、平台没人用，怎么办 → 平台工程的边界：自助服务与安全约束，做多少抽象合适
- 答实的标志：按频率与风险排序自动化；自助带护栏与审计；用工单减少量和 lead time 衡量；能说出一次"自动化闯祸"的教训