vinqi.com

DevOps工程师面试题及答题要点

DevOps/SRE面试通常3-4轮，技术面重点考Linux、CI/CD流水线、容器化、监控告警和线上故障处理。最容易挂的不是知识盲区，而是项目经历被连续追问三层后答不出细节，以及故障场景题没有讲清排查思路。

专业基础

你平时怎么判断一台Linux服务器负载高是什么原因导致的？

考察点：考察Linux基础和排查思路，是否有一套系统化的定位方法。

答题要点：
  1. 先看整体指标：uptime看负载，top确认是CPU、内存还是IO瓶颈，注意区分负载高但CPU空闲的情况（往往是IO等待）；
  2. 再细分定位：CPU高用top+pidstat找进程，内存用free确认是否用了swap，IO用iostat看磁盘利用率；
  3. 最后追根因：是业务流量上涨、代码问题、还是某个任务（如日志压缩、备份）在跑；
  4. 答的时候按『看现象→定位资源→找进程→查原因』的顺序讲，体现思路完整。

别踩：只背命令名不讲排查顺序，或者只说『用top看一下』就停住，显得没有实战经验。

Docker容器和虚拟机的区别是什么？你们生产环境为什么选容器？

考察点：考察对容器原理的理解深度，以及技术选型是否有业务理由而非跟风。

答题要点：
  1. 原理层面：容器共享宿主机内核，靠命名空间做隔离、靠cgroups限制资源，虚拟机则是每个都有独立内核，所以容器更轻、启动更快；
  2. 选型理由要落到业务：交付物标准化、环境一致、扩缩容快、资源利用率高；
  3. 补充一句取舍：隔离性弱于虚拟机，安全要求极高的场景会两者结合使用；
  4. 如果公司规模小，也可以说用容器主要为了解决环境不一致问题，这是真实合理的理由。

别踩：只答『容器轻量』就结束，说不出隔离原理和具体业务收益，暴露只会用不懂原理。

说说你对CI/CD的理解，你们之前的流水线是怎么设计的？

考察点：考察是否真正搭建过流水线，还是只是用过别人搭好的。

答题要点：
  1. 先讲概念：CI是频繁集成+自动化测试，CD是自动化交付/部署，重点讲清两者边界；
  2. 再讲自己参与的流水线阶段：代码提交→构建→单测→制品管理→部署→自动化验证，说明每步卡什么；
  3. 强调关键设计点：比如测试不通过禁止合并、制品版本化管理、部署支持回滚；
  4. 如果只是使用不是搭建，如实说清楚自己负责哪段，别把团队成果全说成自己的。

别踩：把CI/CD讲成概念课，说不出自己流水线的具体阶段和卡点，追问两句就露馅。

你们用的监控体系是怎么搭的？告警是怎么设计的？

考察点：考察监控告警的实战经验，是否处理过告警风暴、告警疲劳这类真实问题。

答题要点：
  1. 分层讲：基础设施层（CPU/内存/磁盘/网络）、应用层（接口延迟、错误率）、业务层（订单量、成功率）；
  2. 告警设计讲分级：什么级别电话、什么级别群消息、什么只记录，以及告警阈值怎么定的；
  3. 一定要讲治理：告警去重、依赖收敛（机房故障只报一条而不是几百条）、定期清理无效告警；
  4. 有具体例子最好：比如某次告警太多导致大家忽略，后来怎么收敛的。

别踩：只罗列监控工具名，讲不出告警分级和治理，这是区分『用过』和『管过』的关键点。

项目经历深挖

挑一个你主导的DevOps项目讲讲，从背景到结果。

考察点：考察表达结构、项目真实性，以及『主导』和『参与』的边界感。

答题要点：
  1. 用STAR结构：背景痛点→目标→你具体做了什么→量化结果，控制在两分钟内；
  2. 背景要具体：比如发布靠手工、一次发布40分钟且常出错，别空谈『效率低』；
  3. 讲清你的角色：哪些是你决策的、哪些是执行的，团队几个人、你负责哪块；
  4. 结果给数字：发布时间降到多少、故障率变化、回滚时间等，没精确数字给估算区间并说明。

别踩：全程『我们我们我们』，追问『你个人做了什么』时答不上来，这是深挖环节最常见的挂法。

你说的这个方案，当时有没有考虑过别的方案？为什么没选？

考察点：考察技术决策能力，是拍脑袋还是有对比和权衡。

答题要点：
  1. 一定要能说出至少一个备选方案，以及各自的优缺点；
  2. 决策理由要结合公司实际：团队技术栈、维护成本、时间窗口，而不是『这个更流行』；
  3. 可以坦承方案的不足和后续补救，比如先快速上线再逐步优化；
  4. 如果当时确实没系统对比，就诚实说当时约束是什么，事后复盘觉得可以怎么做更好。

别踩：说『当时没想那么多』或『领导定的』，直接暴露缺乏独立技术判断。

这个项目上线后出过什么问题？你怎么处理的？

考察点：考察诚实度和复盘能力，完美无缺的项目反而可疑。

