---
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 面试普遍加入"给你一段告警和监控截图现场分析"与"设计一个发布系统"两类题，纯背命令题减少。

## 主题

### Linux 系统排查
- 阶梯：load、CPU、内存、IO 各看什么命令 → load 高但 CPU 不高意味着什么、内存"用满"与 cache 的区别、iowait 与 steal 的含义 → 机器偶发卡顿、进程 OOM 被杀、磁盘满但 df 与 du 对不上，怎么定位 → 单机调优（内核参数、ulimit、cgroup）的收益边界与何时该换架构
- 好题：一台应用机 load 30 但 CPU 使用率只有 20%，业务报慢。你按什么顺序看？可能的原因至少三种，各自怎么验证？
- 危险信号：只会 top；不知道 D 状态进程；把 buffer/cache 当内存泄漏；不知道 OOM killer 的选择逻辑
- 期望信号：区分 R/D 状态与 iowait；用 vmstat/iostat/pidstat 分层；会看 dmesg 与 cgroup 内存限制；能提到文件被删但句柄未释放导致空间不回收

### 网络与 TCP/HTTP 排查
- 阶梯：三次握手四次挥手、TIME_WAIT 与 CLOSE_WAIT 各出现在哪一侧 → 连接池、keepalive、backlog、conntrack 表的作用 → 服务间偶发超时/连接重置、DNS 解析慢、跨机房丢包怎么分层定位 → 调 TCP 参数、加代理层、改重试策略的取舍与副作用
- 好题：服务 A 调服务 B 每分钟有几次 "connection reset by peer"，两边 CPU 都不高。你怎么定位是客户端、网络、负载均衡还是服务端的问题？需要抓包时在哪抓、看什么？
- 危险信号：CLOSE_WAIT 大量堆积说不出是应用没关连接；把 TIME_WAIT 当故障并只会调 tw_reuse；不会 tcpdump/ss
- 期望信号：ss 看状态分布并归因到哪一侧；LB 空闲超时与应用 keepalive 不匹配的经典案例；conntrack 满、backlog 溢出的判断；DNS 缓存与 ndots 问题

### 容器原理与镜像治理
- 阶梯：容器和虚拟机差别 → namespace、cgroup、overlay 文件系统、镜像分层 → 容器内 OOM 但宿主机内存充足、容器里看到的 CPU 核数与限制不符、镜像拉取慢 → 镜像瘦身、基础镜像统一、漏洞扫描与镜像仓库治理的成本收益
- 好题：Java 服务容器化后频繁被 OOMKilled，但 JVM 堆设置远小于容器限制。可能原因有哪些？怎么用 cgroup 与 JVM 参数验证和修复？
- 危险信号：认为 Docker 就是轻量虚拟机；不知道 cgroup v1/v2 差异；镜像用 latest 且无扫描
- 期望信号：容器内存包含堆外、metaspace、线程栈与 page cache；JVM 感知容器限制的参数；多阶段构建与非 root 运行；镜像签名或扫描接入流水线

### 编排平台运维（Kubernetes 视角）
- 阶梯：Pod、Deployment、Service 分别解决什么 → 调度、探针、资源 request/limit、HPA 的机制 → Pod Pending/CrashLoopBackOff/Evicted 各怎么查、节点 NotReady 怎么处理 → 集群规模、多集群、升级策略与平台自治程度的取舍（细节交给 infra-k8s 包）
- 好题：一次发布后一半 Pod 在 CrashLoopBackOff，另一半正常，日志看不出差别。你怀疑哪些差异（节点、镜像、配置、依赖）？怎么快速止血再定位？
- 危险信号：只会 kubectl get pods；不知道 request 与 limit 影响调度和 QoS；探针配置照抄
- 期望信号：先回滚再排查的止血意识；describe 看事件、按节点/版本对比；探针与优雅退出的配合；对集群升级的风险有认识

