韦雨欣 · 运维面经手册（112 题 + 简历审计）

简历全面审计

审计基准：ATS 可解析性、应届口径校准、数字自洽、追问风险

重庆城市科技学院 · 软件工程（本科）· 2023.09–2027.06 · 中共党员 · 绩点 4.6/5.0 · 综测 3/272 · RHCE / RHCSA
目标岗位：运维工程师 / SRE / DevOps（建议补充到简历'求职意向'栏）

总体评价

78/ 100

这份简历在应届运维候选人里属于中上水平。核心优势是有对口的真实实习（奇点云 4 个月数据平台运维，工单 180+、平均 15 分钟响应、3 套私有化交付）和两个可讲 STAR 的真实排障案例（Longhorn 版本兼容、iptables 转发链丢失），再加上 RHCE 与 3/272 的学业背书，匹配度很高。主要问题有四类：① PDF 是多文本框模板，机器提取时标题与内容严重错位，过大厂 ATS 简历解析系统（北森/Moka 等）有被解析乱序的风险；② 技能栏 6 条里 5 条'熟练'，应届口径过高，容易被当成'背词条'往死里追问；③ AI/AIOps 那条有语病且无任何实证，量化数据'掌握度提升 85%'无法自洽；④ 缺少 GitHub、求职意向等关键模块。下面按优先级给出全部修改意见。

五大优势（面试主动展示）

岗位匹配度高：Linux + 容器/K8s + 监控告警 + Python/Shell 自动化，正中运维/SRE JD 的核心要求清单
有真实企业实习且带量化：180+ 工单、15min 响应、3 套私有化交付、2 套 CDH 维护——比多数应届的'实验室经历'可信得多
证书与学业背书硬：RHCE 认证 + 绩点 4.6/5.0、综测 3/272、中共党员（投国企/银行科技岗显著加分）
有完整故障闭环叙事素材：煌上煌交付中 Longhorn 存储调度异常与 iptables 链丢失两个案例，面试讲 STAR 非常占便宜
文档沉淀习惯（8 篇 SOP/部署文档/巡检清单）契合运维'稳定性工程'的价值观，这是团队最看重的软素质之一

问题清单（按严重度排序，共 13 条）

高危

1. PDF 模板导致 ATS 解析乱序

[整体结构]

程序提取这份 PDF 的文本顺序是：教育背景 → CSDN → 邮箱 → 专业技能 → 项目经历 → 实习经历 → 姓名 → 政治面貌……标题与内容完全错位，说明模板用了多个独立文本框排版。大厂招聘系统解析后字段会张冠李戴。

修改建议：改用单栏、自上而下的标准模板，顺序固定为：姓名+联系方式 → 求职意向 → 教育背景 → 专业技能 → 实习经历 → 项目经历 → 校园经历 → 荣誉证书 → 自我评价。改完用 PDF 复制粘贴到记事本自测一遍顺序。

高危

2. '熟练'密度失控，自抬追问火力

[专业技能]

6 条技能 5 个'熟练'（含大模型辅助运维）。应届生写'熟练'，面试官默认你能扛住该方向的连环深挖，任何一条答穿都会被放大。

修改建议：统一分级话术：熟悉（能独立完成生产操作）→ 掌握（用过并理解原理）→ 了解（知道概念和边界）。建议第 1、2 条保留'熟悉'，第 3 条 Python 可保留'熟悉'，第 5 条云平台、第 6 条 AI 降为'掌握/了解'。

高危

3. 第 6 条 AI/AIOps 语病且无实证

[专业技能]

'面向AI 大模型AI 基础设施的稳定性建设'——'AI'重复、句子不通；且整条没有任何项目、工具、产出支撑，属于高危吹牛区，2026 年面试官普遍会追一句'具体怎么落地的？'

修改建议：改写：'了解 LLM/Agent 基本原理与 API 调用，实习中实践过用大模型辅助日志分析与告警收敛的探索；持续关注 AIOps 落地。' 同时必须准备一个能讲 5 分钟的实例——哪怕是自己写的小工具（如调 LLM API 对告警做聚类摘要），面试时这条反而能成为差异化亮点。

高危

4. '全员掌握度提升85%以上'无法自洽

[荣誉/量化]

'掌握度'没有量化定义，数据无法验证，必被质疑，反而连累其它真实数据的可信度。

修改建议：改为可验证口径：'组织 3 轮模拟测试，团队平均分提升 85%'，或直接删掉数字只保留'牵头梳理考点、组织 3 轮团队测试'。

高危

5. 缺 GitHub 主页与求职意向

[缺失模块]

运维岗代码能力的最好证明是 GitHub 仓库（巡检脚本、K8s 项目 README）；求职意向（目标岗位+城市）缺失会让 HR 不敢乱投递。

修改建议：头部补一行求职意向；GitHub 上传：K8s 高可用项目（含部署手册 README）、自动化巡检/部署脚本仓库，简历附链接并注明 star/内容。

中危

6. '维护 2 套 CDH 大数据集群'追问风险高

[实习经历]

4 个月实习生'维护'CDH 集群，面试必问 HDFS NameNode HA、YARN、ZooKeeper 架构与真实故障。若实际是配合/参与，措辞过度会翻车。

修改建议：如实降级为'参与维护'；同时把 CDH 三件套原理 + 至少 1 个真实故障（如 DataNode 掉线、磁盘 IO 慢拖高 CPU）准备到能白讲 3 分钟。

中危

7. 煌上煌项目归属易被误读

[项目经历]

放在'项目经历'下且落款'奇点云'，容易被当成第二段实习，被问'为什么两段实习时间重叠/这么短'。

修改建议：移入实习经历作为子项目，或标题注明'（奇点云实习期间客户交付项目）'。

中危

8. 鸡汤句与空泛表述

[自我评价]

'相信越努力，越幸运'在技术面试语境里是减分项；'自驱抗压、责任心强'属于无信息量形容词。

修改建议：自我评价改成事实标签：'4 个月数据平台私有化运维实习：独立处理线上工单 180+（平均 15 分钟响应）、完成 3 套私有化平台交付；擅长 Prometheus+Grafana 监控建设与 Shell/Python 自动化，习惯把重复操作沉淀为脚本与 SOP；故障处置追求闭环：定位→恢复→根因→预防。'

中危

9. 校园/党务经历篇幅过大

[校园经历]

纪检组组长的档案管理、三会一课细节与运维岗位无关，占了近 1/4 版面，挤压了技术内容的展开空间。

修改建议：班长保留两行（组织协调能力佐证），党支部经历压到一行；省出的空间给 K8s 项目补'3 个典型故障与解决'。

中危

10. 技能栏没有 Ansible

[技能缺口]

大厂运维面试 Ansible 是高频考点（本题库就有 5 道真题：setup 模块、register、file 模块幂等）。

修改建议：补学并在 K8s 项目里真实用一遍（6 节点内核参数/hosts 初始化天然适合 Ansible 化），然后写入技能栏和项目描述，形成闭环。

中危

11. CSDN 链接无背书数据

[联系方式]

只放链接不说明产出，若博客内容少反而暴露。

修改建议：有持续产出就标注'原创文章 XX 篇'；没有就删除。

低危

12. 若干用词与格式瑕疵

[措辞]

'生产规格'应为'生产级规格'；'承担数据平台运维技术支持'建议改'负责数据平台运维支持'；'优秀共青团干部"'引号全半角混用；手机号做邮箱前缀有撞库风险。

修改建议：逐句通读修正；邮箱建议换成姓名拼音前缀；电话保持 130-6022-5913 格式统一。

低危

13. 主修课程罗列过长

[教育背景]

Java、Python 爬虫、Web 开发等课程与运维岗位关联弱，稀释重点。

修改建议：保留 Linux 自动化运维、计算机网络、数据库技术、数据结构，其余删除。

改写示例（Before → After）

专业技能第 6 条（AI 方向）

Before熟练使用大模型辅助运维调试，了解大模型、Agent基本原理与API调用，可完成AI功能工程化落地；关注AIOps 告警收敛、智能根因分析、智能容量规划、混沌工程方向，面向AI 大模型AI 基础设施的稳定性建设。

After掌握大模型 API 调用与 Prompt 工程化，实习中实践过用 LLM 辅助日志聚类与告警摘要（自研脚本，告警噪音明显下降）；了解 Agent、MCP 基本原理，持续关注 AIOps 告警收敛与根因分析方向。

自我评价

Before具备Linux、云原生SRE实操经验与4个月数据平台运维实习，熟练Python、K8s、监控告警与自动化运维；擅长故障定位闭环与文档沉淀，关注AIOps与AI基础设施稳定性；自驱抗压、责任心强，相信越努力，越幸运。

AfterLinux/云原生方向，4 个月数据平台私有化运维实习：独立处理线上工单 180+（平均 15 分钟响应）、完成 3 套私有化平台交付；熟悉 K8s 集群运维与 Prometheus+Grafana 监控体系，习惯把重复操作沉淀为脚本与 SOP（8 篇文档）；故障处置追求闭环：定位→恢复→根因→预防。

华为 ICT 大赛量化

Before牵头梳理云赛道考点，组织3 轮团队测试，全员掌握度提升85% 以上；

After牵头梳理云赛道考点，组织 3 轮模拟测试，团队平均分提升 85%，获省赛实践区优胜；

投递与面试策略

岗位优先级：SRE/运维开发（匹配度最高）＞系统运维＞ DevOps 工程师；云厂商技术支持岗（华为云/阿里云）命中率也很高——有华为 ICT 大赛 + 私有化离线交付双重背书。
薪酬预期校准：题库里'对答如流 20-30k'指的是社招熟练工水平。2027 届校招现实区间：一线城市 12–20k（大厂 SP 另议），成渝 8–13k。谈薪建议给区间，并强调'更看重平台、技术栈与转正机会'。
时间线：2026.09 正值秋招正式批黄金窗口，优先投大厂秋招 + 银行/国企科技岗（党员 + 学生干部 + 绩点是硬加分项），同时日常实习转正路线并行。
一页纸原则：压缩校园经历后控制在 1 页；准备两个版本——SRE 版突出 K8s/监控/故障演练，云厂商版突出华为云 + 私有化交付。
面试防翻车清单（每条都要能展开 3 分钟）：① CDH 三件套架构 + 1 个真实故障；② Longhorn 本质（基于 iSCSI 的副本化存储，依赖 iscsid）与版本兼容排障全过程；③ iptables：Docker 的 DOCKER-USER/FORWARD 链、conntrack、DNAT 流量路径能画图；④ AIOps 实例（LLM 日志聚类小工具）；⑤ 简历每个数字的构成（180+ 工单里故障/咨询占比、15 分钟怎么统计、3 套交付各自节点规模）；⑥ VIP 漂移全过程与脑裂防范（Keepalived nopreempt/仲裁、为什么 3 master）。

开局与反问

共 4 题

Q30 ｜大厂真题·卷一

1. 自我介绍

我的回答 · 第一人称，结合简历

面试官您好，我叫韦雨欣，重庆城市科技学院软件工程专业 2027 届，绩点 4.6/5.0、综测排名 3/272，中共党员，持有 RHCE 认证。我最近一段经历是在奇点云做了 4 个月运维实习：负责数据平台私有化环境的运维支持，处理线上故障工单 180 多个、平均 15 分钟响应，独立完成 3 套私有化平台的交付；期间用 Prometheus+Grafana 定位 CDH 集群的 CPU、内存、IO 瓶颈并输出扩容方案，还把重复运维操作做成 Python/Shell 脚本，沉淀了 8 篇 SOP 和巡检文档。技术栈上我最扎实的是 Linux、Docker/K8s、监控告警体系和自动化脚本。课外我自己从零搭了一套 3 主 3 工作节点的高可用 K8s 集群，用 Keepalived+HAProxy 做 apiserver VIP 高可用，做过节点故障注入和 VIP 漂移演练。我的特点是故障处置有闭环意识、文档沉淀习惯好，希望有机会加入团队，请多指教。

回答思路 · 考点拆解与追问预防

结构：基本信息（3 项背书：绩点排名/党员/RHCE）→ 实习经历（量化数字+做的事）→ 技术栈关键词 → 个人项目亮点 → 收尾标签。控制在 60-90 秒。每个数字都会被追问：180+ 工单构成、15 分钟怎么统计、3 套交付规模——提前想好展开版本。

Q52 ｜大厂真题·卷二

2. 你真实运营过 Kubernetes 平台吗？

我的回答 · 第一人称，结合简历

如实回答两部分：一是实习期间真实运营过客户私有化 K8s 平台——我负责工单处理和监控告警日常，处理过 Pod 异常、镜像拉取失败、跨节点网络不通、Longhorn 存储调度异常这些线上问题，4 个月 180+ 工单；二是我自己从零搭了一套 3 主 3 工作节点的生产级规格集群，从内核参数、Keepalived+HAProxy、MetalLB、Calico 到监控栈都是自己配的，还做过故障注入演练。所以'从 0 搭建'和'线上运营'两段经历我都有，规模是中小型，但链路完整、踩的坑都是真的。

回答思路 · 考点拆解与追问预防

诚实拆成'运营'与'从零搭建'两块，规模如实但强调链路完整。关键：立刻准备好 2-3 个真实故障细节（镜像拉取、iptables 链、Longhorn），这题答完面试官通常马上挑一个让你展开。

Q83 ｜大厂真题·卷二

33. 看你还有什么问题。（反问环节）

我的回答 · 第一人称，结合简历

我会问两三个有信息量的问题：① "这个岗位日常更偏平台建设（工具链/自动化）还是业务运维支持？新人前一两个月一般接手哪块？"——判断成长路径；② "团队现在的监控/发布体系覆盖到什么程度，有哪些是计划中要补的？"——如果对方说'正在建设'，正好对上我监控和 CI/CD 的经验；③ "团队规模和值班机制是怎样的？"——了解真实工作节奏。我不会在技术面问薪资福利，那些留给 HR 面；也不会说'没有问题了'——反问是表达意愿的最后机会。

回答思路 · 考点拆解与追问预防

反问三件套：岗位内容（成长）、体系建设（对口切入点）、团队节奏（务实）。'没有问题'是禁忌。可以留一个钩子问题，把话题引回自己最熟的项目。

Q111 ｜ 2026 最新搜集

你怎么理解 SRE 这个岗位？（牛客校招高频收尾题）

我的回答 · 第一人称，结合简历

我认同 SRE 的核心信条：用软件工程的方法解决运维问题，用 SLO 而不是'零故障'来定义稳定。展开三点：① 错误预算——99.9% 的可用性意味着每月有约 43 分钟的'犯错额度'，预算没烧完可以激进发布新功能，烧完了就冻结变更优先稳定性，这是开发和运维冲突的解法；② 减少琐事（Toil）——手工重复操作要自动化掉，人应该去做工具和系统建设，我在实习里把巡检部署脚本化就是最朴素的 SRE 实践；③ 事后复盘不指责——故障是流程和工具的改进输入，我输出的 SOP 和故障文档就是想让同类问题第二次出现时有章可循。对岗位的理解：SRE 是'懂系统、写代码、扛责任'的工程师，不是重启服务的操作员——这也是我给自己规划的路线。

回答思路 · 考点拆解与追问预防

SLO/错误预算、消除 Toil、无指责复盘三大信条+实习实践对应。收尾一句个人定位。这是价值观题，答出'读过 SRE 书'的水准即可，别堆砌名词。

DevOps 基础

共 9 题

Q01 ｜通用题库

1. 解释 DevOps 的核心原则是什么？

我的回答 · 第一人称，结合简历

我理解 DevOps 的核心是让开发和运维作为一个整体，用文化和工具让软件交付又快又稳。经典框架是 CAMS：Culture 文化（打破部门墙、共担线上责任）、Automation 自动化（CI/CD、IaC、自动化测试）、Measurement 度量（DORA 四指标：部署频率、变更前置时间、MTTR、变更失败率）、Sharing 分享（知识库、故障复盘）。我在奇点云实习时对这四条都有体感：把部署巡检做成 Python/Shell 脚本是 Automation，输出 8 篇 SOP 和巡检文档是 Sharing，工单做故障分级、参与 SLA 评估就是 Measurement——因为我们知道平均 15 分钟响应能倒推出哪些环节最耗时，再针对性自动化。

回答思路 · 考点拆解与追问预防

考点：是否只会背名词。框架：一句话定义 → CAMS/DORA 展开 → 立刻绑定自己实习里的一件事印证。追问预防：DORA 四指标具体怎么算？你们 MTTR 是多少？怎么统计的？（要能答出 15 分钟响应与工单闭环的关系。）

Q02 ｜通用题库

2. 什么是持续集成（CI）和持续部署（CD）？

我的回答 · 第一人称，结合简历

CI 持续集成：开发频繁把代码合入主干，每次合并自动触发构建和测试，问题在最小范围内尽早暴露；CD 有两层：持续交付（Delivery）指代码随时处于可发布状态、发布需人工审批，持续部署（Deployment）指审批通过后自动发布到生产。我自己的链路是：git push → GitLab CI 触发 lint 和测试 → 多阶段构建镜像推 Harbor → helm upgrade 滚动更新 K8s；实习的私有化交付场景偏轻量，CI 主要做镜像构建和部署校验，回滚靠镜像版本号 + helm rollback。核心价值我说两句：一是减少人为失误，二是让发布变成例行操作而不是'大事件'。