答题要点：
  1. 准备一个真实的小故障案例：现象→定位过程→修复→后续预防措施；
  2. 重点讲预防：加监控、加告警、改流程，体现闭环思维；
  3. 如果自己有责任就大方承认，说明学到了什么；
  4. 别选太严重的事故（如删库），也别说『没出过任何问题』。

别踩：说项目从没出过问题，面试官会判定要么项目太小要么在撒谎，两个都不加分。

如果让你现在重新做这个项目，你会改哪些地方？

考察点：考察技术视野的成长性，是否还在持续反思和更新认知。

答题要点：
  1. 准备2-3个具体的改进点，最好和这两年的技术演进相关；
  2. 改进要有理由：当时的约束是什么、现在条件变了什么；
  3. 可以提到流程层面：比如自动化测试覆盖不够、文档沉淀不足；
  4. 避免全盘否定过去的方案，讲『在当时条件下合理，现在可以更好』。

别踩：说『没什么要改的』显得停止思考；把过去方案全盘否定又显得当时决策不靠谱。

故障处理与情景应变

凌晨两点你收到告警，线上服务不可用，说说你的处理过程。

考察点：考察故障应急的完整流程：止血优先还是排查优先、如何汇报。

答题要点：
  1. 第一原则先止血再查因：能不能快速回滚、重启、切流量，恢复业务永远优先；
  2. 同步拉群通报：已知现象、影响范围、当前动作、下次同步时间，别闷头自己查；
  3. 止血后再定位：看变更记录（是不是刚发布）、看监控曲线拐点、看依赖服务；
  4. 事后写复盘：时间线、根因、改进项，并落实到具体负责人和期限。

别踩：一上来就钻进排查细节，忘了先恢复业务和同步信息，这是SRE面试最经典的减分点。

发布过程中发现新版本有bug，但已经发布到一半了，怎么办？

考察点：考察发布策略设计和应急决策，是否有灰度和回滚意识。

答题要点：
  1. 先问发布策略：如果有灰度/分批，影响面可控，直接停住并回滚已发布部分；
  2. 回滚前评估：回滚本身有没有风险（比如涉及数据库变更就麻烦），必要时宁可前滚修复；
  3. 讲预防机制：为什么发布要分批、要留快速回滚能力、数据库变更要和代码发布解耦；
  4. 体现决策速度：这种场景要果断，别纠结『先查清楚bug再说』。

别踩：只讲『回滚』两个字，说不出回滚的前提条件和数据库变更这类例外情况。

开发说测试环境好好的，一到生产就出问题，你怎么排查这种环境差异？

考察点：考察环境一致性意识和系统化对比排查能力。

答题要点：
  1. 先对比配置：环境变量、配置文件、中间件版本，这是最常见原因；
  2. 再对比数据和规模：测试数据量小、生产并发高，很多问题只在规模上来后暴露；
  3. 对比依赖：生产依赖的外部服务、网络策略、权限和测试环境是否一致；
  4. 长期方案：推动环境一致性和配置管理，把『我本地能跑』这类问题从流程上消灭。

别踩：只说『查日志』，没有环境差异的系统性对比框架，显得排查经验不足。

老板要求下周上线一个新服务，但你的自动化还没覆盖它，怎么办？

考察点：考察务实和优先级判断，是死守流程还是灵活交付。

答题要点：
  1. 先接需求再谈风险：明确上线必须项（监控、告警、回滚方案）不能省，自动化可以后补；
  2. 给方案分级：手动上线+关键项自动化，一周内可交付；完整流水线排到下个迭代；
  3. 把风险写清楚同步给相关方，让决策透明，而不是自己扛或硬顶；
  4. 上线后立刻补自动化，避免临时方案变永久方案。

别踩：两个极端都减分：要么『不行必须先做自动化』显得不灵活，要么全手动硬上不留监控。

行为面试

和开发团队在发布流程上有分歧，比如他们嫌你的卡点太多影响效率，怎么处理的？

考察点：考察跨团队协作能力，DevOps一半工作是推动流程落地。

答题要点：
  1. 先讲具体案例：分歧是什么、开发的核心诉求是什么、你的顾虑是什么；
  2. 体现换位思考：效率确实重要，把卡点做轻（比如测试从20分钟优化到5分钟）而不是硬顶；
  3. 用数据说话：用发布故障率、回滚次数证明卡点的价值；
  4. 结果导向：最终达成什么共识，流程有没有被团队真正接受。

别踩：把开发说成对立面，或者『我坚持原则最后他们接受了』，暴露协作能力差。

说一次你推动自动化的经历，遇到的最大阻力是什么？

考察点：考察推动能力和对组织现实的理解，自动化落地难在人不难在技术。

答题要点：
  1. 选一个阻力真实的项目：比如老系统没人敢动、团队没时间配合；
  2. 讲清你怎么破局：从小范围试点、先做最痛的环节、让受益方看到效果；
  3. 承认节奏：不是一次推成，而是分阶段让团队逐步接受；
  4. 给结果：节省了多少人力或减少了多少故障，哪怕是估算。