### CI/CD 与发布系统
- 阶梯：CI 和 CD 的区别、流水线阶段 → 构建缓存、制品管理、环境隔离、密钥注入 → 流水线偶发失败、构建越来越慢、发布后回滚不了，怎么治理 → 灰度、蓝绿、金丝雀各自代价与适用场景，发布系统平台化的投入产出
- 好题：设计一个面向 200 个服务的发布系统：分批、健康检查、自动回滚、审批与紧急通道各怎么做？一次发布把数据库 schema 改坏了，回滚流程会遇到什么？
- 危险信号：发布靠脚本手工执行；不知道制品与源码版本的绑定；没有回滚演练过
- 期望信号：不可变制品、一次构建多处部署；发布与迁移分离并向前兼容；金丝雀指标自动判定；紧急变更也留痕

### 基础设施即代码与配置管理
- 阶梯：为什么要 IaC → Terraform 状态文件、plan/apply、模块化，Ansible 幂等性 → 状态漂移、并发 apply 冲突、误删资源怎么防与恢复 → IaC 覆盖范围（全部还是核心）、平台团队与业务团队的权限边界
- 好题：Terraform plan 显示要销毁并重建一个生产数据库实例，只是因为改了一个标签。你怎么处理？怎么从流程上防止这类误操作到达 apply？
- 危险信号：手工改控制台再补代码；state 放本地；不看 plan 就 apply
- 期望信号：远程 state 加锁；lifecycle 保护关键资源；plan 进 PR 审核；漂移检测定期跑

### 监控指标与告警设计
- 阶梯：指标、日志、trace 分别回答什么问题 → Prometheus 数据模型、四个黄金信号、RED/USE 方法、聚合与基数 → 告警太多没人看、告警来了但定位不到、指标基数爆炸拖垮监控系统，怎么治 → 告警按症状还是按原因、阈值告警与异常检测、谁被叫醒的取舍
- 好题：你们的告警一天几百条，值班同学已经麻木。给出一个治理方案：怎么分级、怎么合并、哪些该删、怎么衡量治理效果？
- 危险信号：CPU 超 80% 就告警；不知道 label 基数会打爆 Prometheus；告警没有 runbook
- 期望信号：按用户可感知症状（错误率、延迟）告警；告警带处理指引与自动降噪；有 SLO 燃烧率告警；用"告警后是否需要动作"做删减标准

### SLO、错误预算与可靠性工程
- 阶梯：SLI/SLO/SLA 的区别 → 怎么选 SLI、多少个九怎么定、错误预算怎么算 → SLO 一直达标但用户投诉、SLO 定得业务方不认，怎么办 → 错误预算耗尽时冻结发布的执行阻力，可靠性投入与业务迭代速度的谈判
- 好题：给一个支付网关定 SLO：选哪些 SLI、怎么采集、阈值怎么和业务方对齐？预算烧完了但业务要上大促功能，你怎么处理？
- 危险信号：SLO 就是"99.9%"却说不出分子分母；把基础设施指标当 SLI；SLO 只写在文档里不驱动任何决策
- 期望信号：SLI 从用户视角定义（成功率、延迟分位数）；有燃烧率告警；错误预算用于发布节奏决策；知道 SLO 需要迭代

### 故障响应与复盘
- 阶梯：接到告警第一步做什么 → 止血优先于根因、指挥与沟通角色、时间线记录 → 多个团队互相甩锅、根因藏在变更里没人承认、故障反复发生，怎么推动 → 无责复盘的文化建设与行动项落地的跟踪
- 好题：复述你处理过最严重的一次故障：发现方式、多久止血、怎么做的决策、根因、改进项落地了没有。如果当时重来一次，最早能在哪一步缩短恢复时间？
- 危险信号：讲不出时间线；"重启就好了"没有根因；复盘只有人的失误没有系统改进
- 期望信号：MTTD/MTTR 有数字；止血动作（回滚、扩容、降级、切流）优先级清晰；复盘产出可验证的改进项；对"变更是故障主因"有数据感

