这次我们来看一个 DevOps 岗位面试准备项目litu54 / DevOps-Interview-Guide。它不是一个自动化部署工具也不是一个云平台而是一个面向 DevOps 求职者的开源知识库。从项目名称就能看出来主线是“面试题 知识梳理”。对于准备跳槽、转岗或校招的人来说这种仓库最大的价值不是提供标准答案而是帮你把 DevOps 涉及的技术栈、概念和工程实践按问题串起来形成一套可复述、可验证的知识体系。很多人在准备 DevOps 面试时会有两个问题一是问题太散不知道公司会问什么二是会操作但不会表达。比如用 Jenkins 做过流水线却说不清楚 CI/CD 的整体过程用过 Docker却不理解镜像分层和容器隔离的原理。这个项目存在的意义就是把这些内容集中整理让复习从“刷零散文章”变成“按主题冲刺”。我也会按照同样的思路把最常见、最容易被追问的 DevOps 知识点拆开讲清楚。这个项目对硬件基本没有要求不需要 GPU不需要显存也不需要安装复杂的运行环境。你只需要能打开 GitHub或者把仓库克隆到本地用浏览器和 Markdown 编辑器阅读就行。这也是文档型项目的优点启动成本几乎为零。下面先看能力速览再进入环境准备、内容验证和面试考点解析。1. DevOps-Interview-Guide 核心能力速览从项目标题和这类开源面试指南的常见写法来看可以整理成下面的速览表。注意具体目录结构需要以仓库实际内容为准本文只做合理推断和使用方法说明。能力项说明项目类型DevOps 面试知识整理与复习资料库文档型仓库主要内容面试问题、知识梳理、工具链对比、工程实践建议需要以仓库实际内容为准硬件要求无 GPU / 显存需求文本阅读即可操作系统Windows / macOS / Linux 均可运行方式浏览器阅读 / Markdown 编辑器阅读 / Git Clone 到本地API 服务不涉及批量任务不涉及依赖环境Git、Markdown 编辑器按需准备适合人群DevOps 岗位候选人、运维转开发、开发转运维、校招学生局限不代替动手实验不保证覆盖所有公司面试题从表里能直接得到一个结论这个项目不是拿来“运行”的而是拿来“读”和“练”的。你不需要为它单独准备一台服务器也不用担心显存不够。真正需要投入的是时间以及围绕面试题展开的动手验证。2. 适用场景与使用边界2.1 这个项目适合谁第一种是准备 DevOps 岗位面试的人。你可以在短时间内浏览面试范围找到自己不会的概念再逐个补齐。适合作为面试前的冲刺材料。第二种是从传统运维转 DevOps 的人。传统运维关注“稳定”DevOps 关注“稳定 效率 自动化”。通过面试题中的项目场景能快速理解 DevOps 是在解决什么问题。第三种是开发人员。很多后端开发也需要维护 Jenkins 流水线、写 Dockerfile、部署到 Kubernetes。这份指南可以作为补充知识帮助理解研发和运维之间的协作方式。2.2 能解决什么问题它至少能解决三个问题面试方向不明确围绕 DevOps 的岗位太多有的偏 CI/CD有的偏 Kubernetes有的偏云平台。面试题指南能帮助你找到这些岗位共同关注的核心模块。会做不会说很多人有操作经验但不知道如何组织语言。面试题通常要求先解释概念再说流程最后说工具。以题目切入比直接背原理更容易形成表达习惯。知识零散Docker、Kubernetes、CI/CD、监控、IaC 看起来是多个领域但面试时会被串起来。指南可以将这些内容收拢到同一个复习框架里。2.3 不适合什么场景如果你是已经深度掌握 CI/CD、容器、云原生并且有大量项目经验的高级 DevOps 工程师那么这个项目对你的帮助有限。它更适合作为查漏补缺的目录而不是完整进阶手册。另外面试题指南普遍有一个问题内容更新速度可能跟不上工具版本变化。比如 Jenkins 新版本弃用了某些插件或者 Kubernetes 版本不再支持某种 API。使用时要自己核对版本和时效性不能盲目照搬。最后要明确一点不管是使用这类面试项目还是自己动手搭建 CI/CD 环境都要遵守软件授权和合规要求不要直接复制公司内部文档和脚本到自己的笔记里。涉及真实业务数据、账号密钥、私有镜像都要脱敏处理。3. 使用前必须知道的背景DevOps 不是一个工具很多面试者会在第一道概念题上卡住什么是 DevOps如果只是回答“DevOps 是开发运维一体化”面试官很容易继续追问“具体怎么做”。所以你在看这份指南之前先把底层逻辑搞明白。DevOps 不是某一个工具也不是一个岗位名称。它是一种软件交付理念和文化目标是缩短从代码提交到生产环境部署的周期同时保证质量、安全和稳定性。DevOps 强调开发团队和运维团队协作通过自动化流程来减少手工操作和沟通成本。从流程上看DevOps 覆盖了需求、开发、持续集成、持续交付、部署、监控、反馈这样一个闭环。CI/CD 只是其中最重要的自动化手段而不是全部。配合容器化、配置管理、基础设施即代码、监控告警和日志分析才能形成完整的 DevOps 能力。面试中还有一个常见问题DevOps、Agile、SRE 有什么区别。简单理解Agile 解决的是需求开发和交付节奏问题DevOps 解决的是软件交付到运维全链路的协作问题SRE 是运维工程化的落地角色用软件工程方法保证服务可靠性。三者可以共存不是互斥关系。回答这类问题时建议用一条主线穿起来先说明 DevOps 的目标再说明流程最后给出工具。例如“DevOps 的目的是通过自动化和平台化手段让代码更快、更安全地到达生产环境落地时常见工具包括 Jenkins、GitLab CI、Kubernetes、Terraform、Prometheus 等。”4. 项目环境准备与本地克隆虽然这个项目没有复杂运行依赖但我还是建议你把它克隆到本地方便全文搜索、做笔记和长期迭代。这里先给出通用操作路径和仓库名需要按实际项目替换。4.1 准备 Git 和 Markdown 编辑器Windows 用户安装 Git for WindowsmacOS 用户自带 GitLinux 用户通常也已经安装。编辑器建议用 VS Code 加 Markdown 插件或者 Typora。如果只是快速浏览直接在 GitHub 网页上也能看。检查 Git 是否已经安装git --version如果没安装根据系统下载安装即可。安装完成后打开终端或命令行。4.2 克隆项目到本地进入你希望存放项目的目录执行克隆命令# 示例命令实际仓库地址以 GitHub 页面为准 git clone https://github.com/litu54/DevOps-Interview-Guide.git cd DevOps-Interview-Guide克隆完成后先看一下目录结构# Windows 下使用 dirLinux/macOS 使用 ls ls -la如果项目里是多个 Markdown 文件你通常能看到类似 README.md、docs、images 或者按主题划分的文件夹。不同版本可能结构不同不要认为所有仓库都是同一套标准。4.3 打开与阅读本地阅读时可以直接用 Markdown 编辑器打开目录。如果需要全文搜索VS Code 中使用CtrlShiftF可以批量搜索所有文件中的关键词。这样比在网页上逐页翻看效率高很多。建议你在 IDE 里保持目录结构不变如果将来要补充自己的笔记可以在根目录创建notes文件夹不要随意修改原仓库文件避免后续更新仓库时产生冲突。5. 内容验证如何快速判断这份指南的质量拿到任何一个知识型项目第一件事不是从第一页读到最后一页而是先判断它值不值得读。这里给出三个低成本验证方法。5.1 看 README 和目录README 通常包含项目简介、目录导航、使用方式。先看它是否明确回答了三个问题这个仓库覆盖哪些主题适合什么水平如何阅读再看目录结构有没有按照 DevOps 常见模块划分。合理的目录一般包括基础概念、CI/CD、容器、Kubernetes、自动化、监控、云平台、面试真题。如果目录只有零散题目没有分类阅读效率可能不高。5.2 搜索核心关键词在仓库目录下执行关键词搜索可以快速判断覆盖面# 搜索是否包含 CI/CD 相关核心词 grep -r CI/CD --include*.md . # 搜索是否包含 Kubernetes 相关词 grep -r Kubernetes --include*.md .你不需要把每个词都搜一遍选 5 到 8 个你自己最薄弱的方向去搜。如果都有对应内容说明覆盖度不错如果没有就把它当专题补充材料不要强求。5.3 用题目自测面试指南好不好最直接的方法是挑几个问题自测。比如什么是持续集成持续交付和持续部署有什么区别Docker 镜像和容器的关系是什么Kubernetes 中 Deployment 和 StatefulSet 有什么区别Jenkins Pipeline 的 Stage 和 Step 是什么关系如何设计一套高可用的 CI/CD 架构每道题先自己想 30 秒再看仓库里提供的答案。如果你能用自己的话回答再对比参考答案找差距这种复习方式比纯背诵有效得多。6. Jenkins 与 DevOps面试高频对比题和这个项目标题强相关的网络热词是“devops, jenkins vs devops”。这看起来很像一道面试题Jenkins 和 DevOps 有什么区别有人会以为 Jenkins 就是 DevOps或者 DevOps 就是 Jenkins这是典型的认知错误。6.1 两者不是同一个层级DevOps 是一种文化、理念和流程Jenkins 是一个自动化服务器工具。如果用房子来比喻DevOps 是建筑设计理念Jenkins 是砖瓦和施工工具。你不可能把 Jenkins 和 DevOps 放在对立位置因为这二者不是同一层级。更准确的关系是Jenkins 是 DevOps 落地时常用的 CI/CD 工具之一。DevOps 的落地需要工具链但工具链不等于 DevOps。只看重 Jenkins 插件体系却不改变研发、运维协作模式也就只是“装了工具的团队”不一定真正做到了 DevOps。6.2 Jenkins 在 CI/CD 中的位置Jenkins 最核心的使用场景是自动化流水线。一个典型流程是开发者提交代码到 Git 仓库Jenkins 检测到变更后触发构建执行编译、测试、打包然后再部署到测试环境或生产环境。下面是一段典型的 Jenkinsfile 示例演示了流水线的基本结构pipeline { agent any stages { stage(Checkout) { steps { git https://github.com/example/example-repo.git } } stage(Build) { steps { sh mvn clean package } } stage(Test) { steps { sh mvn test } } stage(Deploy to Dev) { steps { sh deploy.sh dev } } } }面试时如果被问到这个文件是什么你可以这样回答它定义了流水线的阶段顺序从拉取代码、构建、测试到部署每一步都可以被查看日志和失败重跑。这种代码化的流水线叫 Pipeline as Code是 Jenkins 在 DevOps 实践中的重要用法。6.3 面试中的回答套路当面试官问“Jenkins 和 DevOps 的区别”时不要只回答一句话。推荐答出三层概念层DevOps 是文化与实践Jenkins 是工具。流程层Jenkins 解决 CI/CD 的自动化DevOps 还涉及 IaC、监控、协作和反馈。落地层只看 Jenkins 无法代表 DevOps还需要容器、编排、配置管理、日志监控等一起配合。这样既体现理解也展示了知识广度。6.4 Jenkins vs GitLab CI vs GitHub Actions面试官也很喜欢问“为什么用 Jenkins而不是 GitLab CI 或 GitHub Actions”。对比时可以从托管方式、配置格式、插件生态和适用场景四个维度说。对比项JenkinsGitLab CIGitHub Actions部署方式自建服务为主可使用 GitLab 自带 Runner也可自建托管 Runner也可自建配置方式Jenkinsfile / 界面配置.gitlab-ci.yml.github/workflows/*.yml插件生态非常丰富较丰富行动市场增长快扩展能力适合复杂流水线深度集成 GitLab深度集成 GitHub规模成本需要自己维护有免费额度和付费方案有免费额度和付费方案选择工具没有标准答案重点是看团队基础设施和需求。比如已经在使用 GitLab那优先考虑 GitLab CI项目以 GitHub 为中心则 GitHub Actions 更自然已有大量 Jenkins 插件和自由构建任务换到其他工具成本可能很高。7. DevOps 面试必须掌握的知识体系无论你用的是 litu54 / DevOps-Interview-Guide 还是其他面试资料下面几个模块都是 DevOps 面试的高频区域。建议按照这个框架做自评再对照项目内容补缺。7.1 CI/CD 流水线持续集成、持续交付、持续部署这三个词必须能明确区分持续集成频繁将代码合并到主干并自动构建和测试。持续交付通过自动化测试后代码随时可以发布到生产环境但发布动作可能是手动的。持续部署代码通过所有检查后自动部署到生产环境。面试题常给一个场景然后问“这个流程应该属于持续交付还是持续部署”。判断标准就看部署动作是否还需要人工干预。7.2 容器与编排Docker 相关的常见问题包括镜像与容器关系、Dockerfile 编写、多阶段构建、数据卷和网络模式。Kubernetes 相关的常见问题包括 Pod 与容器关系、Deployment、Service、Ingress、ConfigMap、Secret、StatefulSet、Helm 和自动扩缩容。动手验证时不一定要有一整台集群可以用一种非常轻量的方式本地跑一套环境。下面是一份课程级别的 docker-compose 示例用于本地启动一个 Web 服务和数据库version: 3 services: app: image: nginx:stable-alpine ports: - 8080:80 volumes: - ./html:/usr/share/nginx/html db: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: example-pass MYSQL_DATABASE: app volumes: - mysql_data:/var/lib/mysql volumes: mysql_data:这个文件可以放进你的实验项目作为“容器编排入门”的验证用例。面试时讲清楚端口映射、数据卷和容器编排基础即可。7.3 基础设施即代码基础设施即代码的目标是用代码管理服务器、网络、存储和云资源。代表工具是 Terraform、Ansible、Pulumi、CloudFormation。核心概念包括声明式与命令式、状态管理、幂等性、模块化、Plan/Apply 流程。面试中常问“Terraform 和 Ansible 有什么区别”回答时可以点明Terraform 偏向资源生命周期管理Ansible 偏向配置管理和应用部署但实际使用中有重叠。7.4 监控与可观测性监控不等于可观测性。监控是“系统是否正常”可观测性是对系统内部状态的洞察能力。三个核心支柱是 Metrics、Logging、Tracing。常见工具组合是 Prometheus Grafana Loki OpenTelemetry。面试问题可能是你现在有一台应用服务器如何判断它有问题可以先看 CPU、内存、磁盘再看日志最后看请求延迟和错误率。整个排查思路也是 DevOps 工程师的日常能力。7.5 云平台与多云现在很多 DevOps 岗位要求熟悉至少一种云平台比如 AWS、阿里云、腾讯云、华为云。面试重点包括云主机、对象存储、负载均衡、数据库服务、容器服务、IAM 权限模型和成本优化。如果没有云环境也可以只看官方文档和免费额度。但要注意不要把生产环境的账号密钥放进自己的面试项目和笔记里。7.6 脚本语言与自动化工具DevOps 工程师不需要是高级软件工程师但至少要掌握一种脚本语言。最常见的组合是 Python Bash。面试题可能涉及写一段脚本批量处理日志、调用 API 或清理临时文件。写脚本时要有基本安全意识不要明文写密码不要随意删除生产环境文件要做输入校验和日志输出。这些点都能在面试中体现工程素养。7.7 软技能与 SRE 思维除了技术知识DevOps 岗位很看重协作和响应能力。比如线上故障发生时怎么沟通、怎么划分优先级、怎么复盘。面试可能问“你遇到过一次重大线上事故怎么处理”。回答要包含发现问题、止血、定位、修复、恢复、复盘改进六个步骤。8. 如何把面试题转化为自己的项目经验面试题背得再多也不如一个小项目有说服力。建议你在复习期间一边看 litu54 / DevOps-Interview-Guide 的内容一边搭建一个最小可运行的 DevOps 实验环境。8.1 从题目到方案把你最不熟悉的技术点做成小型需求。比如“如何写一条 Jenkins 流水线构建一个 Node.js 项目并部署到服务器”这个需求就包含代码仓库、Jenkins、Docker、测试、部署多个环节。你可以把这个需求拆成子任务用本地虚拟机或一台低配服务器完成。完成之后用 Markdown 写一页实验记录包含环境、步骤、命令、截图和遇到的问题。这份记录可以直接用到面试项目介绍中。8.2 整理个人实验环境如果条件有限不一定要申请大量云资源。本地 Docker Desktop 加一台虚拟机已经能覆盖大部分 CI/CD、容器、编排和部署演示。把示例配置写成独立目录保持“一键启动”的潜力。下面是一些你可以自己实践的方向用 Gitea 或 GitLab 私有部署一个 Git 仓库用 Jenkins 或 Gitea Actions 配置一条自动化流水线用 Docker Compose 启动 Nginx MySQL Redis用 Terraform 管理本地或云上的简单资源用 Prometheus 加 Grafana 做监控面板8.3 用作品集证明能力面试官不太信任“我平时会用 Docker”但容易相信“我做过一个 Docker 化的应用并写了部署文档”。用项目沉淀面试素材比单纯背题更稳。不要虚构没有做过的数据。如果只是跟着文档跑通 demo就说“完成了部署实验”如果做过线上故障处理再写真实案例。项目经验要经得住追问。9. 关于 API 与批量任务的说明对于 litu54 / DevOps-Interview-Guide 这个项目它属于文档型知识仓库不提供软件服务也不涉及接口 API 和批量任务。这一点在面试准备和使用时不需要担心。你不需要向这个项目发送请求不需要配置端口也不需要设置任务队列。它不会像 ComfyUI、TTS 服务或 OCR 服务那样有显存占用和并发压力。它占用的资源只是磁盘和阅读时间。如果之后你自己把面试知识点整理成笔记系统那可以和 API 无关如果你想做一个“自动化面试刷题工具”那就需要按通用 API 设计原则来规划但这已经超出了原项目的范围。10. DevOps-Interview-Guide 常见问题与排查使用文档型开源项目时最多遇到的问题不在代码运行上而在访问、阅读和内容理解层面。下面是一份排查表格。问题现象可能原因排查方式解决方案GitHub 页面打开缓慢网络访问不稳定用本地网络检测或其他镜像源使用可访问的镜像站或稍后重试克隆失败仓库地址写错或网络异常检查 URL 大小写和路径重新复制仓库地址后执行 git clone克隆成功但内容为空分支不对或仓库尚未初始化执行 git branch -a 查看分支切换到主分支如 git checkout main找不到某个面试题项目未覆盖该主题用关键词全局搜索先阅读 README再结合其他资料补充知识点太散不知道从哪里开始没有复习主线按第 7 节的知识体系自评从自己最薄弱且面试高频的模块开始题目答案过时仓库没有及时更新查阅对应工具官方文档以官方文档和当前稳定版为准读了但记不住缺少输出和练习手写笔记 / 复述 / 搭建实验每道题用自己的话回答并运行验证简历项目经验与面试题脱节没有把概念转成项目经验梳理真实实验和案例按第 8 节构建最小可运行项目遇到任何问题时先看自己有没有足够的上下文再看外部依赖。比如 Jenkins 题目不会做可能是没安装 Jenkins 环境那就先本地跑一次流水线再回头看概念理解和记忆都会更牢固。11. 最佳实践与使用建议11.1 第一次先做知识自评不要从第一个 Markdown 文件开始顺序阅读。先用 30 分钟浏览目录和 README标记出自己会、部分会、完全不会的知识点。先把完全不会的放到最后先从“部分会”的开始复习因为你已经有一定上下文理解速度更快。11.2 用“费曼式回答”检验效果每看完一道题合上资料用自己的话讲一遍最好写下来。如果发现讲不清楚说明还没有真正理解。这个流程比反复划线更重要。11.3 保留一套最小可运行配置面试前最好准备一套可以快速演示的配置比如说一条简单的 Jenkinsfile一个 docker-compose.yml或者一个 Kubernetes Deployment YAML。面试中如果被要求现场说思路你能直接在白板或文档上写出来。11.4 注意合规与安全边界复习和实验过程中不要使用公司内网的敏感数据不要公开分享包含密钥的配置文件。任何涉及账号、密码、Token 的内容都要脱敏。如果你使用云服务做实验注意控制成本用完释放资源。11.5 形成长期学习习惯面试只是起点。DevOps 技术变化很快今天 Jenkins 是标配明天可能 GitLab CI 和 GitHub Actions 成为主流。这类面试指南适合作为知识目录真正的成长还是来自你在真实项目中的每次构建、部署和排障。如果你正好在准备 DevOps 面试第一步可以先把 litu54 / DevOps-Interview-Guide 克隆到本地把 README 和目录结构读一遍再用第 5 节的检索方法找几个你不熟的关键词。如果目录里没有覆盖你需要的主题就按第 8 节的方法用自己的实验补上。这样不管仓库内容是否完整你的复习过程本身已经比单纯刷题更有价值。