别踩：说『没什么阻力，大家都很支持』，面试官会认为你只做过锦上添花的小事。

你平时怎么保持技术更新的？最近在学什么？

考察点：考察学习习惯的真实性，以及技术敏感度是否匹配岗位需求。

答题要点：
  1. 说具体的学习方式：关注的信源、动手做过什么，而不是『看博客』；
  2. 最近在学的东西要和岗位相关，能讲出为什么学、学到什么程度；
  3. 最好有输出：内部分享、笔记、给开源项目提过issue都可以；
  4. 别堆热门词，说一个就讲透一个。

别踩：罗列一堆热门技术名词但每个都只会说概念，追问『你用它做过什么』就卡住。

为什么从上家公司离开？

考察点：考察离职动机是否合理，以及稳定性预期。

答题要点：
  1. 理由指向发展：想接触更大规模的系统、更完整的DevOps体系、更贴近业务；
  2. 不贬低前公司和前领导，客观陈述客观限制即可；
  3. 和应聘岗位形成闭环：这家公司恰好能补上你想成长的那块；
  4. 如果被裁或公司变动，如实说，行业都理解，别编故事。

别踩：抱怨前公司、吐槽领导，或者说『钱少』作为唯一理由且没有其他支撑。

反问环节

你有什么想问我们的吗？

考察点：考察你对这个岗位的关心程度和判断力，完全不问或只问薪资都不好。

答题要点：
  1. 问团队现状：目前发布频率、自动化覆盖程度、故障响应机制是怎么运作的；
  2. 问挑战：这个岗位当前最需要解决的问题是什么，前半年主要做什么；
  3. 问协作：DevOps团队和开发团队的关系、流程由谁主导；
  4. 薪资福利放在HR面问，技术面把时间用在了解真实工作内容上。

别踩：说『没什么想问的』显得没兴趣；只问加班和薪资显得只关心待遇。

（如果你反问后面试官反问）你觉得我们目前这套体系有什么可以改进的？

考察点：临场压力题，考察基于有限信息的判断力和表达分寸。

答题要点：
  1. 先声明信息有限，给的是初步假设而非结论；
  2. 基于面试中听到的信息提1-2个具体方向，比如发布频率和团队规模是否匹配；
  3. 用提问式表达：『我理解是……不知道实际是不是这样』，留出对方纠正的空间；
  4. 别说『我觉得你们体系很落后』这类判断性结论。

别踩：仗着面试官一句话就大刀阔斧点评对方体系，显得傲慢且信息判断能力差。

面试准备清单

什么时候要做什么
面试前 3 天把简历上每个项目按STAR结构写一遍，重点补量化结果和你个人的具体动作，准备被追问三层的细节。
面试前 3 天过一遍Linux排查命令、容器原理、CI/CD阶段设计、监控告警分级这四块基础，确保能脱稿讲清排查顺序而非只背命令名。
面试前 2 天准备2个故障案例：一个完整的线上故障处理（含复盘改进），一个发布出问题的应急处理，按『止血→定位→根因→预防』组织。
面试前 1 天查目标公司的技术栈和业务规模，把你的项目经历往他们的场景上靠，反问问题也据此准备2-3个。
面试前 1 天准备离职原因、自动化推动经历、跨团队分歧这三个行为题的答案，各控制在90秒内，先自己说一遍录音听一遍。
面试当天提前10分钟到场或上线，准备好纸笔；回答故障题时可以在纸上画时间线，边画边讲思路更清晰。

常见问题

DevOps面试一般几轮？都考什么？
通常3-4轮：1-2轮技术面（Linux、容器、CI/CD、监控、故障场景题）、一轮主管或交叉面（项目深挖+行为面）、最后HR面谈薪资和动机。中小公司可能压缩到2轮，技术面和行为面合并进行。
没有大规模生产环境经验，故障题怎么答？
用测试环境或小规模环境的真实案例来答，重点展示排查思路的完整性：先止血、再定位、后复盘。面试官考察的是方法论而非事故规模，硬编大事故反而容易在追问细节时露馅。
DevOps和SRE面试题一样吗？
基础部分高度重合（Linux、容器、CI/CD、监控），但SRE会更偏稳定性：故障应急、SLA/SLO、值班机制、容量规划问得更多；DevOps更偏流水线和交付效率。投SRE岗要额外准备故障处理和on-call相关案例。
技术面答不上来的题怎么办？
直接说这块不熟，但给出你的排查思路或相关的相邻经验，比如『这个具体参数我没用过，但类似问题我会先查官方文档和监控指标』。诚实加思路比硬编答案好得多，面试官往往就是故意出一道超纲题看反应。

继续看这个岗位

简历怎么写 面试题与答题要点 技能要求与关键词

相关岗位

后端开发工程师简历前端开发工程师简历Java开发工程师简历Python开发工程师简历Go开发工程师简历全栈工程师简历 后端开发工程师面试题前端开发工程师面试题Java开发工程师面试题Python开发工程师面试题 后端开发工程师技能要求前端开发工程师技能要求Java开发工程师技能要求Python开发工程师技能要求