回答思路 · 考点拆解与追问预防

题眼：把 CI / 持续交付 / 持续部署三个词讲出层次感，很多人混着说。用自己的流水线把概念串一遍是加分项。追问预防：交付和部署的区别？你们有没有自动回滚？

Q03 ｜通用题库

3. 解释基础设施即代码（IaC）的概念。

我的回答 · 第一人称，结合简历

IaC 就是把服务器、网络、集群这些基础设施用声明式代码描述：进 Git 版本化、可评审、可重复执行、幂等。好处四个：环境一致（消灭'我这环境是好的'）、可审计回滚、能快速重建环境、配置不漂移。工具上我分两类记：供给类如 Terraform（管云资源 ECS/RDS/SLB 的创建销毁），配置管理类如 Ansible（管机器内部的状态）。我的实践：K8s 集群里所有 YAML/Helm values 全部进 Git，这本身就是 IaC 思想；节点初始化我用 Ansible playbook 批量下发内核参数；煌上煌交付时靠'文档+脚本+Git'让客户环境可以重建。

回答思路 · 考点拆解与追问预防

定义 + 好处 + 工具分类 + 自己例子，四段式。追问预防：Terraform 和 Ansible 的区别（有状态编排 vs 无状态配置管理、state 文件的作用）；幂等是什么意思（同一剧本重复执行结果一致）。

Q04 ｜通用题库

4. 你如何监控系统和应用性能？

我的回答 · 第一人称，结合简历

我按可观测三支柱搭：指标、日志、链路追踪，日常以指标为主。体系是 Prometheus + Grafana + Alertmanager：节点层 node_exporter（DaemonSet 方式跑），容器层 kubelet 内置的 cAdvisor，K8s 对象状态用 kube-state-metrics（Pod 重启次数、副本不一致、PVC 状态），应用层让服务暴露 /metrics 用 ServiceMonitor 接入。方法论上主机看 USE（利用率、饱和度、错误），服务看 RED（速率、错误、时延）。实习时维护 2 套 CDH 集群就是用这套东西定位过 CPU、内存、IO 瓶颈，输出扩容方案；下钻顺序是 top/vmstat/iostat 看资源层 → 定位到进程 → 再看 JVM（jstack/jstat）或应用日志。

回答思路 · 考点拆解与追问预防

展示体系化：三支柱 → 工具分层 → 方法论（USE/RED/黄金四指标）→ 一个实习实例收尾。只报工具名是最低分答法。追问预防：黄金四指标是什么（时延、流量、错误、饱和度）？你们告警阈值怎么定的？

Q05 ｜通用题库

5. 描述一下你如何实现自动化部署。

我的回答 · 第一人称，结合简历

我分两层做：应用层走流水线——GitLab CI 里提交触发，lint → 构建镜像（多阶段构建，tag 带分支+commit 短哈希）→ 推私有 Harbor → helm upgrade --install 滚动更新，K8s 的 readinessProbe 保证新实例就绪才接流量，maxSurge/maxUnavailable 控制节奏，失败 helm rollback；系统层走 Ansible/脚本——内核参数、运行时安装、目录初始化批量下发。实习时我把重复的部署巡检场景写成 Python/Shell 工具替代人工，这是我最直接的自动化产出。我认为自动化部署的两个不能省的配套是健康检查和回滚，否则自动化只是让事故发生得更快。

回答思路 · 考点拆解与追问预防

框架：触发 → 构建 → 部署策略 → 验证 → 回滚，闭环讲完。最后一句'健康检查+回滚'体现工程判断。追问预防：滚动更新的参数含义？回滚的原理（回到历史 ReplicaSet / 旧镜像 tag）。

Q06 ｜通用题库

6. 解释蓝绿部署和金丝雀部署。

我的回答 · 第一人称，结合简历

蓝绿：两套完全相同的环境，新版本先部署到备用（绿）环境，验证通过后把入口流量整体切换过去，回滚就是切回来，秒级，但资源要翻倍。金丝雀：新旧版本同时在线，先放小比例真实流量（比如 5%）到新版本，观察错误率、时延没问题再逐步放大到 100%，风险更小，但依赖监控指标和流量分流能力。K8s 里的落地：蓝绿可以用两个 Deployment + 改 Service selector 一键切换；金丝雀我用过 ingress-nginx 的 canary 注解按权重分流。选型：能接受资源翻倍、要求秒级回滚选蓝绿；用户量大、需要真实流量验证选金丝雀；实际大厂更多是金丝雀/灰度。

回答思路 · 考点拆解与追问预防

定义 → 流量切换方式 → 优缺点对比 → K8s 落地手段 → 选型建议，五步走完。追问预防：金丝雀阶段观察哪些指标？数据库 schema 变更和发布怎么解耦（这是灰度的真正难点）。

Q09 ｜通用题库

9. 描述一下如何管理配置和机密。

我的回答 · 第一人称，结合简历

K8s 里非敏感配置用 ConfigMap、敏感的用 Secret。我最强调的坑是：Secret 默认只是 base64 编码，不是加密——所以要么开启 etcd 静态加密（EncryptionConfiguration），要么对接 KMS/Vault；RBAC 严格控制谁能 get secret；绝对不把明文机密提交进 Git（可以用 gitleaks 在 CI 里扫描，用 sealed-secrets 或外部注入的方式管理）。另一个易错点：Secret 以环境变量注入时，更新后 Pod 要重建才生效；以文件挂载时会自动延迟刷新。传统机器上我用 .env 文件 + 600 权限 + 专用账号。镜像里绝不烘焙密钥，交付时密钥独立于部署包走加密通道。

回答思路 · 考点拆解与追问预防

加分点全在'Secret 不加密'和'env 注入不热更新'这两个真实坑上，说明真踩过。追问预防：Vault 的动态机密是什么；多环境配置怎么组织（values 分文件/overlay）。

Q10 ｜通用题库

10. DevOps 实践中的安全性如何保证？

我的回答 · 第一人称，结合简历

我按供应链、运行时、流程三块讲。供应链：私有 Harbor + 镜像漏洞扫描（Trivy）、多阶段构建减小攻击面、基础镜像固定版本、CI 里做密钥扫描（gitleaks）；运行时：K8s RBAC 最小权限、NetworkPolicy 限制东西向流量、容器非 root 运行 + readOnlyRootFilesystem、resource quotas 防资源耗尽；流程：所有变更走 MR 评审 + 审批，定期权限审计，密钥轮转。理念上我认同'安全左移'——把扫描和评审放进流水线最前面，问题越晚发现修复成本越高。实习交付离线环境时，我对端口暴露和防火墙规则做过一轮收敛，只放行必要端口。

回答思路 · 考点拆解与追问预防

三横（供应链/运行时/流程）+ 一纵（左移理念）。追问预防：容器逃逸了解吗（privileged、hostPID 的风险）；镜像扫描扫到高危但业务催发布怎么办（记录豁免+限期修复）。

Q50 ｜大厂真题·卷一

21. 你用过哪些开发语言？

我的回答 · 第一人称，结合简历

主力是 Python：写过部署/巡检自动化脚本和一些小工具——paramiko 批量执行、日志分析、巡检报告生成，用过 requests、fastapi 这些库；Shell 熟练，日常运维、cron 任务、CI 脚本都是 Shell；Java 是课程系统学的，能读代码，配合 jstack/jstat 做过 JVM 排障；Go 目前在'了解'级别——因为 K8s、etcd、Prometheus 全家桶都是 Go 写的，我在补 Go 以便读它们的源码。我的原则是语言为场景服务：要快速自动化用 Python，系统粘合用 Shell，读懂云原生源码靠 Go。

回答思路 · 考点拆解与追问预防

如实分级 + 每种语言绑定用途实例；'为了读 K8s 源码在学 Go'是运维岗很讨喜的姿态。追问预防：现场写一段 Python（比如批量 SSH 执行命令、解析日志统计 topN——提前练熟）；Python 的 GIL 了解吗。

Linux 系统

共 19 题

Q11 ｜通用题库

26. 如何设置内核参数？

我的回答 · 第一人称，结合简历

工具是 sysctl：临时改 sysctl -w net.ipv4.ip_forward=1；永久生效写 /etc/sysctl.d/99-k8s.conf 再 sysctl --system 加载，直接看所有参数 sysctl -a 或读 /proc/sys/ 目录。我实际调过的场景：搭 K8s 必开 ip_forward、bridge-nf-call-iptables（要先 modprobe br_netfilter）、关 swap；跑 Longhorn 存储时调过 fs.inotify 的 max_user_instances/max_user_watches，容器密集时不过这个会报 too many open files；HAProxy 预绑 VIP 需要 net.ipv4.ip_nonlocal_bind=1；高并发还会动 somaxconn、tw_reuse、nofile。每个参数我都能说清'为什么调'，这是排障攒下来的。

回答思路 · 考点拆解与追问预防

命令（临时 vs 永久）+ 一串自己真调过的参数和场景——后者才是区分度。追问预防：为什么 K8s 要关 swap（性能可预期、调度公平）；br_netfilter 是干嘛的（桥接流量也走 iptables）。

Q12 ｜通用题库

27. 解释什么是 RAID，以及不同 RAID 级别。

我的回答 · 第一人称，结合简历

RAID 把多块物理盘组织成逻辑卷，目标是性能、冗余或两者兼得。常见级别：RAID0 条带化，性能最高、无冗余，坏一块全丢；RAID1 镜像，写两份，空间利用率 50%；RAID5 分布式校验，至少 3 盘，坏 1 块可重建，适合读多写少；RAID6 双校验，可坏 2 块；RAID10 先镜像后条带，性能和冗余都高，数据库常选。运维视角再补三点：软 RAID 用 mdadm 创建，状态看 /proc/mdstat；RAID 卡要关注缓存策略和 BBU；生产建议配热备盘。选型一句话：日志/备份盘 RAID5/6 省空间，数据库这种怕丢又要性能的上 RAID10。

回答思路 · 考点拆解与追问预防

每个级别讲'机制+利用率+适用场景'三件事，最后给选型判断。追问预防：mdadm 怎么建（-C -l -n）；RAID10 和 RAID01 区别（先镜后条 vs 先条后镜，故障域不同）；坏盘后重建期注意什么（IO 压力、二次故障风险）。

Q13 ｜通用题库

28. 如何查找和终止僵尸进程？

我的回答 · 第一人称，结合简历

僵尸进程是子进程已退出、但父进程没有 wait() 回收，残留在进程表里的 PCB，状态为 Z，占 PID 资源。查找：ps aux | awk '$8 ~ /^Z/' 或 ps -eo pid,ppid,stat,cmd 过滤 Z 状态。处理的关键认知是：僵尸进程本身 kill 不掉，因为它已经死了，要处理的是它父进程——kill 父进程后子进程被 init/systemd 接管并回收。大量僵尸的根因一般是父进程代码没处理 SIGCHLD，要从应用侧修。和它区分开的是孤儿进程：父进程先退出、子进程被 init 收养继续跑，这是正常现象不是故障。

回答思路 · 考点拆解与追问预防

题眼一：Z 状态定义和成因；题眼二：'kill -9 僵尸无效'这个反直觉点；题眼三：孤儿 vs 僵尸的区别。追问预防：僵尸多了会怎样（PID 耗尽，fork 失败）；怎么从根上预防（父进程 waitpid/SIGCHLD handler）。

Q14 ｜通用题库

29. 解释什么是 SELinux 以及其作用。

我的回答 · 第一人称，结合简历

SELinux 是 Linux 内核级的强制访问控制（MAC）：给进程和文件都打安全上下文标签，由策略决定进程能不能访问资源——即使进程是 root，不符合策略也一样拒绝。三种模式：enforcing 强制拦截、permissive 只记日志不拦截（排障定位用）、disabled。常用命令：getenforce / setenforce 1|0 临时切换，永久改 /etc/selinux/config；看上下文 ls -Z，临时改 chcon，永久改用 semanage fcontext -a + restorecon 恢复。典型排障场景：服务换了个非标准端口或目录后起不来/403，audit.log 里有 AVC denied，用 sealert 分析；我一般先切 permissive 验证'是不是 SELinux 拦的'再定位。这块是 RHCE 考试重点，我当时系统练过。

回答思路 · 考点拆解与追问预防

概念（MAC+标签）→ 三模式 → 命令 → 一个排障套路（permissive 二分定位）。提 RHCE 是自然加分。追问预防：和 chmod 的区别（DAC vs MAC）；AppArmor 了解吗（基于路径的替代方案）。

Q15 ｜通用题库

30. 如何在 Linux 中配置 IP 地址？

我的回答 · 第一人称，结合简历

分临时和永久。临时：ip addr add 192.168.1.10/24 dev eth0、ip link set eth0 up、加网关 ip route add default via 192.168.1.1，立即生效重启丢失。永久按发行版走：CentOS/Rocky 传统是改 /etc/sysconfig/network-scripts/ifcfg-eth0（BOOTPROTO=static、ONBOOT=yes）然后 nmcli con up eth0，新版本统一用 nmcli con mod eth0 ipv4.addresses 192.168.1.10/24 ipv4.gateway ... ipv4.method manual，或 nmtui 图形化；Ubuntu 用 netplan，写 /etc/netplan/01-netcfg.yaml 后 netplan apply。DNS 配 resolv.conf 或由连接管理下发。配完我按固定链路验证：ip addr 看地址 → ip route 看路由 → ping 网关 → ping 公网 IP → nslookup 域名，一层层把问题定位在 IP/路由/DNS。

回答思路 · 考点拆解与追问预防

临时 vs 永久 + 各发行版差异（nmcli/netplan 是新趋势）+ 分层验证思路。追问预防：ping 不通网关怎么排查（链路、vlan、防火墙）；resolv.conf 被覆盖怎么办（PEERDNS、systemd-resolved）。

Q16 ｜通用题库

31. 解释 Linux 中的 LVM 是什么及其好处。

我的回答 · 第一人称，结合简历

LVM 在物理盘和文件系统之间加了一层抽象，三层结构：PV 物理卷（pvcreate /dev/sdb）→ VG 卷组（vgcreate 把多个 PV 池化成大空间）→ LV 逻辑卷（lvcreate 从 VG 里切空间格式化挂载）。好处：在线扩容不停服——我处理过数据盘不够：云上先扩云盘，然后 pvresize → lvextend -r +50G /dev/vg/data（-r 顺带同步扩文件系统）一条龙在线完成；快照做一致性备份（snapshot 是写时复制）；空间可以跨盘条带化；未来加盘直接 vgextend 进池子。注意 xfs 只能扩不能缩，缩容要先缩 fs 再缩 LV 且风险高。

回答思路 · 考点拆解与追问预防

三层结构讲清楚 + 在线扩容命令链（pvresize→lvextend -r）是最强实操信号。追问预防：快照原理（COW）；误删 PV 怎么救（vgcfgrestore）；为什么云主机推荐 LVM（盘可以在线扩）。

Q17 ｜通用题库

32. 解释什么是 NFS 以及如何配置它。

我的回答 · 第一人称，结合简历

NFS 网络文件系统，让多台机器像挂本地目录一样共享远端存储，常用于共享配置、Web 静态资源、备份目录。配置服务端：装 nfs-utils，写 /etc/exports：/data 192.168.1.0/24(rw,sync,no_root_squash)，然后 exportfs -rv 生效、systemctl enable --now nfs-server，防火墙放行 2049 和 rpcbind 相关端口。客户端：showmount -e 服务端IP 查看可挂载项，mount -t nfs server:/data /mnt，开机自动挂载写 /etc/fstab 并加 _netdev 参数。两个注意点：no_root_squash 允许客户端 root 以 root 身份写，有安全风险，默认的 root_squash 会压成匿名用户；NFS 性能和一致性弱于块存储，K8s 里一般用作低成本 ReadWriteMany 方案。

回答思路 · 考点拆解与追问预防

exports 格式 + 服务端/客户端命令完整走一遍 + 安全注意点。追问预防：squash 的含义；挂卡死怎么办（hard vs soft 挂载选项、umount -l/-f）；K8s 里 PV 用 NFS 的场景。

Q18 ｜通用题库

33. 如何使用 SSH 进行无密码登录？

我的回答 · 第一人称，结合简历

三步：ssh-keygen -t ed25519 生成密钥对（老环境用 rsa -b 4096）；ssh-copy-id user@host 把公钥追加到对端 ~/.ssh/authorized_keys；之后 ssh 走公钥认证不再要密码。排查不生效的要点：服务端 .ssh 目录必须 700、authorized_keys 必须 600、属主正确，否则 sshd 的 strictmodes 会静默拒绝；用 ssh -v 看详细握手过程定位。批量场景我会用 sshpass + 循环或者直接 Ansible 的 authorized_key 模块分发。我给 6 节点 K8s 集群做过免密跳板——这是几乎所有集群部署的第一步，后面 Ansible、分发证书都依赖它。

回答思路 · 考点拆解与追问预防

命令简单，得分点在权限排障（700/600/属主）和批量分发方案，最后落到自己集群的真实用途。追问预防：known_hosts 是什么；跳板机场景（ProxyJump）；密钥加了口令怎么免交互（ssh-agent）。

Q19 ｜通用题库

34. 描述 iptables 和 firewalld 之间的区别。

我的回答 · 第一人称，结合简历

