DevOps与SRE面试深挖 15 题
涵盖容器编排、SLI/SLO 体系、故障自愈、容灾架构与全链路可观测性实战。
题目为高频真实问法;①②③ 三层答案为模拟示范,非真实面经
① 简历常见平淡回答
「用 kubectl logs 看报错日志,没有日志就 kubectl describe 看退出状态码,然后进容器看。」
停留在基础命令罗列,未讲清应用初始化探针配置、OOMKilled 内存溢出判定、依赖未就绪与系统信号处理的底层定位链条。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
排查 CrashLoop 首先执行 kubectl describe pod 检查 Last State:若退出码为 137 则明确是 OOMKilled,需核实 limit 限制或排查内存泄漏;若退出码为 1 或 2,则通过 kubectl logs --previous 查看上一次崩溃前的控制台输出。若日志为空,排查启动命令挂载、Secret/ConfigMap 挂载缺失或 InitContainer 执行阻塞;若应用启动后几秒退出,检查健康探针(Liveness/Readiness)端口与超时参数是否过严,避免探针误杀。
① 简历常见平淡回答
「把服务器 CPU 使用率和接口可用性定到四个九,平时看告警群,超出指标就让开发停需求。」
将基础设施资源指标与用户体验混为一谈,缺乏基于关键用户旅程(CUJ)的 SLI 提炼、燃烧率(Burn Rate)阶梯告警与阻断机制。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
SRE 拒绝把 CPU 当 SLI。我们围绕关键用户旅程设计服务等级指标:比如支付网关以「成功下单 HTTP 2xx 且延迟低于 500ms 的请求占比」为 SLI,设定月度 SLO 为 99.95%,对应每月 21.6 分钟的不可用错误预算。监控层配置多窗口多燃烧率告警(如 1 小时消耗 5% 预算触发 P1 寻呼,6 小时消耗 10% 触发工单);当月度错误预算消耗超过 80%,自动化门禁冻结非紧急业务发布,强制转入稳定性治理迭代。
① 简历常见平淡回答
「把 OpenTelemetry 接入所有应用,把全部 Trace 收集发到 ES 或者 Jaeger 里面存起来。」
全量存储海量追踪数据会迅速压垮存储集群并产生巨额开销,缺乏头部采样、尾部采样(Tail-based Sampling)与自适应治理经验。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
全量采集是典型的反模式。我们在 OpenTelemetry Collector 层推行两阶段采样策略:在客户端做 1% 的基础头部概率采样(Head-based Sampling)以建立吞吐基线;在 Collector 网关集群部署尾部采样(Tail-based Sampling),在内存中缓冲完整 Trace,一旦判定请求包含 HTTP 5xx 错误、慢调用超过 1.5 秒或命中白名单用户标签,则强制 100% 持久化落库。结合 ClickHouse 列式存储替代传统 ES,存储成本降低 75% 且保留了全量异常溯源能力。
① 简历常见平淡回答
「发布的时候先上一台机器看看有没有报错,如果有报错就手动在发布系统点回滚。」
人工盯盘缺乏客观阈值与实时统计学检测,缺少自动化金丝雀分析(ACA)与结合指标的自动化阻断回滚闭环。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
现代金丝雀发布依赖自动化度量闭环。我们基于 Argo Rollouts 或 Flagger 编排发布:首批引导 5% 生产真实流量进入 Canary 实例,并启动 10 分钟自动化指标比对;核心指标(如接口 5xx 错误率增量、P99 延迟跃升、日志异常堆栈数)通过 Prometheus 持续聚合分析;若错误率超过基线 0.5% 或指标波动触碰统计学显著性阈值,系统自动中断发布流程并在 30 秒内秒级切流回滚,同时在飞书群自动输出熔断报告。
① 简历常见平淡回答
「写 Terraform 脚本把服务器和网络建好,代码更新了用 Jenkins 跑脚本部署到集群里。」
缺少对 GitOps 声明式单一事实源、状态漂移检测(State Drift)、权限审计与不可变基础设施闭环的理解。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
IaC 与 GitOps 的核心是「声明式终态与防漂移闭环」。我们将全部网络 VPC、Kubernetes 集群与云资源通过 Terraform 模块化声明,状态文件统一加密存放在远程后端;在应用交付侧,采用 ArgoCD 践行 GitOps 原则,Git 仓库作为集群期望状态的唯一事实源。ArgoCD 持续对比线上实时状态与 Git 提交,一旦发生手动篡改自动触发 Self-Heal 覆盖纠偏;敏感凭证通过 Vault 与 External Secrets 动态注入,杜绝明文上库。
① 简历常见平淡回答
「重启节点上的 kubelet 试试,如果还不行就看节点系统日志或者把这个节点删了重新加。」
盲目重启或删节点缺乏系统级排查素养,未讲清 kubelet 心跳上报、容器运行时(containerd)、底层磁盘空间与网络 CNI 插件的故障链。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
排查 NotReady 首先通过 kubectl describe node 查看 Conditions 状态块:检查是 DiskPressure、PIDPressure 还是 NetworkUnavailable。若出现磁盘压力,立即排查 /var/lib/containerd 镜像层与容器日志是否爆满并触发自动清理;若由于 kubelet 心跳丢失,登录主机检查 systemctl status kubelet 与 journalctl -u kubelet,排查 CNI 插件崩溃(如 Calico/Flannel 路由未同步)或底层 D 状态卡死;必要时先 cordon 隔离并 drain 驱逐工作负载,确保业务连续性。
① 简历常见平淡回答
「接口慢了就加缓存,请求实在太多了就在前端弹队排,或者后端把某些不重要的查询关掉。」
停留在静态配置与经验降级,缺乏基于系统饱和度(CPU/排队延迟/并发度)的动态自适应过载保护算法与分级丢弃设计。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
过载保护必须具备「自适应吞吐维持能力」。静态阈值在瞬时波峰下极易过早误伤或过晚打崩,我们采用 CoDel 或借鉴 Envoy/BBR 的排载算法:网关层实时监控系统运行排队延迟与 CPU 水位,当延迟突增触发过载时,按照业务优先级权重自适应丢弃请求(先丢离线爬虫与推荐刷新,保核心交易支付);下游服务间调用配置熔断器(如 Resilience4j / Sentinel),在错误率或慢调用比例突破阈值时秒级半开降级,依赖只读缓存返回预设兜底数据。
① 简历常见平淡回答
「在两个城市各建一个机房,数据库做双向主从同步,机房挂了一个就把域名切到另一个机房。」
双向主从同步在网络分区或高并发下必然引发写入冲突与数据错乱,缺乏单元化架构(Cell-based Architecture)与路由分片的实操深度。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
多活必须采用「单元化业务封闭与全局数据路由」架构。我们按用户 ID 做哈希切片分片到各机房单元,保证 95% 以上的核心写事务在本地机房内部单元闭环完成,规避跨地域网络时延;全局公共配置或元数据采用 Raft 分布式一致性协议或单向异步复制;发生机房级断网灾难时,通过全局流量控制平台联动 DNS 与边缘网关剔除故障可用区,重新计算分片权重将受损用户重定向至健康单元,并严格结合分布式排他锁防止双写脑裂。
① 简历常见平淡回答
「部署 Prometheus 抓取所有 Pod 的 metrics,配置 Alertmanager 把告警发送到钉钉或者邮件群。」
单机 Prometheus 面临存储瓶颈与单点故障,缺乏海量时序分片存储、高基数控制、告警泛滥去重与拓扑抑制的架构能力。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
我们构建「分布式采集加长周期集中存储」监控底座:边缘部署轻量 Prometheus Agent 专职抓取指标,后端统一通过 Remote Write 写入 VictoriaMetrics Cluster 或 Thanos 集群做降采样与分布式长期存储;在告警治理端,针对告警风暴推行三层收敛机制:在 Alertmanager 配置基于服务与环境标签的 Grouping 分组,利用 Inhibition 规则实现「机房挂了自动抑制上千个微服务不通告警」,并基于动态基线消除夜间静态阈值误报,将每日无效报警压降 80% 以上。
① 简历常见平淡回答
「各个机房拉专线通起来,各机器配好防火墙规则,应用调用都走内部内网 IP 访问。」
默认内网互信边界模型极易因单点攻破导致横向渗透,缺乏身份认证基础设施(SPIFFE/SPIRE)、双向 TLS 加密与精细化访问控制。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
零信任原则是「持续验证,永不信任」。我们基于 Istio / Envoy 构建服务网格服务网格底座:借助 SPIRE 为集群内每一个工作负载动态签发唯一且短寿命的 X.509 身份凭证;网格数据面默认开启双向 mTLS,全面加密跨节点与跨机房流量;通过 AuthorizationPolicy 实施严格的最小权限白名单通信控制,阻断未授权的跨服务横向调用;所有管理运维通道废弃堡垒机静态密码,全面推行基于 OIDC 统一身份认证与临时按需授权(JIT Privilege)的访问体系。
① 简历常见平淡回答
「平时在测试环境拔掉一根网线,或者随机杀掉几个服务容器,看看系统能不能自动起来。」
盲目胡乱注入故障属于危险的恶作剧,缺少假设验证框架、爆炸半径控制(Blast Radius)与自动化急停(Kill Switch)机制。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
混沌工程是「基于假说的受控韧性实验」。实验严格遵循标准闭环:首先定义稳态指标(如支付成功率、P99 响应延迟);提出明确假设:「当下游风控节点网络丢包 30% 时,上游降级逻辑应平稳触发且主流程不受影响」;借助 Chaos Mesh 逐步注入故障并严格限制爆炸半径至金丝雀流量;全程配置自动化急停开关(Kill Switch),一旦业务稳态指标越线,系统在 10 秒内强制回滚注入。通过常态化演练成功提前发现多起隐性死锁与超时配置反模式。
① 简历常见平淡回答
「在群里艾特所有开发赶快上线查问题,让大家看自己负责的模块,催促他们尽快解决。」
缺乏标准应急响应机制(Incident Command System),群龙无首、混乱杂音与盲目多线排查会严重延长系统中断时间(MTTR)。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
作为事故指挥官(IC),我的职责是「控制节奏、阻断噪音、全力止血」。启动战情室后建立严格纪律:IC 负责统筹决策,分派专人(Scribe)负责对内对外每 15 分钟同步客观通报,指定 1 到 2 名核心攻坚人员专心排查,阻断管理层的直接催问干扰;应急优先级坚决贯彻「止血第一,归因第二」:优先通过流量切权、降级非核心功能或一键回滚恢复服务,杜绝在生产环境当场写代码调 Bug。服务恢复后,才转入保留日志和根因排查。
① 简历常见平淡回答
「开复盘会找出到底是谁改错了代码或者配错了参数,按公司规定进行通报批评或者扣绩效。」
指责个体不仅无法根治系统隐患,反而导致团队隐瞒失误与消极协作,缺乏通过人机工程、系统设计缺陷防范再犯的组织韧性。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
无指责复盘的信条是:「我们假设每个人在当时的信息条件下都做出了其认为最合理的决定」。复盘的核心不是「追究谁干的」,而是问「系统为什么允许这个动作发生且造成如此大破坏」。我们通过五个为什么(5 Whys)深挖根因:为什么没有自动化检查拦截?为什么告警延迟了 10 分钟才响?为什么单点故障没有容灾?最终产出具备清晰验收标准与到期责任人的行动项(Action Items),把事故变成不可多得的系统加固契机。
① 简历常见平淡回答
「直接拒绝,拿公司安全与稳定性红线压他们,不给开发开通发布权限。」
简单粗暴做守门人会激化对立,被业务指责阻碍商业发展,缺乏站在风险共担角度建立快速准入机制与阶梯授权的协同策略。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
SRE 的角色是「铺设安全的高速公路,而不是设置关卡路障」。面对紧急上线,我首先与业务负责人厘清核心商业预期与流量波峰时间;随后不搞一刀切卡死,而是与研发共同制定「风险前置折中预案」:对核心接口开展轻量级自动化关键链路压测,暂时禁用高风险后台旁路模块,并在网关层为新接口预置针对性限流降级开关;同时与业务负责人签署明确的风险备忘与上线应急预案,在满足业务时效性的同时守住底线。
① 简历常见平淡回答
「平时多加班搞工程开发,工单来了就先放一放,或者在团队里招实习生专门负责处理工单。」
靠人肉堆砌工单与消极拖延无法摆脱恶性循环,缺乏对苦工(Toil)的量化界定、50% 时间红线保护与平台自服务工程化意识。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
SRE 宪条明确规定:苦工(Toil)时间必须严格控制在 50% 以内。我的消除苦工策略分三步:第一,为琐碎工单建立结构化标签体系,统计每周重复率最高的前 5 类人工请求(如权限申请、配置变更、日志捞取);第二,秉承「凡手工重复超过三次的操作必须自动化」原则,将高频诉求抽象并沉淀至统一运维自服务平台(IDP),开放给研发团队自主执行;第三,将释放出来的精力投入到弹性伸缩、混沌演练等高杠杆工程项目,让系统具备自主运维能力。
换个岗位,继续练
练完DevOps / SRE 运维,通常接着练这些相邻岗位
后端开发面试深挖 15 题
核心技术 · 分布式 · BQ
查看题库
同技术栈全栈开发面试深挖 15 题
端到端交付 · 系统架构 · 全链路优化 · BQ
查看题库
能力延伸网络安全面试深挖 15 题
攻防对抗 · 漏洞挖掘 · 权限防御 · BQ
查看题库
没找到你的岗位? 查看全部 25 个岗位 →