### 容量规划与成本治理
- 阶梯：怎么知道该扩容了 → 压测方法、水位线、峰值预估、弹性伸缩 → 资源利用率只有 15% 但业务喊不够、云账单月涨 30% 没人说得清，怎么查 → 预留与按需、超卖、混部的风险收益，成本责任怎么分摊到业务
- 好题：集群整体 CPU 利用率 15%，业务还在申请资源。你怎么找到浪费在哪（request 虚高、僵尸服务、非高峰空转）？给出三个降本手段并说明各自的可靠性风险。
- 危险信号：容量靠拍脑袋；不知道 request 与实际用量的差距；降本只想到关机器
- 期望信号：按服务维度的用量/申请比；VPA 或推荐值治理；错峰与弹性；成本可视化到团队并有考核

### 变更管理与安全生产
- 阶梯：为什么大部分故障来自变更 → 变更分级、审批、窗口、可回滚性 → 紧急修复跳过流程出了事、配置中心一键推全量导致雪崩，怎么防 → 流程严格度与交付速度的平衡，自动化守门与人工审批的边界
- 好题：设计一个变更管理体系：什么变更需要审批、什么可以自动过、配置变更怎么灰度、怎么保证任何变更都能在五分钟内回滚？
- 危险信号：所有变更一个流程；配置改动不算变更；没有变更与告警的关联视图
- 期望信号：变更风险分级；配置也走灰度与校验；变更事件打到监控时间轴；自动化检查替代大部分人审

### 高可用与灾备架构
- 阶梯：单点在哪 → 多可用区、多活与主备、数据复制的一致性 → 一个可用区挂了业务却全挂、切换演练从没成功过，怎么整改 → 多活的成本与复杂度，RPO/RTO 目标怎么与业务对齐
- 好题：你们标称"双可用区高可用"，一次机房网络抖动却导致全站不可用。请列出可能的隐藏单点（DNS、配置中心、注册中心、数据库主库、依赖的第三方），怎么系统性找出来并验证？
- 危险信号：高可用就是"多部署几个副本"；从未做过故障演练；RPO/RTO 说不出数字
- 期望信号：依赖梳理与单点清单；定期演练（混沌工程）；数据层切换的一致性代价；按业务重要性分级的灾备目标

### 自动化与平台化思维
- 阶梯：哪些重复工作该自动化 → 脚本、工具、平台的演进路径 → 自动化脚本本身成为故障源、平台没人用，怎么办 → 平台工程的边界：自助服务与安全约束，做多少抽象合适
- 好题：业务团队每周提几十个"申请资源、加配置、查日志"的工单。你会怎么把它们变成自助服务？先做哪个、怎么衡量成功、怎么防止自助变成失控？
- 危险信号：以工单量为荣；脚本不进版本控制；自动化没有 dry-run 与审计
- 期望信号：按频率与风险排序自动化；自助带护栏与审计；用工单减少量和 lead time 衡量；能说出一次"自动化闯祸"的教训

## 好题 / 坏题对比

- 坏：Linux 里怎么看 CPU 和内存？
- 好：一台机器 load 30 但 CPU 只用了 20%，业务报慢，你按什么顺序看？说出至少三种可能原因以及各自怎么验证。如果发现是 D 状态进程堆积，下一步怎么查？

- 坏：什么是 SLO？和 SLA 有什么区别？
- 好：给支付网关定 SLO：你选哪些 SLI、数据从哪采、阈值怎么和业务对齐？错误预算烧完了但业务要在大促前上新功能，你怎么处理？

- 坏：说说你了解的发布方式。
- 好：设计一个 200 个服务的发布系统，分批、健康判定、自动回滚、审批与紧急通道各怎么做？一次发布把数据库 schema 改坏，回滚会遇到什么？你会怎么改流程避免下次？

## 项目结合钩子

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

## 出题原则

- 每道题从现象切入而不是从概念切入：给一段告警、一组指标或一个用户反馈，要求候选人给排查顺序与验证方法；只会给结论不会给验证的要追问。
- 故障必问且要完整时间线：没有处理过真实故障的候选人不管工具多熟都要标记为经验不足；有故障经历的要追"重来一次最早能在哪缩短恢复"。
- 结合规模出题：管理 10 台机器与 10000 台的问题完全不同，先问清规模，再决定问单机调优还是平台治理。
- 不考命令参数的记忆与特定云厂商的产品名，考的是分层排查思路、止血优先意识与把重复工作工程化的能力。