两者都是内核 netfilter 的前端。iptables 传统工具：四表五链、规则自上而下顺序匹配，直改底层，规则量大后线性匹配性能下降；firewalld 是抽象管理层：按 zone（public/trusted 等）组织规则，以 service/port 为单位放行，运行时和永久配置分离（--permanent 之后还要 --reload），动态更新规则不中断现有连接，新系统底层已换成 nftables。我的用法：日常放行端口用 firewalld——firewall-cmd --add-service=https --permanent && firewall-cmd --reload；做 NAT、精细转发就直接 iptables。K8s 场景要注意：节点一般直接关 firewalld，避免和 kube-proxy/Calico 的规则互相干扰——我在煌上煌项目里就排查过 Docker 转发链丢失导致容器跨节点不通的问题，最后是重建转发链恢复的，所以我对这层规则的实际走向比较熟。

回答思路 · 考点拆解与追问预防

先说共同点（都是 netfilter 前端）再说抽象层级差异，最后用简历里的 iptables 真实案例收尾——这题答完面试官大概率顺着问那个故障。追问预防：四表五链是哪些；DOCKER-USER 链的作用。

Q20 ｜通用题库

35. 如何查找最消耗 CPU 的进程？

我的回答 · 第一人称，结合简历

快查：top（大写 P 按 CPU 排序）或 ps aux --sort=-%cpu | head。但我不会停在'找到进程'，会继续下钻：top -H -p PID 或 pidstat -t 1 定位到线程；再看它是用户态还是内核态——vmstat 1 里 us 高是应用逻辑问题，sy 高是系统调用/上下文切换问题，wa 高说明 CPU 在等 IO，真正瓶颈在磁盘；si/so 高是换页。确认进程身份用 ps -ef、ls -l /proc/PID/exe。Java 服务把线程号转 16 进制去 jstack 里对栈。实例：实习时 CDH 节点 CPU 高，追下去是 DataNode 所在盘 IO 慢导致的问题放大，最后靠的是加盘分摊 IO 而不是限 CPU。

回答思路 · 考点拆解与追问预防

命令只是入口，'进程→线程→上下文（us/sy/wa）'的下钻逻辑才是考点，结尾带一个真实案例。追问预防：load average 高但 CPU 空闲为什么（IO 等待也算 load）；us/sy/wa 各自含义。

Q22 ｜通用题库

37. 如何备份和恢复 Linux 系统？

我的回答 · 第一人称，结合简历

我分层做：配置与文件数据——脚本化 rsync 增量 + tar 全量，重要数据同步到异地或对象存储，rsync -av --delete 保证一致性；数据库类——MySQL 用 mysqldump 逻辑备份或 XtraBackup 物理热备；K8s 集群——核心是 etcd 快照：ETCDCTL_API=3 etcdctl snapshot save snap.db --endpoints=... --cacert/--cert/--key，恢复走 snapshot restore，我交付的环境把这个做成了 cron 定期任务并落 NFS；块设备层——LVM 快照 + dd，云上直接云盘快照。我的原则是'备份必须演练恢复'——没有验证过 restore 的备份等于没备份，所以巡检清单里有一项是抽查备份文件可解压、etcd 快照能在测试环境拉起。

回答思路 · 考点拆解与追问预防

分层 + 工具 + '备份要演练恢复'的意识句（这句很值钱）。etcd 快照对 K8s 岗位是高频加分。追问预防：rsync 增量原理（delta 传输）；etcd 恢复后要做哪些事（清 data 目录、成员信息、API server 指向）。

Q23 ｜通用题库

38. 如何设置定时任务（cron job）？

我的回答 · 第一人称，结合简历

用户级 crontab -e 编辑、-l 查看，格式五段：分时日月周 + 命令，比如 0 2 * * * /opt/scripts/backup.sh 每天凌晨两点跑备份。系统级任务写 /etc/crontab 或 /etc/cron.d/xxx（可以指定执行用户）。我踩过并会主动讲的坑：cron 的环境变量极简，PATH 和登录 shell 不一样，脚本里必须用绝对路径、显式 source 环境或定义 PATH，否则手动跑正常、cron 跑失败；排查看 /var/log/cron 和任务自己的输出重定向。秒级需求用 sleep 拼或 systemd timer。我的巡检、日志清理、备份脚本全都是 cron 驱动，输出统一落 /var/log/scripts/ 目录并在脚本内判断异常才告警。

回答思路 · 考点拆解与追问预防

格式必背 + 环境变量坑是区分度点 + 自己 cron 化的脚本例子。追问预防：cron 和 anacron 区别（错过执行是否补跑）；怎么防止任务重叠（flock 锁）。

Q24 ｜通用题库

39. 解释什么是虚拟内存以及如何配置它。

我的回答 · 第一人称，结合简历

虚拟内存给每个进程一套独立、连续的虚拟地址空间，由 MMU + 页表映射到物理内存，缺页中断按需加载，不够时把冷页换出到 swap。价值：进程隔离、允许超分配、单个进程可以用超过物理内存的地址空间。配置与调优：swap 大小——传统建议内存的 1-2 倍，现代服务器常给小 swap 甚至关闭；K8s 节点我一定 swapoff 并注释 fstab，因为交换会让时延不可预期、干扰资源调度；vm.swappiness——控制换出倾向，数据库类调到 1-10 尽量不换页；OOM 相关调 oom_score_adj 保护关键进程。判断指标：free 看 available（而不是 free 列，buff/cache 占多是正常且好的），vmstat 看 si/so，sar -B 看缺页。si/so 持续非零才是真内存压力。

回答思路 · 考点拆解与追问预防

概念→机制（页表/缺页/swap）→参数（swappiness/swapoff）→判断指标（available、si/so）。追问预防：为什么 K8s 要关 swap；OOM killer 怎么选牺牲者（oom_score）；buff/cache 能回收吗（能，kswapd/直接回收）。

Q86 ｜ 2026 最新搜集

软链接和硬链接的区别？

我的回答 · 第一人称，结合简历

硬链接：多个文件名指向同一个 inode，inode 里有链接计数，删一个名字只是计数减一，计数归零才真删数据。限制：不能跨文件系统（inode 号只在单个 fs 内有意义）、不能对目录建（防环）。软链接：是一个独立的新文件（有自己的 inode），内容存的是目标路径，可以跨文件系统、可以指向目录、目标删了就成悬空链接。查看：ls -l 看指向，stat 看 inode 和 Links 计数。运维场景：/var/log/containers 对 /var/log/pods 就是软链；磁盘迁移时用软链保持旧路径兼容；硬链接常用于备份去重（rsync 的 hardlink 保留快照）。

回答思路 · 考点拆解与追问预防

inode 计数、跨 fs、目录限制三个硬核差异点+两个真实场景。追问预防：删除原文件后两者表现（硬链正常、软链悬空）；为什么目录不能硬链接。

Q87 ｜ 2026 最新搜集

kill 和 kill -9 的区别？

我的回答 · 第一人称，结合简历

kill 默认发 SIGTERM（15），是'请求退出'：进程可以捕获信号、做清理（释放锁、刷缓冲、关连接）后体面退出，也可以选择忽略。kill -9 是 SIGKILL：内核直接终止进程，不可捕获不可忽略，进程没有任何清理机会——副作用可能是临时文件残留、锁没释放、共享内存段遗留、数据库类进程数据损坏风险。所以我的顺序永远是：先 TERM，给几秒宽限，不行再 KILL。补充：SIGKILL 和 SIGSTOP 是唯二不可捕获的信号；kill -9 对 D 状态（不可中断 IO 睡眠）进程无效，那种通常要查 IO 或存储故障。kubectl delete pod 走的也是先优雅终止（宽限期 terminationGracePeriodSeconds，默认 30s）再强杀的两段式。

回答思路 · 考点拆解与追问预防

信号语义（优雅 vs 强杀）+ 副作用 + '先 TERM 后 KILL'的操作纪律 + KILL 对 D 状态无效这个深点。

Q88 ｜ 2026 最新搜集

df 显示磁盘满了，但 du 找不到大文件，怎么回事？

我的回答 · 第一人称，结合简历

经典场景：文件已被删除，但仍被进程持有打开的句柄——Linux 下删除只去掉目录项，inode 和数据块要等最后一个引用（包括打开的文件描述符）释放才回收，所以 df（看文件系统块统计）显示占着，du（遍历目录）看不到。定位：lsof +L1 列出已删除但仍被占用的文件，按大小排序找到元凶进程。处置分两种：进程可重启就重启/ reload 释放句柄（比如某个服务狂写日志被 rm 了但不退出）；不能重启就清空而不是删：: > /proc/PID/fd/N 截断写。根因预防：删日志要用 truncate/copytruncate 模式的日志切割，或者让进程自己轮转——我处理过一次日志被 rm 但进程还开着句柄的案例，之后巡检清单里加了 lsof +L1 检查项。

回答思路 · 考点拆解与追问预防

'已删除但仍被占用'一句话破题 + lsof +L1 定位 + 两种处置 + 预防（日志切割姿势）。带一个自己处置过的实例更佳。

Q89 ｜ 2026 最新搜集

磁盘有余量却报 No space left on device？

我的回答 · 第一人称，结合简历

大概率是 inode 耗尽而不是数据块不足——df -h 看起来有空间，df -i 一看 IUse% 100%。成因通常是海量小文件（session 文件、缓存碎片、邮件队列、crontab 错误邮件堆积）。定位哪个目录最费 inode：df -i 确认分区 → for d in /var/*; do echo $d $(find $d -xdev | wc -l); done 数各目录文件数 → 到具体目录清理。另一个可能是文件系统被设了保留块（root reserved，ext 系默认 5%），普通用户在'满'之前就会报错，tune2fs -m 可调。预防：小文件业务独立分区+inode 配额、缓存目录定期清理进 cron。

回答思路 · 考点拆解与追问预防

df -i 这个命令就是题眼；成因、定位、备选原因（保留块）三层讲全。追问预防：inode 是什么（存元数据的对象）；怎么调 inode 数量（mkfs 时 ratio，不能事后调）。

Q90 ｜ 2026 最新搜集

free 显示可用内存很少，是内存不足吗？

我的回答 · 第一人称，结合简历

不是，看错了列。free 列少是正常且健康的——Linux 拿空闲内存做 buff/cache（页缓存）加速文件 IO，需要时立刻让出来。判断真不足要看 available 列：它估算的是'不给系统添麻烦的前提下还能给进程多少'。available 持续很低 + swap 的 si/so 持续非零（vmstat 看）才是真内存压力；再配合 sar -B 看缺页情况。内存耗尽的终点是 OOM killer，dmesg 里有 oom-kill 记录、进程神秘消失，可以 grep 'Out of memory' 确认。我的习惯：接到'内存告警'先 free -m 截图看 available，再看 si/so 和 dmesg，三步定性。

回答思路 · 考点拆解与追问预防

buff/cache 的语义 + available 才是准的 + si/so/dmesg 三步定性——把'读数'答成'诊断流程'。追问预防：buff 和 cache 区别；OOM killer 怎么选进程。

Q91 ｜ 2026 最新搜集

Load Average 是什么？多高算高？

我的回答 · 第一人称，结合简历

load 是运行队列 + 不可中断睡眠（D 状态）任务的平均数，1/5/15 分钟三个窗口。关键认知：D 状态（通常是 IO 等待）也计入，所以 load 高但 CPU 很闲，大概率是存储慢——这是它最有诊断价值的特性。判断标准不看绝对值，看 与 CPU 逻辑核数的比值：load ≈ 核数是满负荷临界，超过说明排队。比如 8 核机器 load 10 就是明显积压，再看 vmstat 的 r 列（运行队列）和 wa（IO 等待）分流：r 高是 CPU 瓶颈，wa 高查磁盘/NFS。容器时代注意：load 是宿主机全局的，节点上看到的 load 包含所有容器。

回答思路 · 考点拆解与追问预防

'D 状态也计入'是本题灵魂，直接导出'load 高 CPU 闲=IO 慢'的推论；比值判断+分流诊断完整闭环。

网络基础

共 5 题

Q84 ｜ 2026 最新搜集

TCP 三次握手，为什么不是两次？（vivo 一面 / 2026 高频）

我的回答 · 第一人称，结合简历

三次握手的核心目的是同步双方初始序列号并确认收发能力。为什么不是两次：① 两次无法让服务端确认'自己发的、客户端能收到'——客户端收发和服务端收发四个能力只验证了三个；② 更关键的是历史重复连接问题：网络里滞留的旧 SYN 到达服务端，两次握手会让服务端直接建立连接并分配资源，白白挂着等数据；三次握手下客户端会收到异常 ACK（旧的序列号），回 RST 掐掉。为什么不是四次：ACK 和 SYN 可以合并在同一个报文里，四次冗余。运维关联点：握手阶段的问题在云上常表现为 SYN Flood 攻击——内核参数 tcp_syncookies 就是防线，我在节点基线里会开。

回答思路 · 考点拆解与追问预防

三层递进：能力确认 → 历史连接（能否答出这一点是分水岭）→ 为什么不是四次。结尾带一个运维参数（syncookies）把网络题拉回本职。追问预防：SYN Flood 怎么防（syncookies、syn backlog）；ISN 为什么要随机（防猜测伪造）。

Q85 ｜ 2026 最新搜集

TIME_WAIT 和 CLOSE_WAIT 的区别？大量出现分别说明什么？

我的回答 · 第一人称，结合简历

TIME_WAIT 出现在主动关闭一方，时长 2MSL，目的：保证最后一个 ACK 对方能收到（丢了可重发）、让旧连接的报文在网络里自然消亡，防止污染新连接。大量 TIME_WAIT 通常是本机主动发起了海量短连接（比如爬虫、压测、频繁连后端），本身不是 bug，但会占用端口资源——优化：开 tcp_tw_reuse（仅客户端方向）、长连接改造（keepalive/连接池）。CLOSE_WAIT 出现在被动关闭一方，收到对端 FIN 回了 ACK 之后、自己还没调用 close 的窗口。大量 CLOSE_WAIT 几乎必然是应用代码泄漏——没关连接，排查定位到进程：ss -tan state close-wait 或 lsof -i:port 看是哪个服务，修代码才是根治。一句话总结：TIME_WAIT 是设计如此，CLOSE_WAIT 是程序有病。

回答思路 · 考点拆解与追问预防

两个状态各自的位置、成因、处置完全对立——这个对比结构就是满分答案。最后一句总结很容易被面试官记住。追问预防：2MSL 多长、为什么是 2 倍；tw_reuse 和 tw_recycle 的区别（recycle 在 NAT 下有坑已移除）。

Q93 ｜ 2026 最新搜集

正向代理和反向代理的区别？

我的回答 · 第一人称，结合简历

看'代理谁'：正向代理代理客户端——服务器不知道真实客户端是谁，典型是公司出口代理、科学上网、爬虫代理池；反向代理代理服务端——客户端不知道真实后端是谁，典型是 nginx/HAProxy 做负载均衡、TLS 终止、缓存。运维视角反向代理是我们的日常：入口层 nginx 转发到后端 tomcat/上游服务，配 upstream 池、健康检查、超时和重试（proxy_next_upstream）。安全性上两者都能隐藏一端，正向代理常配 ACL 做访问控制，反向代理配 WAF 和限流。

回答思路 · 考点拆解与追问预防

一句'代理谁'定胜负+两列典型场景+回到自己最熟的 nginx upstream。

Q94 ｜ 2026 最新搜集

502 和 504 的区别？502 怎么排查？（字节真题）

我的回答 · 第一人称，结合简历

504 Gateway Timeout：网关等后端响应超时——后端还在跑但太慢（慢 SQL、下游阻塞、超时设置太短）。502 Bad Gateway：网关连不上后端或后端给了无效响应——后端挂了、没监听、连接被拒、进程崩溃中。502 排查链：① 先看后端进程活着吗：目标端口 ss -lnt / 进程 ps——起不来就看应用日志和系统日志（OOM：dmesg 查 oom-kill）；② proxy_pass 地址对不对：写错端口、DNS 解析失败（容器环境经典：解析到旧 IP）；③ 超时参数：proxy_connect_timeout 太小、后端 accept 队列满（somaxconn/backlog）；④ 中间层：防火墙/安全组、SELinux、连接数限制；⑤ K8s 场景换成：Endpoint 是否为空（探针失败全摘）→ Pod 就绪状态 → svc 选择器标签。定位手段 curl 直接打后端绕过网关逐段二分。我实习处理过工单里的 502：多数是后端 OOM 重启窗口期网关拿到 connection refused。

回答思路 · 考点拆解与追问预防

先讲语义差异（超时 vs 连不上/无效响应）再给分层排查链+二分手段；K8s 分支（Endpoint 空）是云原生加分。追问预防：502 间歇性出现怎么查（后端重启循环、连接池耗尽）。

Q105 ｜ 2026 最新搜集

LVS 四种模式的区别？（vivo 一面）

我的回答 · 第一人称，结合简历

四种模式按'改什么'记：NAT——改目标 IP（进）+源 IP（回），RS 网关指向 LVS，双向都过 LVS，LVS 易成瓶颈，但 RS 不需要公网 IP、配置最简单；DR（直接路由）——只改 MAC 帧：LVS 把请求帧的目标 MAC 改成 RS 的 MAC 直接丢给同网段的 RS，RS 处理后以自己的 VIP（配在 lo 上）为源直接回客户端，不经过 LVS——性能最好，要求 LVS 和 RS 同二层、RS 要配 VIP+ARP 抑制；TUN——IP 隧道封装，RS 收到解封后直接回，跨网段可行，RS 也要配 VIP；FULLNAT——进改目标、回改源，RS 不需要配网关和 VIP，LVS 和 RS 可跨网段，代价是 RS 看到的源 IP 是 LVS 的（需 TOA 透传真实 IP）。生产上 DR 用得最多。我项目里的 HAProxy（四层也做）对应的是用户态代理，和 LVS 内核态转发相比性能低但功能灵活。

回答思路 · 考点拆解与追问预防

按'改什么/回程走哪'两条线记四种模式；DR 的 lo 上配 VIP+ARP 抑制是细节题；结尾对比 HAProxy 展示全局观。追问预防：ARP 抑制怎么做（arp_ignore/arp_announce）。

Shell 脚本

共 5 题

Q25 ｜通用题库

75. 如何在 Shell 脚本中操作字符串？

我的回答 · 第一人称，结合简历

我常用两组。内置参数展开（快、无子进程）：${var##*/} 取文件名（去最长前缀）、${var%.*} 去后缀取主名、${var/old/new} 替换第一个、${var//old/new} 全替换、${#var} 取长度、${var:0:5} 截取、${var:-default} 变量为空时给默认值。外部工具：cut -d: -f1 按列取、awk -F 分隔处理、sed 's/a/b/g' 替换。实例：我的巡检脚本里，日志文件名拼接 logfile=app_$(date +%F).log，取后缀判断类型用 ${file##*.}，输出对齐用 printf 而不是 echo。面试手写高频：把'hello world'反转或替换，我习惯先想参数展开再做 sed。

回答思路 · 考点拆解与追问预防

背熟 5 个以上参数展开操作符 + 每个给 micro 例子；# 与 % 的方向（#从头删、%从尾删、双写=最贪婪）是细节题。追问预防：printf 和 echo 区别；怎么判断变量是否存在/为空（-z/-n 与 :- 默认值）。

Q26 ｜通用题库

76. 解释如何在 Shell 脚本中处理文件和目录。

我的回答 · 第一人称，结合简历

判断：[ -f file ] 普通文件、[ -d dir ] 目录、[ -e ] 存在、[ -r/-w/-x ] 权限。遍历：for f in /path/*.log; do ... done（注意 nullglob，无匹配时通配符原样传入）或用 find。批量操作经典组合：find /var/log -name '*.log' -mtime +7 -delete 删 7 天前日志；find ... -exec cmd {} \; 或 find ... | xargs 处理特殊文件名时加 -print0 | xargs -0。目录操作 mkdir -p、cp -a、rsync -av。实例：我的日志清理脚本就是 find -mtime +N -delete + crontab；部署脚本开头 [ -d bak ] || mkdir -p bak 再做备份；巡检脚本 for 循环遍历 /etc/sysctl.d 与 nginx 配置做语法检查。

回答思路 · 考点拆解与追问预防

测试运算符 + find 三件套（-name/-mtime/-size）+ xargs 空格陷阱 + 日志清理这个万能实例。追问预防：-exec 和 xargs 区别（每文件 fork vs 批量传参）；for 通配符无匹配的坑。

Q27 ｜通用题库

77. 如何在 Shell 脚本中使用正则表达式？

我的回答 · 第一人称，结合简历

主力三件：grep -E、sed -r、awk。基础元字符 ^ $ . * [] [^] + ? {n,m} () |；进阶 \b 单词边界、后向引用。实战例子：grep -E 'Failed password' /var/log/secure 统计爆破来源；awk -F'|' '$2==8' file 提取分隔符为 | 时第二列等于 8 的行（字节真题原题）；给文件每行行首加内容：sed -r 's/^/head /' file（也是字节真题）；提取 IP：grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}'。一个必讲的细节：BRE 和 ERE 转义不同——+、?、() 在基础正则里要加反斜杠，所以我统一加 -E/-r 用扩展正则，避免两套记法打架。nginx 日志分析 top10 IP 这种题我张口就来：awk '{print $1}' access.log | sort | uniq -c | sort -rn | head。

回答思路 · 考点拆解与追问预防

元字符清单 + ERE/BRE 转义差异（细节加分）+ 日志分析实战组合链（sort|uniq -c|sort -rn|head 必须手写熟练）。追问预防：贪婪匹配怎么控制（.*? 在 sed 里不支持，换思路）；grep -o 的作用。

Q28 ｜通用题库

78. 解释 Shell 脚本中的 I/O 重定向和管道。

我的回答 · 第一人称，结合简历

三个标准流：0 stdin、1 stdout、2 stderr。重定向：> 覆盖、>> 追加、2> 只收错误、2>&1 把错误并入输出（注意顺序，必须写在 1>log 之后，或者直接 >log 2>&1 / &>log）、2>/dev/null 丢弃、< 文件输入、<<'EOF' heredoc（引号防变量展开）。管道把上一个命令的 stdout 接到下一个的 stdin：ps aux | grep nginx | awk '{print $2}'。tee 双路：cmd | tee a.log 既上屏又落盘，调试定时任务特别有用。我脚本的标准开头是 exec >> $LOG 2>&1，把整个脚本输出统一落日志，cron 排障全靠它。经典组合链：sort | uniq -c | sort -rn | head 做计数排行。

回答思路 · 考点拆解与追问预防

2>&1 的书写顺序是最高频细节题；heredoc 加引号防展开是二线考点；用 exec 收脚本日志体现工程习惯。追问预防：>file 2>&1 和 2>&1 >file 区别（后者顺序错误，stderr 还是去了终端）；管道里拿退出状态（PIPESTATUS）。

Q29 ｜通用题库

79. 如何确保 Shell 脚本的安全性？

我的回答 · 第一人称，结合简历

我的固定清单：set -euo pipefail 开头三件套——遇错即停、未定义变量报错、管道任一环节失败即失败；所有变量引用加双引号防分词和路径注入；绝不 eval 不可信输入，不把输入拼进 find/xargs/ssh 命令串（xargs 用 -0，或改 -- 参数分隔）；危险命令防呆——rm 前判空 [ -n "$dir" ] && [[ "$dir" = /data/* ]]，路径变量 readonly 固定；最小权限运行——专用账号 + sudo 白名单而不是 root 跑；敏感信息不硬编码，从环境变量或 600 权限的独立配置读；脚本本身放只读目录防篡改、加幂等设计（重复执行不出事）；上线前过 shellcheck 静态扫描。我交付环境的脚本都按这套走完再挂 cron。

回答思路 · 考点拆解与追问预防

set -euo pipefail + 引号 + 不 eval + 最小权限 + shellcheck，五件套齐了就是满分框架；'幂等设计'是运维视角的加分句。追问预防：set -e 在管道和函数里的坑（可以提 pipefail 的必要性）；shellcheck 报 SC2080 是什么（未加引号的变量）。

K8s 与容器

共 31 题

Q07 ｜通用题库

7. 什么是容器化？Docker 是如何工作的？

我的回答 · 第一人称，结合简历

容器化是把应用连同它的依赖、运行时打包成标准镜像，以隔离的进程方式运行的技术。Docker 的工作原理三个关键词：Namespace 做资源视图隔离（pid、net、mount、uts、ipc、user），Cgroups 限制 CPU/内存配额，UnionFS（OverlayFS） 分层存镜像——容器层可写、镜像层只读，所以镜像可以共享和增量分发。所以容器本质是'隔离的进程组'，不是轻量虚拟机，它共享宿主机内核，这正是它秒级启动、高密度的原因，也是隔离性弱于 VM 的原因。实践中我写多阶段 Dockerfile 控制体积，实习离线交付时处理过镜像拉取失败——需要预导入客户私有 Harbor 或 docker load。

回答思路 · 考点拆解与追问预防

核心词 namespace + cgroups + unionFS 一个都不能少，再对比 VM 引出共享内核的利弊。追问预防：容器和 VM 的安全边界；docker save/load 和 export/import 区别。

Q08 ｜通用题库

8. 解释 Kubernetes 的工作原理和它的主要组件。

我的回答 · 第一人称，结合简历

我分控制面和节点两层讲。控制面：apiserver 是集群唯一入口，负责认证、鉴权、准入，所有读写必经它；etcd 存储所有对象的期望状态；scheduler 负责把未调度的 Pod 通过预选（Filter）+ 打分（Prioritize）绑定到节点；controller-manager 是一组控制器，靠调和循环不断让实际状态逼近期望状态。节点：kubelet 管理本节点容器生命周期，通过 CRI 对接 containerd；kube-proxy 维护 Service 的负载均衡规则。整体是声明式面向终态的架构：我声明 Deployment 副本数是 3，控制器就持续保证 3 个健康副本，节点挂了会在别的节点重建。组件间通信用 list-watch 机制，不互相直连。我搭的 3 主 3 工作节点集群上，还给 apiserver 加了 Keepalived+HAProxy 做 VIP 高可用，避免控制面单点。

回答思路 · 考点拆解与追问预防

两层讲组件职责 → 落到'声明式+调和循环'思想 → 带出自己的 HA 架构。追问预防：scheduler 两个阶段各考虑什么；etcd 为什么适合（watch 机制、Raft 强一致）；apiserver 挂了集群会怎样（已运行 Pod 不受影响，但不能变更）。

Q21 ｜通用题库

36. 解释什么是 Docker 容器以及它与虚拟机的区别。

我的回答 · 第一人称，结合简历

容器是共享宿主机内核、靠 namespace 隔离视图、cgroups 限额的进程组；虚拟机由 Hypervisor 虚拟出完整硬件，每个 VM 跑独立内核。差异三句话：隔离性——VM 有硬边界，容器共享内核，逃逸风险相对高，所以多租户强隔离场景用 VM；开销——容器秒级启动、MB 级内存开销，VM 分钟级、GB 级；密度——单机容器密度可以很高，适合微服务和弹性伸缩。真实生产基本是两者结合：云上 ECS（VM）里跑 K8s，容器负责交付效率，VM/云主机负责资源隔离边界。我实习的私有化平台也是这个形态。

回答思路 · 考点拆解与追问预防

关键词'共享内核 vs 独立内核'推出安全与性能的取舍，再落到'VM+容器混合'的真实生产形态。追问预防：Windows 容器为什么存在（内核不同）；容器安全加固手段（非 root、seccomp、CapDrop）。

Q31 ｜大厂真题·卷一

2. K8s 常用的指令？

我的回答 · 第一人称，结合简历

我按日常操作分类说。排查类：kubectl get pods -o wide、describe pod（看 Events）、logs -f 和 logs --previous（看上一次崩溃的日志）、exec -it -- sh、top nodes/pods。变更类：apply -f、edit、scale、rollout status / history / undo、delete。网络对象：get svc / ep / ingress。节点管理：get nodes、cordon/uncordon、drain（驱逐前会自动 cordon）、taint。上下文与命名空间：config get-contexts / use-context、-n/--all-namespaces。辅助：explain 查字段、--watch 持续观察。我排查 Pod 异常有固定的三板斧：get 看状态 → describe 看 Events → logs 看应用输出，90% 的问题这三步能定位到方向。

回答思路 · 考点拆解与追问预防

分类报命令比背清单有条理；describe 看 Events、logs --previous、drain 会自动 cordon 这类细节是'真用过'的信号。追问预防：怎么进入没有 sh 的镜像（kubectl debug 临时容器）；怎么查 Pod 实际资源用量（top 背后是 metrics-server）。

Q32 ｜大厂真题·卷一

3. K8s 的 Ingress 网关？

我的回答 · 第一人称，结合简历

Ingress 是 K8s 的七层路由资源：按域名和路径把 HTTP/HTTPS 流量路由到不同 Service，并支持 TLS 终止、虚拟主机、会话保持这类能力。要点是 Ingress 本身只是'规则声明'，真正干活的是 Ingress Controller（ingress-nginx、Traefik、HAProxy Ingress 等）——controller 以 Pod 形式跑在集群里，watch Ingress、Service、Endpoint、Secret 这些对象的变化，动态生成数据面的转发配置。外部流量先经过 LB/NodePort 到 controller，再按规则进后端 Pod。四层负载和对外暴露我们用 Service（NodePort/LoadBalancer）或者我项目里用过的 MetalLB——它给裸金属集群提供 LoadBalancer IP。

回答思路 · 考点拆解与追问预防

题眼一：区分'Ingress 资源'和'Ingress Controller'（很多人混）；题眼二：能讲 watch→生成配置→流量路径。追问预防：Ingress 和 Service 的关系；TCP/UDP 四层怎么暴露（Ingress 的 tcp-services ConfigMap 或 LB 直通）。

Q33 ｜大厂真题·卷一

4. Ingress 你用过哪些资源（字段）？

我的回答 · 第一人称，结合简历

我常配的几块：路由规则 spec.rules 的 host + path + backend（service name/port）；TLS：spec.tls 引用 secret 里的证书做终止；注解用得最多——nginx.ingress.kubernetes.io/rewrite-target 做 URL 重写、proxy-body-size 放开上传限制、proxy-connect-timeout / proxy-read-timeout 调超时、limit-rpm 限速，还有 canary-weight 做金丝雀权重分流；defaultBackend 兜底后端；ingressClass 标识归哪个 controller 管。加 TLS 时踩过的细节：secret 类型必须是 kubernetes.io/tls，且证书和 host 要匹配，否则 controller 日志里会报 PEM 错误。

回答思路 · 考点拆解与追问预防

这题考'是不是真配过'——能报出具体 annotation 名字就是用过；canary-weight 可以主动提，把话题引向金丝雀（自己熟的领域）。追问预防：一个 Ingress 挂多域名怎么写；rewrite-target 配合正则捕获组的用法。

Q34 ｜大厂真题·卷一

5. K8s 创建 Pod 的流程？

我的回答 · 第一人称，结合简历

以 kubectl apply 一个 Deployment 为例走全链路：kubectl 提交到 apiserver（认证→鉴权→准入控制）→ 对象写入 etcd → Deployment 控制器 watch 到新对象，创建 ReplicaSet → RS 控制器创建 Pod（此时没有节点，状态 Pending）→ scheduler watch 到未调度的 Pod，先预选（Filter：资源够不够、亲和性、taint 容忍）再打分（Prioritize）选出节点，把 nodeName 写回 Pod → 目标节点的 kubelet watch 到'属于我'的 Pod，通过 CRI 调 containerd 拉镜像、创建 pause 沙箱和业务容器，之后按探针管理健康。整条链路是事件驱动的 list-watch，组件之间不直接调用，全部围绕 etcd 里的期望状态解耦。

回答思路 · 考点拆解与追问预防

全链路顺序 + 每个组件一句话职责 + 'watch 机制解耦'收尾。这是 K8s 必考的骨架题，能顺手提预选打分两阶段就超过平均水准。追问预防：image 拉不下来卡在什么状态（ImagePullBackOff，describe 看）；谁负责重启 Pod（kubelet）。

Q35 ｜大厂真题·卷一

6. K8s 常用控制器？

我的回答 · 第一人称，结合简历

五个常用：Deployment——无状态应用部署+滚动更新，底层靠 ReplicaSet 管副本；StatefulSet——有序启停、稳定的网络标识和独立存储，数据库、中间件类用；DaemonSet——每个节点跑一个，日志采集器和监控 agent 的标准姿势，我环境里 Filebeat 和 node_exporter 就是 DaemonSet；Job / CronJob——一次性和定时任务，我的备份、巡检脚本都跑在 CronJob 里；再往上是 HPA 按指标自动扩缩容。选择逻辑一句话：无状态 Deployment、有状态 StatefulSet、节点级 DaemonSet、任务 Job/CronJob。

回答思路 · 考点拆解与追问预防

每个控制器讲'解决什么问题+我的使用场景'，比背定义有说服力。追问预防：StatefulSet 稳定在哪（podName 固定、PVC 跟着 pod 走不跟 ReplicaSet）；滚动更新参数；Job 失败重试（backoffLimit）。

Q36 ｜大厂真题·卷一

7. 收集日志你会用什么控制器？

我的回答 · 第一人称，结合简历

日志采集 agent 我用 DaemonSet：保证每个节点恰好一个采集器（Filebeat / Fluent Bit），挂载宿主机的 /var/log/pods 和 /var/log/containers 目录采集容器日志，汇聚后发 Kafka/ES。这样做的理由：Pod 调度到任何节点都有 agent 兜底、和业务容器生命周期解耦、采集器故障只影响本节点。另一种是 sidecar 模式——每个业务 Pod 旁边挂一个采集容器，隔离性好但资源开销大；K8s 1.21+ 之后官方有原生 Sidecar 容器特性改进了这块的启动顺序和回收问题。我们交付环境用的是 Filebeat DaemonSet，自己的集群里 node_exporter 也是同样的部署思路。

回答思路 · 考点拆解与追问预防

DaemonSet + 挂载路径 + 和 sidecar 的取舍。这题和下一份卷子的'Pod 日志在宿主机哪里'是连环题，路径要背熟。追问预防：sidecar 和 DaemonSet 各自优缺点；怎么只采集特定 namespace 的日志（label/namespace 过滤）。

Q47 ｜大厂真题·卷一

18. 你们有几套 K8s 集群？

我的回答 · 第一人称，结合简历

如实说：实习的私有化交付场景，我参与的是 3 套客户平台，每套含测试、生产两个小集群，单集群 6-10 个节点的规模；另外我自己维护一套 3 主 3 工作节点的实验集群。企业里多集群的常见切分维度：按环境（dev/test/staging/prod）、按业务线隔离、按合规要求（金融类物理隔离）、或按地域容灾。

回答思路 · 考点拆解与追问预防

应届不要虚报'几十个节点的大规模'，交付场景多套环境+自己集群的事实讲清楚即可；主动展示对多集群切分维度的理解，自然引出下一题'为什么多套'。追问预防：多集群应用怎么统一管理（ArgoCD/多集群 kubeconfig）；你们两套集群配置怎么保持一致。

Q48 ｜大厂真题·卷一

19. 说一下你们为什么要用两套 K8s 集群？

我的回答 · 第一人称，结合简历

核心是隔离，拆四个维度：① 环境隔离——测试集群承接变更、压测、演练，爆炸半径不外溢；② 故障隔离——测试环境升级组件或做混沌演练，不影响生产 SLA；③ 权限与流程隔离——生产集群 RBAC 收紧、变更走审批，测试集群相对宽松提效；④ 版本灰度——新的 K8s 版本、CNI、存储组件先在测试环境完整验证再进生产。我们私有化交付就是这个模式：给客户建独立测试+生产两套，像 Longhorn 升级这种高风险操作，一定是测试环境完整演练通过后才敢进生产。代价也要讲：资源翻倍、配置容易漂移，所以必须用 IaC（Helm values + Git）保证两套环境的一致性。

回答思路 · 考点拆解与追问预防

四个隔离维度 + 自己交付场景的例子 + 主动说代价与应对（一致性管理）——讲出代价说明真运营过。追问预防：测试和生产除了规模还有什么差异（数据脱敏、监控强度、日志保留）。

Q51 ｜大厂真题·卷二

1. 说一下 K8s 基础架构吧。

我的回答 · 第一人称，结合简历

我分两平面讲。控制面四个组件：apiserver——集群唯一入口，认证/鉴权/准入都在这，所有组件只和它通信；etcd——分布式 KV，存全部对象的期望状态和当前状态，Raft 保证一致性；scheduler——watch 待调度 Pod，预选+打分选节点；controller-manager——一组控制器（Deployment/RS/Node...）靠调和循环把实际状态拉向期望。节点面：kubelet——节点代理，通过 CRI 指挥 containerd 管理容器生命周期、执行探针；kube-proxy——在每个节点维护 Service 的转发规则；还有 CNI（我用的 Calico）负责 Pod 网络。通信模型是 list-watch：所有组件 watch apiserver 的资源变化事件，互相不直连。高可用上：控制面多副本（3 master）+ 前置 LB 给 apiserver，etcd 3/5 节点保 quorum——我自己集群就是 3 master + Keepalived/HAProxy VIP 的形态。

回答思路 · 考点拆解与追问预防

两平面组件职责 → list-watch 通信模型 → HA 形态收尾（带出自己集群）。这题是全场地基，讲稳了后面所有 K8s 追问都有支点。

Q53 ｜大厂真题·卷二

3. 你们集群规模有多大？

我的回答 · 第一人称，结合简历

如实：实习交付的单套集群是 6-10 个节点的中小规模，跑数据平台组件和中间件；我自己实验集群 3 master + 3 worker。规模不大，但我把'节点数不大、复杂度在别处'讲清楚：私有化交付的难点是离线环境、异构硬件、客户网络限制，以及 CDH 大数据这类重状态应用和 K8s 的混合运维，这些我全程亲手做过。

回答思路 · 考点拆解与追问预防

应届最忌虚报节点数被追问细节击穿。用'规模如实+复杂度维度'的话术把价值讲出来。追问预防：节点配置（CPU/内存/盘）、Pod 数量级、etcd 大小——提前给自己集群的真实数字。

Q54 ｜大厂真题·卷二

4. 你们主要上面跑什么应用？

我的回答 · 第一人称，结合简历

私有化数据平台的典型构成：大数据组件——CDH 体系的 HDFS/Yarn/Hive/Spark 任务，Airflow 类调度；中间件——MySQL、Redis、Kafka；平台自身服务——Web 管理控制台、API 服务、前端静态资源。我自己集群跑的是监控栈（kube-prometheus 全家桶）、业务实验应用。不同类型负载的关注点不一样：计算型看资源和队列，有状态中间件看存储和稳定性，Web 服务看发布和探针。

回答思路 · 考点拆解与追问预防

报'构成分类'而不是零散名词；最后一句'不同负载关注点不同'体现运营视角。

Q55 ｜大厂真题·卷二

5. 都是 Java 服务吗？

我的回答 · 第一人称，结合简历

不是，混合栈：大数据组件多数是 JVM 系（Hadoop/Hive/Spark），平台服务里有 Python（调度、我自己写的工具）、Go（云原生组件：ingress-nginx、Prometheus 都是 Go），前端是静态资源。运维上这对监控方式有直接影响：JVM 应用接 jmx_exporter 或 Micrometer 暴露指标，重点看 GC、堆、线程；Python/Go 服务直接暴露 /metrics 或用 process exporter 兜底；日志层面统一走 Filebeat，无差别。

回答思路 · 考点拆解与追问预防

答'不是'+构成+引申到'不同语言监控方式差异'——把事实题答出技术深度。追问预防：JVM 排障工具链（jstack/jstat/arthas）。

Q56 ｜大厂真题·卷二

6. 那你们 K8s 集群那个网关用什么？

我的回答 · 第一人称，结合简历

入口分两层：客户环境最外层是硬件/软件 LB 或云 SLB，把流量导到集群边界；集群内七层网关用 ingress-nginx。我自己的裸金属集群没有云 LB，用 MetalLB 在二层宣告 VIP，给 ingress controller 的 Service 提供 LoadBalancer IP；另外控制面还有一层网关：Keepalived+HAProxy 给 apiserver 做 VIP 高可用，这个和业务网关是分开的两套东西。

回答思路 · 考点拆解与追问预防

分清'业务流量入口'和'控制面 apiserver 入口'两层网关是本题隐性考点，很多候选人混着说。

Q57 ｜大厂真题·卷二

7. 我说的是那个 Ingress 控制器是用什么？

我的回答 · 第一人称，结合简历

ingress-nginx。选型理由：nginx 数据面生态最成熟、annotation 丰富（重写、超时、限速、canary 权重都有现成注解）、排障资料多，团队学习成本低。了解过的替代品：Traefik——原生云原生设计、自带 ACME 证书、配置更现代；HAProxy Ingress 性能好；Envoy 系（比如 Istio IngressGateway）一般在服务网格场景用。我们中小规模+团队熟悉的权衡下选了 ingress-nginx。

回答思路 · 考点拆解与追问预防

给出主选+理由+替代品矩阵，体现'做过选型思考'而不是'项目用啥我说啥'。

Q58 ｜大厂真题·卷二

8. 它的基础实现逻辑你有了解吗？配完资源之后 Nginx 就可以实现流量转发，这块有了解吗？

我的回答 · 第一人称，结合简历

了解，讲三层：① 配置生成：ingress-nginx controller 里跑着 nginx 和一个 Go 控制器，list-watch Ingress、Service、Endpoints、Secret 对象，任何变化就重新渲染 nginx 配置模板；② 动态 upstream：后端地址不是写死的——它用 lua 模块维护 upstream 列表，Pod 扩缩容时只更新 lua 里的 endpoint，不用 reload nginx，只有配置结构变化（新域名、证书变更）才触发 reload，这就避免了 reload 造成连接抖动；③ 流量路径：客户端 → LB/MetalLB VIP → controller 的 Service（NodePort/LB）→ controller Pod 里的 nginx → 按 host/path 匹配 server/location → proxy_pass 直连后端 Pod IP:Port（从 Endpoints 拿，不再绕 kube-proxy 的 Service 一层，减少一跳）。TLS 证书从引用的 Secret 挂载加载。

回答思路 · 考点拆解与追问预防

这是本卷的分水岭题。三层讲全（watch 渲染 / lua 动态 endpoint 免 reload / 直连 Pod IP 不绕 Service）基本就是满分；答不全至少保住'watch + 生成配置 + 流量路径'主干。追问预防：reload 时连接会断吗（优雅 reload，长连接会重置）；为什么直连 Pod IP（少一跳 DNAT、支持长连接保持）。

Q65 ｜大厂真题·卷二

15. kube-proxy 有几种代理方式？工作模式有几种？

我的回答 · 第一人称，结合简历

三种：userspace——最早的版本，流量先到用户态 kube-proxy 再转发，性能差，基本绝迹；iptables——默认模式，kube-proxy 在每个节点写 iptables 规则，KUBE-SERVICES 链里按概率随机 DNAT 到某个 Pod IP，纯内核态转发性能好，但规则是线性匹配，Service 上千后规则同步慢、查找 O(n)；ipvs——内核 IPVS 模块，哈希表查找 O(1)，支持 rr/lc/dh/sh/sed/nq 等十来种调度算法，大规模 Service 首选，依赖 ip_vs 系列内核模块（kube-proxy 会自动 modprobe）。切换就是 kube-proxy 配置里的 mode 字段。

回答思路 · 考点拆解与追问预防

三种+各自优缺点+切换方式。追问预防：ipvs 模式还用 iptables 吗（还用，做 masquerade/mark 等少量辅助规则）；为什么 iptables 大规模慢（全量刷新、链式遍历）。

Q66 ｜大厂真题·卷二

16. Service 主要通过什么来实现呢？创建一个 SVC，它的实现逻辑是由谁来完成的？

我的回答 · 第一人称，结合简历

由每个节点上的 kube-proxy 完成。过程：kube-proxy watch apiserver 里 Service 和 Endpoints 对象的变化 → 在本机写转发规则（iptables 或 ipvs）→ 以 iptables 模式为例：访问 ClusterIP:Port 的包在 PREROUTING/OUTPUT 钩子进入 KUBE-SERVICES 链，匹配后 DNAT 成某个后端 Pod IP:Port → 回包靠 conntrack 记录做反向还原。两个有价值的推论：ClusterIP 是虚拟 IP，没有网卡响应它的 ARP，所以 ping ClusterIP 不通但 curl 通（iptables 规则只匹配 TCP/UDP，ICMP 没被 DNAT）——这是经典排障认知题；Endpoints 由独立的 endpoint 控制器维护，只挂健康的 Pod（readiness 失败的会被摘除）。

回答思路 · 考点拆解与追问预防

kube-proxy watch→写规则→DNAT 全链路；'ping 不通 curl 通'这个推论是这题最亮的加分点，主动说出来。

Q67 ｜大厂真题·卷二

17. kube-proxy 有好几种工作方式，你们一般是用什么方式？

我的回答 · 第一人称，结合简历

我们用 ipvs。理由：交付环境里 Service 数量到几百个量级，iptables 模式下每次 Service 变更要全量刷规则、节点上有可感知的同步延迟，ipvs 哈希查找 O(1) 且规则增量更新，波动小。小集群（几十个 Service）iptables 完全够用，没必要为 ipvs 多维护内核模块依赖。补充一点：ipvs 模式并没有完全抛弃 iptables，masquerade 和少量辅助规则还是 iptables 做的；节点上验证用 ipvsadm -Ln 看虚拟服务器列表。

回答思路 · 考点拆解与追问预防

答主选+量化理由+适用边界（小集群 iptables 够用），最后带出 ipvsadm 验证命令这个实操细节。

Q68 ｜大厂真题·卷二

18. kube-proxy 需要调系统的一些组件吗？

我的回答 · 第一人称，结合简历

需要，依赖内核网络设施：iptables 模式直接依赖 netfilter/iptables；ipvs 模式依赖内核 IPVS 模块（ip_vs、ip_vs_rr、ip_vs_sh 等，kube-proxy 启动会自动 modprobe 加载）；两者都依赖 conntrack 连接跟踪做 NAT 反向还原，连接表大小和超时参数是调优点：nf_conntrack_max 调大防表满丢连接、nf_conntrack_tcp_timeout_established 等超时按业务调，短连接密集场景还要关注 gc。这些参数我在做高并发节点基线调优时会统一通过 sysctl 下发。

回答思路 · 考点拆解与追问预防

答'要'+按模式列内核依赖+conntrack 调优参数。能把 nf_conntrack_max 说出来，说明真调过。追问预防：conntrack 表满了什么现象（丢新建连接、dmesg 报 table full）；怎么查（nf_conntrack_count/max）。

Q80 ｜大厂真题·卷二

30. 你们 K8s 的网络组件有什么？

我的回答 · 第一人称，结合简历

三层分工：① CNI 插件——Calico，负责 Pod 的 IP 分配、跨节点路由和 NetworkPolicy；② kube-proxy——Service 的服务发现与负载均衡（我们跑 ipvs 模式）；③ MetalLB——裸金属环境给 LoadBalancer 型 Service 供应 VIP（ARP/二层宣告）；再往外集群入口是 ingress-nginx，控制面还有 Keepalived+HAProxy 给 apiserver 做 VIP。选 Calico 而不是 Flannel 的原因：BGP 路由能力强、NetworkPolicy 原生支持、性能好——我们需要网络策略做东西向隔离。

回答思路 · 考点拆解与追问预防

按'Pod 网络 / Service 网络 / 对外暴露 / 入口'的层次报组件，再补一句选型理由。这是 Q31-32 的引子。

Q81 ｜大厂真题·卷二

31. Calico 的网络流量流向，比如 Pod 跟 Pod 之间互相访问，流量走向你有了解吗？

我的回答 · 第一人称，结合简历

有了解。Calico 给每个节点上的 Pod 用 veth pair 接到节点上的网关路由接口（每节点一个，常见 169.254.1.1 一类的本地网关地址），Pod 的默认路由指向它。同节点 Pod 互访：流量出 veth 到宿主机协议栈，查路由表发现目标 IP 是本节点网段内的 Pod，直接转给对端 veth，不过三层封装。跨节点 Pod 互访（BGP 模式）：Pod A → 本节点网关 → 查宿主机路由表，BIRD 已经通过 BGP 学到'目标 PodCIDR 的下一跳是节点 B 的物理 IP'→ 包从节点 A 物理网卡直接路由到节点 B → 节点 B 网关查路由投给目标 veth。纯 BGP 模式没有额外封装头，性能接近原生。封装模式（IPIP/VXLAN）则多一步：出节点前套一层封装（新 IP 头或 UDP），到对端节点解封。组件分工：Felix 写路由和 ACL，BIRD 跑 BGP 分发路由。NetworkPolicy 就是在节点上以 ACL/iptables 规则落地做东西向隔离。

回答思路 · 考点拆解与追问预防

分'同节点 / 跨节点 BGP / 封装'三段讲数据路径，点出 veth、节点路由表、BIRD/BGP 的角色；能画图就现场画。追问预防：Pod IP 从哪来（节点 PodCIDR，由 Calico IPAM 分配）；怎么验证（ip route 看下一跳、tcpdump 抓物理网卡）。

Q82 ｜大厂真题·卷二

32. Calico 有几种封装模式？网络模式的话可以选几种？有哪几种？

我的回答 · 第一人称，结合简历

四种典型选择：① 纯 BGP（无封装）——节点间直接跑 BGP 交换 PodCIDR 路由，性能最好、无封装开销，但要求节点二层可达或底层网络能传 BGP；② IPIP——IP-in-IP 封装，外面再套一个 IP 头，开销约 20 字节，兼容性好，是传统默认；③ VXLAN——UDP 4789 端口封装，支持更大规模标识、对底层网络友好，云上跨子网/NAT 场景合适，开销约 50 字节；④ CrossSubnet 混合——同子网节点间走纯 BGP 直路、跨子网才封装，鱼和熊掌的折中。选型逻辑：性能优先且网络可控选 BGP；云 VPC 跨子网用 VXLAN 或 CrossSubnet； unsure 就 CrossSubnet。我自己的裸金属集群节点同网段，跑的是 BGP 直连，路径最干净。

回答思路 · 考点拆解与追问预防

四模式+开销量级+选型逻辑，最后一句自己集群的实际选择收尾（又是一次'真搭过'的证据）。

Q95 ｜ 2026 最新搜集

Dockerfile 里 COPY 和 ADD、CMD 和 ENTRYPOINT 的区别？

我的回答 · 第一人称，结合简历

COPY vs ADD：COPY 只管把文件/目录复制进镜像，语义干净；ADD 额外做两件事——自动解压本地 tar 包、支持 URL 远程拉取。因为'隐式行为'容易出意外，最佳实践是默认 COPY，需要解压时才用 ADD，远程下载应该在构建期 RUN curl 完清理。CMD vs ENTRYPOINT：ENTRYPOINT 定义容器的固定入口（镜像的'人格'——它是个什么程序），CMD 给默认参数；docker run 传参时 CMD 会被整体覆盖、ENTRYPOINT 不会被覆盖（参数追加在后面）。经典组合：ENTRYPOINT ["nginx"] + CMD ["-g","daemon off;"]，用户可以追加自定义参数。覆盖坑：docker run image bash 会把 CMD 整个换成 bash。K8s 里 command 对应 ENTRYPOINT、args 对应 CMD。

回答思路 · 考点拆解与追问预防

两组对比各带'最佳实践+坑'：ADD 的隐式行为、CMD 整体覆盖。K8s 的 command/args 映射是很多社招都答不出的点。

Q96 ｜ 2026 最新搜集

为什么要多阶段构建？

我的回答 · 第一人称，结合简历

为了镜像体积和安全面。单阶段构建的问题：编译工具链（JDK/maven/go toolchain/node_modules）全被打进最终镜像——一个 Go hello world 用 golang 基础镜像 800MB+，里面带着完整编译器和包管理器，攻击面巨大、拉取慢、层缓存浪费。多阶段写法：第一阶段 FROM golang AS builder 做编译；第二阶段 FROM 一个极小的运行镜像（alpine/distroless/scratch），只 COPY --from=builder /out/app /app 拿产物。效果：我的一个 Python 应用镜像从 900 多 MB 压到 120MB 左右；Go 应用可以压到十几 MB。附带收益：最终镜像里没有 git/curl/shell，漏洞扫描的 findings 大幅减少，也天然满足'最小化运行时'的安全基线。

回答思路 · 考点拆解与追问预防

动机（体积+攻击面）→ 写法（FROM ... AS + COPY --from）→ 量化效果 → 安全收益。带数字最有说服力。

Q97 ｜ 2026 最新搜集

Volume 和 Bind Mount 的区别？

我的回答 · 第一人称，结合简历

Volume：由 Docker 引擎统一管理，落在 /var/lib/docker/volumes/ 下，生命周期独立于容器（容器删了 volume 还在），可命名复用、可挂远程驱动（NFS/云盘）、跨平台行为一致——生产推荐。Bind Mount：直接把宿主机任意路径挂进容器（-v /host/path:/container/path），依赖宿主机目录结构，优点是开发时改代码即时可见、方便宿主机工具直接访问文件；缺点是容器逃逸面更大、可移植性差（换台机器路径就没了）。我的用法分工：开发联调用 bind mount 挂代码目录热更新；生产/持久数据一律 named volume 或走 K8s 的 PV/PVC 体系（那才是正经的生产存储抽象，支持动态供给和存储类）。docker inspect 里的 Mounts 段能看两者类型。

回答思路 · 考点拆解与追问预防

管理权、生命周期、可移植性、安全四个维度+开发/生产分工+延伸到 PV/PVC 展示 K8s 视角。

Q98 ｜ 2026 最新搜集

K8s 三种探针的区别？

我的回答 · 第一人称，结合简历

livenessProbe 存活探针：失败就重启容器——治'进程活着但卡死'（死锁、不响应），是自愈手段。readinessProbe 就绪探针：失败就把 Pod 从 Service Endpoint 摘除——不接流量但不重启，治'活着但还没准备好/临时过载'（预热中、依赖未连上）；滚动更新靠它保证新版本就绪才放流量。startupProbe 启动探针：慢启动应用专属——它通过之前 liveness/readiness 都不生效，避免慢应用（老 JVM）启动几分钟就被 liveness 杀成 CrashLoop。配置经验：liveness 失败阈值放宽（initialDelaySeconds 或改用 startup）、readiness 灵敏一些；探针类型 httpGet/tcpSocket/exec 按应用能力选，优先 httpGet 带真实健康路径。我把'应用健康接口是不是真检查了依赖'写进过交付验收清单——readiness 只查 200 状态码不代表业务真就绪。

回答思路 · 考点拆解与追问预防

三种探针各自'失败时发生什么'（重启/摘流/守护启动）是核心，配置经验+验收细节是实操分。追问预防：liveness 配太敏感的后果（启动期反复重启）。

Q99 ｜ 2026 最新搜集

Pod 起不来：CrashLoopBackOff 和 Pending 分别怎么排查？

我的回答 · 第一人称，结合简历

CrashLoopBackOff（反复崩溃退避）：describe pod 看 Events 和 Exit Code——137=OOMKill 或 SIGKILL（查内存 limit 是不是太小，dmesg 看 oom 记录）、1=应用错误、126=权限；kubectl logs --previous 看上一次崩溃日志（现场最关键一步）；常见根因：配置错误（连不上数据库/密码错）、启动依赖没就绪、健康检查路径 404。Pending（没被调度或资源不够）：describe 看 FailedScheduling 原因——资源不足（requests 超节点可分配量）、taint 没容忍、亲和性冲突、PVC Pending（StorageClass 没配好/容量不够）；k get events 按时间排序总览。我的排查习惯：get -o wide 看落在哪个节点/有没有节点 → describe 读 Events（90% 的答案在里面）→ logs/--previous → 节点层面 kubectl describe node 看资源水位。

回答思路 · 考点拆解与追问预防

按状态分流：Exit Code 对照表（137/1/126）+ logs --previous + FailedScheduling 读法。'describe 的 Events 里有 90% 答案'是经验之谈，说出来就是实操过的人。

Q100 ｜ 2026 最新搜集

用一句话说清 K8s 的核心设计思想？（期望状态 + 协调循环）

我的回答 · 第一人称，结合简历

声明式 API + 调和循环：用户只声明'期望状态'（Deployment 副本=3），不写'怎么到达'的命令；各控制器持续 watch 实际状态与期望的偏差，自动执行收敛动作——Pod 挂了重建、节点挂了在别处重建、副本数改了自动扩缩。对比命令式（'启动 3 个容器'发完就完了，挂了没人管），声明式的系统具备自愈能力。这个模式贯穿所有 K8s 对象，Operator 只是把它扩展到了自定义资源——把运维知识编码成控制器的调和逻辑。我理解的推论：排障时遇到'状态不对'，思路不是手动修，而是查'是谁的调和循环在收敛它'——比如 Pod 被删了自动重建，去改 Deployment 而不是跟单个 Pod 较劲。

回答思路 · 考点拆解与追问预防

一句话核心（声明终态+循环收敛）→ 对比命令式 → Operator 延伸 → 排障推论。能把设计思想落到自己排障直觉上，就是面试官想找的'理解了 K8s 的人'。

监控与日志

共 22 题

Q37 ｜大厂真题·卷一

8. Prometheus 是怎么部署的？如何监控 K8s？

我的回答 · 第一人称，结合简历

生产环境我不裸装二进制，用 kube-prometheus-stack 这个 Helm Chart：一把装下 Prometheus Operator、Prometheus 实例、Alertmanager、Grafana、node_exporter、kube-state-metrics，自带 etcd、kube-scheduler、kube-proxy、apiserver 的 ServiceMonitor 和默认看板告警，离线环境就 helm template 渲染后随交付包发布。监控我分四层：节点层 node_exporter（DaemonSet）；容器层 kubelet 内置 cAdvisor 的 /metrics/cadvisor；K8s 对象层 kube-state-metrics（Pod 重启次数、副本数、PVC 状态）；应用层业务暴露 /metrics，用 PodMonitor/ServiceMonitor 接入。Grafana 配看板，Alertmanager 分级告警。实习维护 CDH 集群和自己的实验集群都是这套，我在它上面做过告警规则和看板定制。

回答思路 · 考点拆解与追问预防

说出 kube-prometheus-stack / Operator 是'真部署过'的强信号；分层监控体系是框架分。追问预防：Operator 是什么；Prometheus 数据存哪（本地 TSDB，保留时长参数 retention）；和下一题 ServiceMonitor 原理形成连环。

Q42 ｜大厂真题·卷一

13. 日志你们是怎么做的？

我的回答 · 第一人称，结合简历

我们私有化平台的日志链路：各节点 Filebeat（DaemonSet）采集容器和主机日志 → 发 Kafka 做缓冲解耦、削峰 → Logstash 消费并做 grok 解析、字段结构化 → 进 Elasticsearch 存储（按天建索引、设保留周期）→ Kibana 查询和看板。为什么加 Kafka：采集和消费解耦、ES 故障或慢写入时日志不丢、多个下游（ES+告警+大数据）可以各自消费。轻量场景我自己也用过 Loki+Promtail：只索引标签不索引正文，成本低，配合 Grafana 原生查询很顺。离线交付时踩过日志盘写满的问题，我处理的方式是缩短保留周期 + 按天索引 + 冷数据下沉，后来写进了巡检清单。

回答思路 · 考点拆解与追问预防

全链路 + 每个组件为什么存在 + 一个自己处理过的问题。追问预防：Loki 和 ES 的取舍（成本/检索能力）；日志量暴增怎么办（限流、分级采集）。

Q43 ｜大厂真题·卷一

14. 说一下 ELFK 组件的作用？

我的回答 · 第一人称，结合简历

Filebeat：轻量采集器，harvester 逐行 tail 文件，registry 记录读取位点实现断点续传，有背压感知，资源占用小——用它在业务机上采集，而不是让重的 Logstash 直接扛；Kafka：消息缓冲层，削峰填谷，上下游解耦，支持多消费组复用数据；Logstash：消费+加工管道，input→filter（grok 正则解析、mutate 字段处理、date 时间解析）→output 路由到 ES 或其它；Elasticsearch：分布式全文检索引擎，分片+副本做存储和查询；Kibana：查询界面、看板、告警可视化。F 位置也常换 Fluentd/Fluent Bit，思路一致。

回答思路 · 考点拆解与追问预防

每个组件'干什么+为什么需要它'两句话；Filebeat 为什么要替代 Logstash 直接采集（轻量、不打扰业务机）是常问点。追问预防：Filebeat 断点续传原理（registry 文件）；grok 解析失败怎么兜底（异常落 tag 或单独索引）。

Q44 ｜大厂真题·卷一

15. Kafka 按照什么维度进行分配 topic？

我的回答 · 第一人称，结合简历

我们的划分维度是业务域 + 日志类型：nginx_access、app_error、db_slowlog 各自独立 topic——消费互不干扰、保留策略可以差异化（错误日志留 30 天、访问日志留 7 天）、某类暴增不拖垮别的链路。分区层面：分区数按目标吞吐估，producer 把 namespace+service 名拼成 key，保证同一服务的日志进同一分区、局部有序；消费者用消费组水平扩展，分区数=组内最大有效消费者数。两个运维注意点：分区越多副本同步开销越大；消费 lag 要监控，lag 持续涨说明消费能力不足或下游 ES 慢了。

回答思路 · 考点拆解与追问预防

题眼在'维度'两个字——回答按什么切 topic，再深入到分区 key 和局部有序、消费 lag 监控。追问预防：怎么保证消息不丢（acks=all、消费端手动提交 offset、副本）；怎么重放（重置 offset）。

Q45 ｜大厂真题·卷一

16. 你是怎么做冷热处理的？

我的回答 · 第一人称，结合简历

ES 层面用 ILM（索引生命周期管理）：hot-warm-cold-delete 四阶段——hot 节点用 SSD、承接写入和近期查询；索引滚动（rollover）后 N 天迁到 warm 节点（大容量 HDD、只读查询）；更老的数据进 cold 或直接快照归档到对象存储；到期删除。落地手段：节点打 box_type 标签，索引模板把索引路由到对应节点，ILM 策略绑定索引模式。数据库层面类似：历史表定期归档到冷存储。我实习时处理过日志盘 80% 告警：把 access 日志保留从 30 天压到 7 天、把 warm 段数据迁走，磁盘回落到安全水位，之后把'日志盘水位+ILM 策略检查'加进了巡检清单。

回答思路 · 考点拆解与追问预防

ILM 四阶段 + 节点标签路由 + 一个带数字的处置实例。追问预防：rollover 按什么触发（大小/天数/文档数）；force merge 在 warm 阶段的作用。

Q46 ｜大厂真题·卷一

17. 你用过 ES 快照吗？

我的回答 · 第一人称，结合简历

用过。流程三步：注册仓库 PUT _snapshot/my_repo（type=fs 要先在 elasticsearch.yml 配 path.repo，生产更多用 S3/OSS/MinIO 插件仓库）→ 创建快照 PUT _snapshot/my_repo/snap_20260909?wait_for_completion=false 异步执行，支持按索引选择 → 恢复 POST _snapshot/my_repo/snap_20260909/_restore，可指定目标索引。两个原理级要点：快照是增量的（基于 segment 文件不变性，只拷新段）；恢复时目标索引会被关闭重建。生产上我不手工跑，用 SLM（快照生命周期策略）每天凌晨自动快照，配合 ILM 做'warm 之后归档'。交付环境里我把快照仓库指向客户侧 NFS，并验证过一次完整 restore。

回答思路 · 考点拆解与追问预防

命令链注册→快照→恢复 + 增量原理（segment 只读）+ SLM 自动化。追问预防：快照能跨大版本恢复吗（一般相邻版本）；仓库冲突怎么办（唯一 repo 名+注册表）。

Q49 ｜大厂真题·卷一

20. 你们告警规则怎么管理？

我的回答 · 第一人称，结合简历

核心是'规则即代码'：用 Prometheus Operator 时告警规则全部是 PrometheusRule CRD，跟应用的 Helm Chart 一起交付、进 Git 管理——改动走 MR 评审，CI 里用 promtool check rules 做语法校验，合并后 Operator 自动热加载，禁止任何人直接在页面或文件上手改。规则本身有规范：必须带 severity 标签分级（critical/warning）、annotation 里带 summary 和 runbook 链接（处置文档）、命名和命名空间按团队归属。Alertmanager 的路由树、抑制、静默配置同样 Git 化。实习时我整理过一轮存量告警：把无 runbook、无分级、长期误报的规则下线，告警噪音明显下降。

回答思路 · 考点拆解与追问预防

关键词：CRD、规则即代码、MR 评审、promtool 校验、runbook。这题考'规模化治理'思维，是实习经历里最能出彩的一题。追问预防：告警太多怎么治理（分级路由、聚合、静默窗口、review 机制）。

Q59 ｜大厂真题·卷二

9. 然后你们 K8s 监控的话是怎么做的？是用什么工具做的？

我的回答 · 第一人称，结合简历

kube-prometheus-stack 一把装：Prometheus Operator + Prometheus + Alertmanager + Grafana + node_exporter + kube-state-metrics。分层采集：节点 node_exporter（DaemonSet）、容器 cAdvisor（kubelet 自带 /metrics/cadvisor）、K8s 对象 kube-state-metrics、应用 /metrics 走 ServiceMonitor。看板 Grafana（自带 K8s 核心看板，我补过业务和中间件看板），告警 Alertmanager 分级路由到企业微信/钉钉。方法论上主机看 USE、服务看 RED。实习时用这套定位过 CDH 节点的 CPU/IO 瓶颈并出了扩容方案。

回答思路 · 考点拆解与追问预防

工具链+分层采集+方法论+实例，四段式完整回答。和 Q11-Q12 的 ServiceMonitor 深挖形成连环，这题先把地基打好。

Q60 ｜大厂真题·卷二

10. 都是手动部署吗？没有借助其他开源项目吗？比如 kube-prometheus 用过吗？

我的回答 · 第一人称，结合简历

用过，就是它——我们用 kube-prometheus-stack（Helm 版的 kube-prometheus 方案）。生产上我不手工二进制部署，原因有三：Operator 把 Prometheus/Alertmanager/规则都变成 CRD 声明式管理，可版本化可重建；自带全套组件的 ServiceMonitor、Grafana 看板和默认告警规则，开箱即用；Helm values 一处定制（存储、资源、retention），多环境一致。不过我学原理时手工部署过裸的 Prometheus（binary + 配置文件 + systemd），所以 scrape_config、relabel 这些底层概念是在没有 Operator 的情况下搞明白的——这让我用 Operator 时知道它底下在做什么。离线交付时用 helm template 渲染成静态清单随包发布。

回答思路 · 考点拆解与追问预防

'用 kube-prometheus-stack + 手工部署过裸 Prometheus 学原理'是完美答案结构——既证明会用工具，又证明懂底层。追问预防：Operator 模式本质（自定义控制器+CRD 的调谐循环）。

Q61 ｜大厂真题·卷二

11. 比如现在我有个需求，我起了三个 Pod，需要从这三个 Pod 里拉取 metrics 指标，一般是怎么做？

我的回答 · 第一人称，结合简历

两条路径：有 Service——推荐 ServiceMonitor：selector 选中这个 Service，endpoints 指定 metrics 端口名，Prometheus Operator 生成抓取配置，自动覆盖三个 Pod 的所有 endpoint，Pod 重启换 IP 也自动跟上；没有 Service/不想建——用 PodMonitor 直接按 label selector 选 Pod，或者传统方式给 Pod 打 annotation（prometheus.io/scrape: "true"、prometheus.io/port: "9090"），在 Prometheus 配置里用 pod role 的服务发现+relabel 过滤。前提是应用本身暴露 /metrics（Python 加 prometheus_client，Java 用 Micrometer）。我会优先 ServiceMonitor，因为它顺着 Service/Endpoint 这个天然抽象走，和流量路径一致。

回答思路 · 考点拆解与追问预防

给两条路径+选型理由。追问预防：应用没有 metrics 端点怎么办（blackbox exporter 黑盒探测 / process exporter 兜底）；ServiceMonitor 和 PodMonitor 区别（按 Service 的 endpoint 选 vs 直接按 Pod 选）。

Q62 ｜大厂真题·卷二

12. 具体到 Prometheus 里它是怎么实现的？创建完 ServiceMonitor 之后 Prometheus 里发生了什么？CRD 最后变成 Prometheus 的配置文件，那些配置是做什么的？它为什么就能监听到 Pod？Pod 重启了为什么还能抓取到？利用什么东西实现的？

我的回答 · 第一人称，结合简历

这是我最喜欢的一类问题，完整链路分四步。① Operator 调谐：Prometheus Operator watch ServiceMonitor CR，按它的 namespaceSelector 和 selector 找到匹配的 Service，进而取到 Endpoints 对象（真实后端 Pod IP:Port 清单），然后生成 Prometheus 的 scrape 配置段写入 Prometheus 对象引用的配置（secret 挂载），Prometheus 检测到配置变化自动 reload。② 配置内容：核心是 kubernetes_sd_configs 的 role: endpoints——它让 Prometheus 直连 apiserver，list-watch Service/Endpoints/Pod 对象，把每个 endpoint 变成一个带丰富元标签的候选 target，比如 __meta_kubernetes_service_name、__meta_kubernetes_endpoint_address_target_name。③ relabel：relabel_configs 用这些 __meta 标签做保留/丢弃（对应 ServiceMonitor 的 selector）和改写（把元标签映射成 job、instance 等最终标签）。④ 为什么 Pod 重启还能抓：因为配置里写的从来不是 Pod IP，而是'发现规则'——Endpoint 控制器实时维护 Service→健康 Pod 的映射，Pod 重启换 IP 时 Endpoint 变化，Prometheus 通过 watch 感知、自动刷新 target 列表，完全不需要改配置文件。一句话总结：CRD 声明意图 → Operator 翻译成'服务发现规则'而非'地址清单' → 动态发现让目标自愈。

回答思路 · 考点拆解与追问预防

本卷最深的题，答好直接定级。链路：CRD→Operator 调谐→生成 kubernetes_sd 配置→relabel 元标签→动态 endpoint 自愈。中途卡壳就退守'服务发现+relabel'主干。追问预防：endpoints 和 endpointslice（新版本通过 EndpointSlice 发现）；honor_labels 干嘛的（保留应用自带标签避免冲突）。

Q63 ｜大厂真题·卷二

13. 然后日志的话，你们那边主要用什么？用 Loki 吗？

我的回答 · 第一人称，结合简历

实习的私有化平台用 EFK 体系（Filebeat→Kafka→Logstash→ES→Kibana），重检索场景——客户排障要按关键字、字段聚合查询，ES 的全文检索能力是刚需。Loki 我自己在轻量场景用过（Promtail+Loki+Grafana）：它只对标签建索引、正文压缩存储，成本比 ES 低一个量级，配合 LogQL 查询，适合'知道大概标签范围、捞日志看上下文'的云原生场景。我的选型逻辑：重检索聚合、多租户审计 → ES；成本敏感、标签维度清晰、与 Grafana 生态贴合 → Loki；两者也可以并存，Loki 做常规排障、ES 兜底重查询。

回答思路 · 考点拆解与追问预防

先答主用的（EFK），再展示对 Loki 的理解与选型逻辑——'被问 X 用的 Y 吗'这种题，考的是你能不能讲清 trade-off 而不是站队。

Q64 ｜大厂真题·卷二

14. 一般 Pod 的日志，如果你配置文件不改的话，放在哪里？节点上面起个 Pod，它那个日志放在宿主机的哪个目录？

我的回答 · 第一人称，结合简历

容器的 stdout/stderr 由容器运行时落到节点磁盘：containerd 路径是 /var/log/pods/<namespace>_<podname>_<pod-uid>/<container>/0.log；/var/log/containers/ 下的 .log 文件是指向这些文件的软链接（文件名带 pod/容器名，好认）。Docker 运行时则在 /var/lib/docker/containers/<container-id>/<id>-json.log。kubectl logs 的本质就是 kubelet 读这些文件。轮转由 kubelet 管理，默认 10Mi × 5 份（containerLogMaxSize/containerLogMaxFiles 可调），所以单个容器日志不会无限膨胀撑爆磁盘。我们的 Filebeat DaemonSet 就是挂载 /var/log/containers 来采集的。补充一点：写到容器内文件系统的日志（不是 stdout）kubelet 不管，那种要么挂 emptyDir/PVC，要么应用直接输出 stdout 才能被标准链路采集。

回答思路 · 考点拆解与追问预防

路径必须一字不差答出来（/var/log/pods + /var/log/containers 软链关系）；加分点：kubectl logs 的本质、kubelet 轮转参数、非 stdout 日志的坑。

Q69 ｜大厂真题·卷二

19. 然后监控的告警一般怎么做？是用 AlertManager 来做吗？

我的回答 · 第一人称，结合简历

对，标准链路是：PrometheusRule（CRD）定义规则——expr 表达式 + for 持续时长（防瞬时抖动）+ labels（severity 分级）+ annotations（summary、runbook 链接）→ Prometheus 周期评估，条件满足并持续够 for 时长进入 FIRING → 推给 Alertmanager：按路由树分组（group_by 降低轰炸）、去重、抑制、静默 → receiver 投递企业微信/钉钉/邮件/电话。我们的实践：P0/P1 级别配电话和值班群，P2 只进普通群聚合；每条告警必须带 runbook，新人照着文档就能处置。规则本身 Git 化、CI 校验，这是我实习时治理过的方向。

回答思路 · 考点拆解与追问预防

链路完整（规则→评估→FIRING→路由→投递）+ for 的作用 + 分级运营实践。和 Q20-22 抑制专题是连环三问。

Q70 ｜大厂真题·卷二

20. 告警抑制一般是怎么实现的？

我的回答 · 第一人称，结合简历

在 Alertmanager 配置里用 inhibit 规则：定义 source（抑制方）和 target（被抑制方）的标签匹配条件，加 equal 列表限定必须相同的标签维度。语义是：当一个 source 告警触发时，凡是标签匹配 target 条件、且 equal 列出的标签值与 source 相同的告警，就不再通知。典型应用：node_down（critical）触发时，抑制该节点上所有 severity=warning 的实例级告警——根因先报，衍生告警静默，防止告警风暴把关键信息淹没。实现机制上，Alertmanager 对活跃告警做标签匹配计算，被抑制的告警仍然存在和记录，只是不投递。

回答思路 · 考点拆解与追问预防

inhibit 三要素（source_matchers/target_matchers/equal）+ node_down 经典例子 + '被抑制的仍存在只是不通知'这句精确表述。

Q71 ｜大厂真题·卷二

21. 节点上可能有 5 个告警规则，其中 2 个比较重要必须报，另外 3 个不太重要。重要的触发了之后不重要的也触发了，但我只需要重要的那两个，AlertManager 里怎么实现？

我的回答 · 第一人称，结合简历

这就是抑制的标准场景，配一条 inhibit 规则：source_matchers 匹配 severity="critical"（那两个重要规则），target_matchers 匹配 severity="warning"（那三个次要规则），equal 里放 node 或 instance——保证只在同一节点/实例维度上抑制，A 节点的严重告警不会误杀 B 节点的次要告警。效果：重要的照常报，同维度次要的被压掉。如果需求不是'重要触发才压次要'而是'次要的永远低优先级'，那就用路由分流方案：critical 走电话+值班群，warning 路由到低优先级渠道且拉长 group_interval 聚合批量发。两种手段按语义选：前者是因果抑制，后者是分级降噪。

回答思路 · 考点拆解与追问预防

先给 inhibit 配置级答案（这是面试官想要的），再补充路由分流方案展示广度。equal 的维度限定一定要说，否则显得没真配过。

Q72 ｜大厂真题·卷二

22. 它的抑制主要是通过告警的什么来实现呢？怎么判断这个告警要抑制另一个告警？

我的回答 · 第一人称，结合简历

完全通过告警的标签（labels）来匹配：source_matchers 匹配的告警作为'抑制方'，target_matchers 匹配的作为'被抑制方'，equal 列表要求两者的这些标签值完全相等才建立抑制关系。这带来一个工程推论：告警规则设计阶段的标签规范化是抑制能落地的前提——severity、node、service、cluster 这些维度标签必须统一命名、认真赋值，否则抑制规则匹配不上。所以我们把'告警必须带哪些标准标签'写进了规则模板，新告警不过标签检查不让合并。

回答思路 · 考点拆解与追问预防

一句话答核心（标签匹配+equal），然后升维到'标签规范是治理前提'——把知识点答成工程实践，是这卷反复出现的高分模式。

Q73 ｜大厂真题·卷二

23. 你们那个 Prometheus 的话是单机的，是吗？

我的回答 · 第一人称，结合简历

如实：实习交付场景是单实例——私有化环境节点规模小，监控本身的可用性要求让位于交付成本和资源占用，单 Prometheus + 本地 TSDB 的方案在那个规模下是合理取舍，风险我们也补偿过：告警链路做了检测（Prometheus 挂了本身要有告警，比如 watchdog 常驻告警或黑盒探测）。但如果目标更大、监控不可用等于半盲，就要上高可用方案——这是我主动研究过的方向，下一题我展开。

回答思路 · 考点拆解与追问预防

如实承认单机，但把'为什么这样选'讲成成本/规模的工程取舍，并展示'Prometheus 自身也要被监控'的意识——比硬吹高可用可信得多，还自然引出下一题。

Q74 ｜大厂真题·卷二

24. 有了解过 Prometheus 的高可用实现方案吗？

我的回答 · 第一人称，结合简历

了解，按层次五种：① 双副本并行抓取——两个完全相同配置的 Prometheus 同时抓，Alertmanager 集群模式按告警指纹自动去重，解决告警单点，这是最常用的第一步，代价是抓取目标双倍压力；② 远程存储——remote_write 到 VictoriaMetrics 或 Thanos Receive，查询层无状态化，VM 单机版就能扛很高吞吐，性价比方案；③ Thanos 方案——Sidecar 把 TSDB block 上传对象存储做长期存储+降采样，Query 组件做全局查询视图，Store Gateway 读历史数据，适合多集群全局监控；④ 联邦——上层 Prometheus 拉取下层聚合指标，层级式，适合树状组织但细粒度数据不在中心；⑤ Cortex/Mimir——多租户大规模的完整方案。我的选型直觉：中小规模双副本+Alertmanager 集群起步；数据重要或多集群就 remote write 进 VM；要做长期存储和全局视图上 Thanos。

回答思路 · 考点拆解与追问预防

五种方案+各自解决的问题（告警单点/存储单点/查询全局/长期存储）+分级选型建议。追问预防：Alertmanager 怎么去重（相同 fingerprint 即 labels 哈希）；remote_write 断了数据丢吗（本地 WAL 缓冲重发）。

Q101 ｜ 2026 最新搜集

设计方案：监控 100 台 Linux 服务器，你怎么做？

我的回答 · 第一人称，结合简历

我按四层给方案。采集层：Prometheus + node_exporter（Ansible 批量下发安装注册，或 DaemonSet 若在 K8s）；网络设备/黑盒探测用 snmp/blackbox exporter。存储与展示：Prometheus 分片或按机房联邦，retention 15-30 天，长期数据 remote write 到 VictoriaMetrics；Grafana 建主机总览看板（CPU/内存/磁盘/网络+TOP 排行）。告警层：Alertmanager 集群（两个起步，互为备份+去重），规则分级：P0 主机失联/CPU 持续 95%+/磁盘 90%+/内存 OOM 风险，P2 走聚合低优渠道；每条带 runbook。治理层：规则 Git 化+CI 校验；告警收敛（同主机故障抑制衍生告警）；月度告警复盘删误报。落地顺序：先 20 台试点跑一个月调阈值，再全量。成本考虑：百台规模单 Prometheus 足够（千级目标再谈分片），别过度设计。实习+自建集群的经验里，'告警可用性'最容易被忽略——监控挂了要有 watchdog，网络断要有黑盒探测兜底。

回答思路 · 考点拆解与追问预防

采集/存储/告警/治理四层方案+落地顺序（试点调阈值再全量）+适度设计原则+两个坑（watchdog、黑盒兜底）。设计题考的是完备性和分寸感。

Q103 ｜ 2026 最新搜集

Prometheus 为什么用 Pull 模式？适合什么场景？（字节真题）

我的回答 · 第一人称，结合简历

Pull 的优势：① 目标健康天然可见——拉不动本身就是监控信号（up 指标），推模式下 agent 挂了你只是收不到数据，安静地瞎；② 控制权在中心：抓取频率、超时由 Promethus 统一管理，不被 agent 淹没；③ 目标自描述：/metrics 端点任何 curl 都能调试；④ 天然配合服务发现——kubernetes_sd 跟着集群状态动态增删 target。局限：短生命周期任务（批处理跑完就没了）来不及被拉——用 Pushgateway 做中转（job 完 push 指标，Prometheus 拉 gateway）；NAT 后的私有环境拉不进去——remote_write/Binary 的 push 体系补位。所以结论：长期在线服务 Pull+SD 是最优解（K8s 场景绝配），短任务和边缘场景 Push 补充。采集 K8s 指标我再说下入口：节点和容器指标来自 kubelet 的 /metrics 与 /metrics/cadvisor，对象状态来自 kube-state-metrics，都经 apiserver 的服务发现纳管。

回答思路 · 考点拆解与追问预防

'拉不动就是告警'这个点最能体现理解深度；局限与 Pushgateway 补位展示完整性；后半句接上字节原题的'K8s 采集接口'。

Q104 ｜ 2026 最新搜集

Zabbix 和 Prometheus 怎么选型？（vivo 一面）

我的回答 · 第一人称，结合简历

一句话：传统静态 IT 基础设施选 Zabbix，云原生动态环境选 Prometheus。展开对比：数据模型——Zabbix 以主机为中心（agent 装机器上，配监控项触发器），Prometheus 以多维标签时序为中心（instance/job/任意 label 切片聚合），后者天生适合容器'IP 一直在变'的世界；服务发现——Zabbix 靠手工/自动注册，Prometheus 的 kubernetes_sd/consul_sd 自动跟随；生态——Zabbix 内置 SNMP/IPMI/模板库，搞交换机、服务器硬件、Windows 很顺手，Prometheus 云原生 exporter 生态无敌（Grafana/LOKA 亲和）；存储与扩展——Zabbix 依赖 MySQL，Prometheus 本地 TSDB+远程存储生态（VM/Thanos）更灵活。我的选择：K8s 为主的平台无脑 Prometheus；机房混合环境（交换机+物理机+少量容器）也见过两者并存——Zabbix 管硬件层、Prometheus 管应用层，Grafana 统一看板。

回答思路 · 考点拆解与追问预防

一句话定调+四个维度对比+并存方案收尾。选型题的万能结构：结论先行、维度展开、承认混合现实。

CI/CD 发布

共 5 题

Q38 ｜大厂真题·卷一

9. 说一下你做的 CI/CD 流程？

我的回答 · 第一人称，结合简历

我分实习交付和自建两套口径讲。自己集群上跑的完整链路：开发提交 → GitLab MR 触发流水线 → lint（shellcheck / 语法检查）+ 单测 → Docker 多阶段构建镜像 → 推私有 Harbor，tag 用分支-commit短哈希-日期 → 部署阶段 helm upgrade --install，K8s 滚动更新，readiness 探针过了才接流量 → 部署后验证 rollout status + 健康接口 → 异常时 helm rollback 一键回滚。环境分 dev/prod：dev 自动部署，prod 加人工审批 job。实习的私有化交付环境是离线的，链路调整为：我们把镜像和 Chart 预同步进客户侧 Harbor，变更走'版本包+巡检脚本'的方式交付，配置全 Git 版本化，保证构建一次、到处运行。

回答思路 · 考点拆解与追问预防

先讲标准链路再讲离线交付的变体，恰好覆盖'奇点云私有化'这个简历事实，区分度很高。追问预防：为什么镜像 tag 不用 latest（不可追溯、缓存陷阱）；prod 审批怎么做（GitLab protected environment / Jenkins input）。

Q39 ｜大厂真题·卷一

10. 你们怎么做的镜像？

我的回答 · 第一人称，结合简历

一套镜像规范：多阶段构建——编译阶段和运行阶段分离，编译工具链不进最终镜像；基础镜像选 alpine/slim 或 distroless，固定版本或 digest；.dockerignore 排除 .git、node_modules 等无关文件；分层优化——先 COPY 依赖清单再 COPY 源码，让依赖层吃住缓存；镜像内单进程、非 root 用户；tag 用语义化 + commit 短哈希，坚决不用 latest；推私有 Harbor 并跑 Trivy 漏洞扫描。效果我给个数：一个 Python 应用的镜像从 900 多 MB 压到 120MB 左右。离线交付场景再补一手：docker save 成 tar 包随交付走，或直接同步进客户 Harbor。

回答思路 · 考点拆解与追问预防

规范清单 + 一个量化结果 + 离线场景补充。追问预防：CMD 和 ENTRYPOINT 区别；镜像层缓存原理（指令按序比对）；docker build 缓存失效怎么办。

Q40 ｜大厂真题·卷一

11. 能详细说一下 CD 流程吗？

我的回答 · 第一人称，结合简历

CD 是'从镜像到生产'这段：镜像已经有不可变的版本 tag → 部署用 Helm：helm upgrade release chart --set image.tag=$TAG --atomic，--atomic 参数保证失败自动回滚 → K8s 执行滚动更新：maxSurge 控制超出副本数、maxUnavailable 控制可用下限，新 Pod 通过 readinessProbe 才会进 Endpoint 接流量 → 部署后验证：kubectl rollout status 等就绪、调 /healthz、Grafana 观察 5 分钟错误率和时延 → 异常回滚：helm rollback 或 kubectl rollout undo，本质是切回历史 ReplicaSet（镜像是不可变的所以回滚可靠）。策略上生产可以叠金丝雀：ingress canary 注解先放 5% 流量观察。配套纪律：生产变更窗口、变更单、回滚预案先写好。

回答思路 · 考点拆解与追问预防

镜像不可变 → 部署 → 验证 → 回滚，把'可靠'讲成机制而不是运气。追问预防：rollout undo 能回滚什么不能回滚什么（回滚模板和镜像，回滚不了数据库 schema）；--atomic 原理。

Q41 ｜大厂真题·卷一

12. 流水线的流程（具体 stage）？

我的回答 · 第一人称，结合简历

以我 GitLab CI 的 stage 为例：lint（shellcheck/yamllint/helm lint）→ build（docker build，利用层缓存和镜像仓库缓存加速）→ test（单测、有条件加集成测试）→ push（推 Harbor，打 tag）→ deploy-dev（helm upgrade 自动触发）→ deploy-prod（manual 手动审批卡点，环境保护）→ verify（健康检查 curl /healthz + 观察指标几分钟）→ 常驻 rollback job 一键回上个 release。Jenkins 版对应声明式 Jenkinsfile：stages + input 卡点 + post 块做通知。两条经验：耗时 stage 用缓存和并行压缩；verify 阶段宁可多等两分钟，也别让坏版本过夜。

回答思路 · 考点拆解与追问预防

按 stage 报 + 每段一句目的。追问预防：流水线卡住怎么排查（Runner 状态、分层看是环境/代码/配置问题）；缓存怎么配（cache 关键字、docker layer cache）。

Q102 ｜ 2026 最新搜集

描述从代码提交到发布的完整流程，含回滚。（2026 高频）

我的回答 · 第一人称，结合简历

完整链路七步：① 提交与触发：push/MR 触发 webhook。② 静态检查：lint、安全扫描（gitleaks 查密钥泄漏）。③ 构建与测试：单测→多阶段构建镜像→Trivy 扫镜像漏洞。④ 制品入库：推 Harbor，tag=分支+commit+日期，镜像从此不可变。⑤ 部署：dev 自动发布；测试验证通过后 promote 同一镜像到 prod（审批卡点），helm upgrade --atomic 滚动更新，readiness 探针护流量。⑥ 验证：rollout status+健康接口+观察 5 分钟错误率/时延。⑦ 回滚：指标异常立即 helm rollback / rollout undo（切回历史 ReplicaSet，秒级）；数据库变更单独走向前兼容的迁移（先加列后删列的两段式），保证应用回滚不被 schema 卡住。设计要点一句话：镜像不可变+环境提升用同一个制品+回滚是流程的一部分而不是救火。

回答思路 · 考点拆解与追问预防

七步链路+每步一个安全/质量动作。最亮的两点：'同一镜像 promote'和'数据库迁移向前兼容'——能把回滚讲全的人不多。追问预防：回滚数据怎么办（代码回滚、schema 不回滚的设计）。

Ansible

共 5 题

Q75 ｜大厂真题·卷二

25. Ansible 的话用的多吗？

我的回答 · 第一人称，结合简历

如实：实习里主力是 Python/Shell 脚本，Ansible 用在自己的集群建设和实验环境——6 节点 K8s 的批量初始化（内核参数、hosts、运行时安装）我用 playbook 做过一遍，日常批量小操作用 ad-hoc 命令。我的定位是：一次性/探索性操作脚本快，标准化可重复的批量变更上 Ansible——幂等、模块化、inventory 分组管理，比裸脚本可维护性好。核心概念我熟练：inventory、playbook、role、模块的幂等性、register、handler 触发机制、template 渲染。

回答思路 · 考点拆解与追问预防

如实分级+场景定位（什么时候 Ansible 优于脚本）+概念清单证明系统学过。追问预防：handler 什么时候触发（task 状态 changed 才 notify）；role 的目录结构。

Q76 ｜大厂真题·卷二

26. 我有 100 台主机，需要把 100 台主机的系统版本信息都拿到，需要用什么插件/模块？说说怎么实现。

我的回答 · 第一人称，结合简历

用 setup 模块——Ansible 的信息采集模块（gather_facts 底层就是它），系统版本相关的 fact 有 ansible_distribution、ansible_distribution_version、ansible_kernel。命令：ansible all -m setup -a "filter=ansible_distribution*"，filter 只取相关 facts 减少输出；批量精简输出加 -o 参数。要汇总成报表就写 playbook：对 setup 的结果用 register 收集，再走 template 渲染或 lineinfile 聚合输出 CSV。顺手的替代：ansible all -m command -a "cat /etc/os-release" 也能拿，但 setup 是标准姿势——结构化、不用解析文本。

回答思路 · 考点拆解与追问预防

setup 模块+filter 过滤+-o 是三个采分点；给出 register+template 汇总的进阶版更佳。追问预防：facts 采集慢怎么办（gather_facts: no + 按需 setup）；怎么只对某组主机执行（inventory 分组 + limits）。

Q77 ｜大厂真题·卷二

27. 注册变量这个功能有了解吗？

我的回答 · 第一人称，结合简历

了解，register：把任务的执行结果（stdout、stderr、rc、changed、stdout_lines 等）捕获到变量里，供后续任务引用。典型用法三连：① 条件判断——shell 任务 register 后，下一个任务 when: disk_check.rc != 0 或 when: "'error' in result.stdout"；② 调试输出——debug: var=result.stdout_lines；③ 汇总报表——像上一题，注册 setup 结果再渲染模板。配合的细节：命令可能非零退出时要 ignore_errors: yes 或 failed_when 自定义失败条件，否则 playbook 直接中断；changed_when 可以纠正 shell 任务的 changed 状态，让报告干净。

回答思路 · 考点拆解与追问预防

定义+三种用法+ignore_errors/failed_when/changed_when 三件套——把这三个'纠偏'参数说出来就是真用过。追问预防：register 在 loop 里的结构（results 数组）。

Q78 ｜大厂真题·卷二

28. 我如果创建一个文件，需要用什么模块？

我的回答 · 第一人称，结合简历

file 模块：state=touch 创建空文件、state=directory 创建目录、state=link 创建软链、state=absent 删除，同时能用 mode/owner/group 一并声明权限属主，比如：ansible webservers -m file -a "path=/etc/motd.d/notice state=touch mode=0644 owner=root"。如果创建时还要写入内容，用 copy 模块（content= 或 src=）更直接；模板化内容用 template 模块。

回答思路 · 考点拆解与追问预防

file 模块的 state 矩阵+权限属主参数+升级路径（copy/template），一分钟内答完，别恋战——这题的追问在下一题。

Q79 ｜大厂真题·卷二

29. shell 模块执行命令创建文件跟用 file 模块创建文件有什么区别？file 模块相比较用命令来创建有什么好处？

我的回答 · 第一人称，结合简历

核心差异是幂等和声明式：file 模块声明的是'期望状态'——文件存在且权限属主正确，重复执行 N 次结果一致，且已符合状态时报告 ok 而不是 changed，状态变化会被精确检测；shell 里跑 touch 每次都是'执行命令'——文件已存在时无法感知（要么误报 changed，要么自己写判断逻辑），权限属主还得再补命令，输出要靠 register 解析文本，且 shell 模块有注入风险（命令拼接进 shell 解释器）。所以 Ansible 的铁律是：有原生模块绝不用 shell/command，shell 是没有模块覆盖时的最后手段，而且要配 creates/removes 参数或 changed_when 补幂等性。yum/service/user 这些高频操作同理——模块封装了状态判断，跨发行版兼容也替你做好了。

回答思路 · 考点拆解与追问预防

幂等、changed 状态检测、安全、可移植四个维度对比+creates/changed_when 补救手段。这题就是 Ansible 哲学题，答出'声明式状态 vs 命令执行'的本质就拿满。

数据库缓存

共 2 题

Q109 ｜ 2026 最新搜集

MySQL 主从复制原理？主从延迟怎么处理？（字节真题）

我的回答 · 第一人称，结合简历

复制流程三线程：主库 dump 线程把 binlog 推给从库 → 从库 IO 线程收下写进 relay log → 从库 SQL 线程重放 relay log。复制模式：异步（默认，主库不等从库，可能丢）、半同步（至少一个从库 ACK 才返回，平衡）、GTID 复制（事务全局编号，搭从库和故障切换更省心）。主从延迟：大事务、从库单线程重放、从库机器差。处理：拆大事务、开并行复制（slave_parallel_workers + LOGICAL_CLOCK 按组提交并行）、从库用更好的盘、读写分离时把'写后立即读'强制路由主库。前端配合（字节原题）：读写分离组件+连接池（如 MyCat/ShardingSphere 路由，或应用层数据源分离），会话内写后读走主库。运维侧我的必做项：监控 Seconds_Behind_Master、复制中断自动告警。

回答思路 · 考点拆解与追问预防

三线程模型是骨架，GTID/半同步是加分，延迟的'拆事务+并行复制+路由主库'三层是实战。追问预防：主从切换怎么做（校验数据、提升新主、改写入口）；binlog 三种格式（ROW/STATEMENT/MIXED）。

Q110 ｜ 2026 最新搜集

Redis 缓存穿透、击穿、雪崩的区别和对策？（字节真题）

我的回答 · 第一人称，结合简历

三个都是'缓存没顶住、流量打到 DB'，但成因不同：穿透——查根本不存在的数据，缓存永远无法命中（恶意扫描垃圾 key）。对策：布隆过滤器前置拦截、空值缓存（短 TTL）、接口层参数校验。击穿——某个热点 key 恰好过期瞬间，海量并发直击 DB。对策：热点 key 逻辑过期/不过期、互斥锁重建（只放一个请求去查库回填）。雪崩——大批 key 同时过期或 Redis 实例整体挂。对策：过期时间加随机抖动、多级缓存、集群高可用（哨兵/Cluster）、限流降级保 DB。再补运维侧：Redis 快的原因（内存+IO 多路复用单线程无锁）、持久化 RDB（快照，恢复快可能丢）与 AOF（追加，更安全文件大）混合配置。哨兵模式前端连接（字节原题）：客户端用 JedisSentinelPool 这类哨兵感知的连接池，主从切换后自动跟随新主。

回答思路 · 考点拆解与追问预防

三连对比题的答法：先给一句统一本质，再分成因+对策。带出哨兵客户端连接方式是字节面经原题的加答。

场景排障

共 4 题

Q92 ｜ 2026 最新搜集

服务器 CPU 突然 100%，你的排查思路？（2026 场景题 TOP1）

我的回答 · 第一人称，结合简历

我的固定四步：① 定位进程：top（P 排序）/ ps aux --sort=-%cpu | head，确认是哪个进程、是不是业务相关的。② 看进程内部：top -H -p PID 找热点线程，Java 的拿线程号转 16 进制去 jstack 对栈，看是死循环、频繁 GC 还是锁自旋——jstat -gcutil 看 GC 频率。③ 看系统上下文：vmstat 1 分流——us 高是应用逻辑，sy 高看上下文切换（pidstat -w）和系统调用，wa 高是假 CPU 问题，真凶是 IO。④ 定性处置：业务侧（代码 bug/流量突增）联系开发留证据后重启或限流；资源侧扩容；如果是被入侵挖矿（top 里奇怪进程、高外连），先隔离网络再取证。实习时我处理过 CDH 节点 CPU 高：top 显示 DataNode，vmstat wa 显著，追到是某块数据盘响应慢，IO 拖高整体负载——最后加盘分摊解决，所以我对'CPU 高≠CPU 的错'这点体会很深。

回答思路 · 考点拆解与追问预防

四步框架（进程→线程→上下文→定性）+ 分流判断（us/sy/wa）+ 两个真实分支（GC/挖矿）+ 实习案例。场景题答的是'有没有真的处理过'，框架+案例缺一不可。

Q106 ｜ 2026 最新搜集

说说你真正解决过的一个故障？（2026 最重要场景题）

我的回答 · 第一人称，结合简历

我讲煌上煌交付时的跨节点网络故障。现象：交付验收时发现部分业务容器跨节点互访不通，同节点正常。定位：先收敛变量——Pod 都 Running、Calico 路由表正常（ip route 能看到对端节点 PodCIDR），从问题 Pod 里 ping 同节点 Pod 通、跨节点不通；tcpdump 在源节点抓包看到包发出但目标节点没收到转发痕迹，怀疑中间转发链被跳过；检查宿主机 iptables，发现 Docker 相关的业务网络转发链丢失（之前一次变更把规则冲掉了），FORWARD 链默认 DROP，跨节点包到节点就被丢。恢复：重建转发链规则、恢复 ACCEPT 策略，连通恢复；再补了持久化，避免重启后又丢。根因与预防：根因是规则没有纳入配置管理、变更无校验；改进：网络基线规则脚本化进交付包、验收清单加'跨节点连通性'检查项，之后这类问题在测试环境就能拦住。整个过程的复盘我也写进了交付文档。

回答思路 · 考点拆解与追问预防

满分 STAR 结构：现象收敛→分层定位（tcpdump+iptables）→恢复→根因→制度化预防。'从故障到流程改进'的闭环正是运维成熟度的证据；这是简历煌上煌案例的展开版，务必练到 3 分钟讲完。

Q107 ｜ 2026 最新搜集

网站打不开，完整排查思路？

我的回答 · 第一人称，结合简历

我按流量路径从外到内二分：① 客户端侧：别的用户也这样吗（区分个体/全局）；本地 ping/telnet、换网络、换浏览器。② DNS 层：dig/nslookup 看解析结果对不对、TTL 是否旧记录。③ 入口层：curl -v 直接打 IP 绕过 DNS；telnet IP 443 看端口通不通——不通查安全组/防火墙/LB 后端健康状态。④ 网关层：端口通但响应 5xx——看 nginx 错误日志：502 后端挂（查后端进程/端口/OOM），504 后端慢（查慢在哪）。⑤ 应用层：后端进程日志、线程池/连接池满、依赖的数据库/缓存/下游是否故障。⑥ 资源层：主机 CPU/内存/磁盘/IO，K8s 里再查 Pod 状态和事件。心法：每一步用'换个变量'来二分（换用户、绕 DNS、直连 IP、打本地），快速缩小到一层再深挖，同时盯监控大盘对照时间点有没有变更——80% 的故障前面有一次变更，先回滚再排查是铁律。

回答思路 · 考点拆解与追问预防

按流量路径分层+每层一个'二分动作'+'变更优先回滚'的实战心法。面试官想听的就是这种有条理又能落地的方法论。

Q108 ｜ 2026 最新搜集

域名打不开但 IP 能访问，什么问题？

我的回答 · 第一人称，结合简历

基本锁定 DNS 解析环节，分三段查：① 解析有没有结果：dig +trace / nslookup 看是 NXDOMAIN（记录不存在/已删）还是无响应（DNS 服务器不可达）。② 结果对不对：解析出来的 IP 是不是当前业务 IP——常见坑：变更后 TTL 没到期客户端还用旧缓存（dig 看剩余 TTL）、本地 /etc/hosts 或 /etc/resolv.conf 被改、公司内网 DNS 劫持。③ 谁的问题：换公共 DNS（223.5.5.5/8.8.8.8）能解——本地/运营商 DNS 的问题；也不解——权威侧问题，查解析商控制台记录、健康状态。容器场景再叠一层：CoreDNS 是否正常（kube dns pod、forward 上游）。处置原则：先确认权威记录正确，再让受影响用户刷缓存或降 TTL 等待收敛——所以我在变更前会先把 TTL 调低。

回答思路 · 考点拆解与追问预防

三段诊断（有没有/对不对/谁的锅）+容器分支（CoreDNS）+变更前降 TTL 的预防习惯。

AI 与 AIOps

共 1 题

Q112 ｜ 2026 最新搜集

AI 大模型在运维里怎么用？谈谈 LLM、Agent、MCP 和 AIOps。（2026 加分热点）

我的回答 · 第一人称，结合简历

我的理解分四层：LLM 是大脑——文本理解与生成；运维场景：日志摘要、报错解释、告警内容润色、Runbook 问答。RAG 给它外挂知识库——把 SOP、历史故障工单、架构文档向量化检索后喂给模型再回答，解决幻觉和私有知识问题，我设想过拿实习积累的故障工单做 RAG，新人排障时直接问。Agent 是手脚——LLM 加上规划、工具调用和记忆，能多步执行：接收告警→查监控→读日志→给出诊断甚至执行预案。MCP 是工具接口协议——标准化'模型怎么调用外部工具/数据源'，接 Prometheus 查询、kubectl、工单系统都是即插即用的 MCP server。落地原则：AI 先做只读诊断和摘要（风险低收益直接），写操作必须权限管控+人工确认——告警收敛和根因推荐先行，自动修复审慎推进。我自己的实践是调 LLM API 做日志聚类摘要的小工具，对重复告警的降噪效果很明显，这也是我简历上 AIOps 方向的底气。

回答思路 · 考点拆解与追问预防

四层概念+运维场景映射+'只读先行、写操作管控'的安全边界。最后落到自己做过的小工具——正好接住简历 AI 那条的深挖，把审计里提醒的'高危吹牛区'变成差异化亮点。