简介：一份面向运维工程师岗位的面试题库，聚焦 Linux、Shell、Python、MySQL、Docker、Kubernetes 与网络七大高频方向，适合正在准备中高级运维面试的求职者，也适合团队开展技术摸底与知识查漏补缺。内容按模块组织，覆盖进程与文件系统管理、Shell 变量及脚本编写、Python 数据类型与迭代器、MySQL 主从原理和事务隔离级别、Docker 容器状态与 Dockerfile 指令、K8s 核心组件与数据持久化方式，以及 TCP/UDP、HTTP 等网络基础题。题目不是简单罗列，还穿插场景化问题与命令排查示例，例如根分区满如何定位、判断在线 IP、检查 URL 可用性、启动并挂载 Nginx 容器等。资源整理为一份 PDF 文档，大小约 890KB，虽仅 1 个文件但知识点密度较高，便于集中翻阅和考前冲刺。目前已有 674 人浏览学习，是一套贴合运维面试高频考点的实用复习资料。
1. 运维面试到底在考什么：七个技术点的同一张考卷
先说一个反直觉的观察：运维面试被刷的人，大多不是不会技术，而是把技术答成了背课文。面试官问“线上CPU飙高你怎么查”，有人能从top背到vmstat，却不说先看哪个指标、什么时候该怀疑谁。这份面试题的标题圈定了七个技术点——Linux、Shell、Python、MySQL、Docker、K8s、网络，看似各自独立，实际考的是同一件事：你知不知道组件原理，你能不能动手把事情查出来、修好并验证。对带运维岗的团队来说，他们要的是一个能进生产环境接手事故的人，不是一个默写命令的人。下面按这七块拆解高频考点、手写题目与踩坑记录，适合准备运维和SRE岗位面试的人，也适合需要把“会背”变成“会做”的开发同学。
2. Linux与Shell：高频命令与手写脚本的思路
2.1 高频命令题在问什么：top、ss、ps 背后是一条定位链
运维面试的Linux题很少直接让背参数，开场通常是“线上CPU高了你怎么办”，随后用top不断追问。所以答题顺序本身就是考点：先用top看负载与CPU比例，接着用ps -eo pid,comm,%cpu --sort=-%cpu找进程，再用top -H -p看线程，必要时用perf top看热点函数。这一串不是命令清单，而是一条“负载→进程→线程→热点”的定位链，答完这条链，面试官才会认为你是真排过障。
端口类是另一个高频场景，问“8080端口被占你怎么查”。我一般答：ss -lntp | grep 8080看监听状态，ss -tpn | grep 8080看已有连接，再配合lsof -i:8080确认进程。面试官常追问为什么不优先用netstat，这时要答：ss直接读内核socket信息，在连接量大时比netstat遍历文件描述符更快，这也是新系统默认装ss的原因。顺着这个点还能带出“监听端口”和“已建立连接”的区别，说明你分得清服务是否真的在对外提供能力。
进程状态题也常出现，重点是ps输出里的D和Z。D是不可中断睡眠，通常和IO排队有关，磁盘慢或存储设备卡住会积压一堆D进程；Z是僵尸，代表子进程退出后父进程没有调用wait回收。这类题想听的是“看到D能不能想到IO、看到Z能不能想到父进程”，而不是背字母意义。回答时补一句“僵尸进程要看父进程能不能重启或回收，不能直接kill -9”，就能和只背概念的人拉开差距。
磁盘与IO题同样高频：iostat -x 1看util和await，df -h看空间，du -sh *看目录占用。追问“磁盘满了却找不到大文件”时，要想到已删除但还被进程占用的文件，用lsof +L1列出再确认进程能否重启。这个案例能体现排查链路不只在命令本身，还在于你知道文件系统“空间被占”和“文件被删”是两回事。
systemd题也一样。systemctl status看服务状态和最近日志，journalctl -u看单元日志，systemctl list-unit-files看开机自启。我会把“查服务→查日志→查自启”串成一句话回答，面试官顺着问“服务起不来怎么办”，再补systemctl status里的Active状态与journalctl -xeu的报错片段，整条链路就闭合了。
2.2 手写Shell脚本：清理日志与CPU监控两类典型题
一类是日志清理脚本，面试官常要求写出“保留近7天日志，删除更早文件”：
#!/bin/bash # 保留近7天日志，删除目录下更早的.log文件，并输出清理明细 LOG_DIR="/var/log/myapp" KEEP_DAYS=7 if [ ! -d "$LOG_DIR" ]; then echo "目录不存在: $LOG_DIR" exit 1 fi # -mtime +N 匹配修改时间超过N天的文件，-print 在删除前记录文件名 find "$LOG_DIR" -type f -name "*.log" -mtime +$KEEP_DAYS -print -delete df -h "$LOG_DIR"逻辑说明：脚本先做目录存在性判断，避免在cron环境里因变量为空而跑进错误路径；find的-mtime +7匹配超过7天未修改的文件，-print先打印再-delete删除，方便留审计记录。参数说明：KEEP_DAYS按日志保留策略调整，LOG_DIR必须写绝对路径，因为cron的PATH很精简，相对路径是常见翻车点。生产接入前，建议先用-ls替代-delete试跑一轮，确认命中文件数和预期一致，再放开删除。
另一类是CPU监控脚本，考察“采样和判断”而不是语法：
#!/bin/bash # 当CPU空闲率低于20%时，记录Top5进程并写入系统日志 # CPU_IDLE 取 vmstat 两次采样中的第二次，避免启动瞬时值干扰 CPU_IDLE=$(vmstat 1 2 | tail -1 | awk '{print $15}') THRESHOLD=20 if [ "$CPU_IDLE" -lt "$THRESHOLD" ]; then # 先留现场再告警，防止故障现场被后续操作覆盖 ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -6 > /var/log/cpu_alert_$(date +%Y%m%d_%H%M%S).log logger -t cpu_monitor "CPU idle ${CPU_IDLE}%, below threshold ${THRESHOLD}%" fi逻辑说明：vmstat 1 2表示间隔1秒采样两次，第一次是调用瞬间的值，第二次更稳定，tail -1取最后一行，awk取第15列idle；判断写成“空闲率低于阈值”而不是“使用率高于阈值”，数值关系更直观。参数说明：THRESHOLD与采样次数可按监控粒度调整；生产上建议由cron每5分钟调度，不要常驻循环，避免监控脚本本身抬高了负载，这一点面试官经常追问。
2.3 综合排查思路：现象、定位、确认、恢复
面试官常把Linux与Shell串成综合题：“用户反馈页面打不开，你怎么排查？”这时候背命令无效，要答步骤。我一般按四步走：先确认现象是超时、报错还是拒绝；再按“客户端→网络→服务端”分段定位；关键操作前先留现场，抓包或保存日志；恢复后主动验证。这套顺序能串联零散考点，也是我处理线上故障攒下来的血泪经验。
具体展开：现象登记要明确偶发还是必现、影响范围多大，常见做法是先用ping和telnet端口做分层，能挡掉一半问题。定位顺序建议是系统层先看load与CPU、内存、磁盘IO，再进程层看top和ps状态，最后应用层看日志与慢查询，顺序反了很容易被应用日志里的表面错误带偏。留现场环节，dmesg、journalctl、抓包文件先落盘再操作，重启会毁掉事故现场。恢复与验证阶段，先止血再根治，恢复后模拟请求确认服务真的可用，而不是进程活着就算好。这套框架答下来，比单独堆命令更接近生产环境里真正要做的事。
3. Python与MySQL：日志脚本与数据库优化的高频题
3.1 Python运维题的真面目：不考框架，考处理思路
运维面试里的Python通常不考Web框架，考脚本能力和自动化意识。常见三类：日志文本处理、批量运维操作、小工具编写。考察点集中在会不会用标准库、会不会控制内存与异常、能不能把脚本接到现有流程里。答题顺序建议先讲思路再动笔，面试官更关心对数据的遍历逻辑，而不是语法技巧。比如处理一个大文件，先问清楚文件格式、行数级、要不要保留中间态，再决定用正则还是字符串切分。
批量操作题也经常出现，常见做法是写一个分发脚本，用并发池限制同时执行的机器数，每台机器单独拿到结果。我一般会强调三点：连接要设置超时，避免一台机器卡死拖垮整个任务；结果要按IP落盘，方便对账；执行前先打印要执行的命令做一次演练，而不是直接铺到几百台机器上。这三点比“会用paramiko”更能证明你有批量操作的经验。
3.2 手写日志分析脚本：从正则到统计
#!/usr/bin/env python3 # 统计Nginx access.log 中访问次数Top5的IP # 常见做法是逐行匹配行首IP，而不是一次性 read() 全部读入 import re from collections import Counter LOG_PATH = "/var/log/nginx/access.log" # 匹配IPv4地址：四段数字，分组用于提取完整IP ip_pat = re.compile(r"^(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})") counter = Counter() with open(LOG_PATH, "r", errors="ignore") as f: for line in f: m = ip_pat.match(line) if m: counter[m.group(1)] += 1 for ip, cnt in counter.most_common(5): print(f"{ip}\t{cnt}")逻辑说明：open使用errors="ignore"，避免日志中个别乱码行让整个脚本中断；for line in f按迭代器逐行读取，不会把几十GB的日志一次性加载进内存；most_common(5)直接返回计数最高的前5项。参数说明：如果要统计请求路径或状态码，把正则的可变段替换成对应分组即可；LOG_PATH建议由命令行参数传入，方便复用而不是每次改脚本。
面试官如果追问“日志有几十GB怎么办”，重点不是换语言，而是讲清楚逐行处理已把内存压平，瓶颈在IO；要更快可以按时间切片做并行分片，或者把统计结果落成流式中间值。能讲出这条思路，比贴一段pandas代码更能体现运维视角。如果日志里混了IPv6地址，正则就要按冒号分段的规则调整，这也是数据格式意识的一个体现。
3.3 MySQL高频题：主从复制、索引失效与慢查询
MySQL题目的高频区间很集中：主从复制原理、索引失效、慢查询、事务隔离级别。答主从复制时我习惯按一条链路讲：应用写主库→主库写binlog→从库IO线程拉日志写入relay log→SQL线程重放。面试官通常接着问binlog格式：row格式记录变更后每一行的值，最准确，但日志量大；statement格式记录原始SQL，量小但部分函数在主从执行结果可能不一致；mixed是两者折中。能区分三种格式，就明显区别于只会背“主从同步”的候选人。
索引题里反复出现的坑是：在索引列上套函数、隐式类型转换、左模糊like都会让索引失效。EXPLAIN输出重点看type、key、rows三列，type为ALL时基本能断定全表扫描。SQL优化题的标准回答顺序：先EXPLAIN看执行计划，再确认where条件字段的索引，再看查询字段能否只走覆盖索引，最后才调整SQL结构，不能上来就改语句。
慢查询定位也常考：确认slow_query_log是否开启，分析慢SQL日志里的Rows_examined与耗时，再用EXPLAIN验证优化效果：
-- 慢查询定位：先确认执行计划，再决定是否补索引或调整查询结构 EXPLAIN SELECT u.id, u.name, o.order_no FROM user u LEFT JOIN orders o ON u.id = o.user_id WHERE u.status = 1 AND o.created_at > '2024-01-01';逻辑说明：EXPLAIN不会真正执行SQL，只输出执行计划；关注type列是否从ALL变成ref或range，key列是否用到目标索引，rows列估算扫描行数是否明显下降。参数说明：u.status = 1如果有索引但区分度低，优化器可能放弃索引；o.created_at列上如果没索引，说明需要补一个复合索引，覆盖user_id + created_at两个条件会更有效。回答时给结论：生产环境优先保证数据一致性与刷新，再谈性能调优。
4. Docker与K8s：容器编排面试的完整回答链
4.1 Docker考点：镜像分层、生命周期与数据持久化
Docker的面试题一般围绕三条线：镜像怎么构建、容器怎么跑、数据怎么持久化。镜像分层是最该讲透的题目：Dockerfile每条指令生成一个只读层，层可复用，容器运行时才在只读层上叠加可写层，写时复制发生在容器层。答到“多个容器共享同一个基础镜像的只读层”就抓住了核心，这也能解释为什么镜像比虚拟机轻，以及为什么构建时要把不常变的依赖放在Dockerfile前面。
生命周期题常借“为什么kill不掉容器”来问。答案要点是PID命名空间、进程信号和主进程的处理逻辑：docker stop先发SIGTERM，超时后发SIGKILL；如果容器内的主进程没有正确捕获SIGTERM做优雅退出，容器就会在超时后才被杀。排查顺序一般是docker top看进程、docker inspect看State.ExitCode和OOMKilled、docker logs看退出前日志，三步能定位多数情况。
数据持久化是容易答漏的点。volume由Docker管理，适合数据库等需要长期保存的数据；bind mount直接映射宿主机路径，方便调试但权限处理麻烦；tmpfs放临时文件不落盘。值得强调的细节是容器删除后volume不会跟着删，这个常被忽略，也是误删容器后找回数据的重要兜底。
4.2 K8s考点：Pod生命周期、探针与网络模型
K8s高频题我归成三组：Pod生命周期与状态、探针、网络模型。Pod生命周期题常问“Pod一直Pending怎么办”。答题时先说kubectl describe pod看Events，再按优先级查节点资源、镜像拉取、亲和性与污点约束。Events是K8s故障排查的第一现场，比看Pod状态本身更有信息量，很多人一上来就盯着STATUS列，其实是走错了方向。
探针题考三个概念的分工：livenessProbe决定容器是否重启，readinessProbe决定流量是否放入，startupProbe解决启动慢的容器被探针反复打断的问题。回答时把三者职责讲清，再顺带提一嘴YAML字段。比如Java应用启动慢，如果只配liveness，很可能在启动阶段就被连续失败重启，配一个startupProbe给足启动窗口，才是符合实际的解法。
网络模型题，我一般用“每个Pod一个IP、Pod内容器共享网络栈”开头，再讲Service通过标签选择器关联Endpoints，kube-proxy用iptables或ipvs转发；CNI插件负责为Pod分配IP，常见的是Bridge模式或Overlay模式。要点是把Pod、Service、kube-proxy、CNI四者的职责说成一条链，而不是单独背名词。被追问“Service找不到后端Pod时怎么办”，我习惯答：先kubectl get endpoints看Endpoints是否有地址，再看Service的selector与Pod标签是否一致，最后确认Pod是否Ready，三条查完基本能定位问题。
4.3 资源限制与镜像不可变：两个易答偏的落地细节
资源限制题问“容器内存超了会怎样”，Docker层面会发生OOM Kill，K8s层面则可能杀掉容器甚至驱逐Pod。这里有个常见混淆点：requests与limits的职责不同，requests是调度依据，决定Pod能落在哪个节点；limits是运行时硬上限，内存超限就会触发OOMKilled。答出“limit不等于预留，request才是调度依据”会明显加分。
# 典型Pod资源限制示例：request是调度依据，limit是运行上限 apiVersion: v1 kind: Pod metadata: name: demo-app spec: containers: - name: app image: demo-app:latest resources: requests: cpu: "500m" memory: "512Mi" limits: cpu: "1" memory: "1Gi"逻辑说明：requests里的cpu 500m表示半个核心，调度器按各节点可用量判断放置位置；limits里的cpu 1表示最多用一个核心，memory 1Gi是硬上限，超限容器会被杀掉。参数说明：Mi/Gi是二进制单位，m是千分之一核；内存limit不建议与request差太多，否则节点内存会因超卖被清空或驱逐。生产上还需要结合压测结果确定，不是照抄模板。
镜像仓库相关考题我提醒答两个点：镜像tag不是不可变标识，相同tag可能被覆盖，生产推荐用digest精确定位镜像；镜像删除后不能从仓库层直接恢复，正确做法是保留构建产物和digest记录，必要时做制品备份。诚实说“没有后悔药”，比假装能找回更可信。被追问“线上镜像被覆盖了怎么办”时，我的回答是先切回上一个可用digest，再从CI产物重建推送，同时补一条tag不可变策略，把问题从“急救”变成“根治”。
5. 网络与综合排查：从TCP到DNS的高频题与避坑记录
5.1 TCP与HTTP高频题：握手异常与状态码
网络基础必考TCP三次握手、四次挥手，但运维面试更偏向异常状态。我常用框架：握手看SYN、SYN-ACK、ACK是否成对；半连接队列或全连接队列满时会表现为连接超时或拒绝；TIME_WAIT堆积通常出现在高并发短连接场景。回答时把“现象→队列/状态→验证命令”串成一条线，比背状态含义更稳。比如连接超时先看ss -s里的SYN-RECV数量，再判断是半连接队列溢出还是丢包。
HTTP状态码也常考。502一般代表网关拿不到上游正常响应，504是上游响应超时，和502的区分在于是“没有响应”还是“响应太慢”。答题时我会补排查方向：502先看上线上游的连接与健康检查，504先看上游处理耗时与超时配置。只说含义不说排查，在运维面会显得单薄。如果被追问“502时后端进程还活着”，答案要点是进程活着不代表端口正常，也不代表健康检查通过，要用curl直接打后端探活，而不是看进程列表。
5.2 一条命令链收拢网络排查
现场题“用户说网站打不开”，我一般按这个命令链走：
# 1. 先确认三层连通性，ping只证明ICMP可达，不代表服务端口可用 ping -c 3 example.com # 2. 确认四层端口与TCP握手，-z 只探测不发送数据，-w 设置超时 nc -zv -w 3 example.com 443 # 3. 看DNS解析结果，排查解析到错误IP或本地缓存脏数据 dig +short example.com # 4. curl带超时拿响应码和耗时，区分网络问题还是应用问题 curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" --connect-timeout 5 https://example.com/ # 5. mtr看链路每一跳的丢包与延迟，适合跨公网链路定位 mtr -rw -c 10 example.com逻辑说明：ping、nc、dig、curl分别验证三层、四层、DNS、七层，哪一步先异常就往哪一层深入，避免在错误层浪费排查时间。参数说明：nc的-z表示只探测端口不传输数据，-v输出详情，-w 3是超时3秒；curl的--connect-timeout建议5秒，避免长时间挂起；mtr的-c 10表示探测10个包，-r是报告模式，-w是宽行输出，适合脚本化记录。
面试官接下来大概率追问“为什么ping通了但业务不通”。答案很直接：ping只测ICMP，证明不了TCP端口和HTTP服务；必须用nc确认端口，再用curl确认应用响应。这条回答能挡住一长串网络排查追问。如果每跳都通但业务仍异常，就要考虑防火墙策略、安全组或云平台转发规则，这些不会在ping结果里体现。
5.3 避坑记录：三个我见过最多人答错的网络题
现象1：把“一次完整的HTTPS请求”答成“先TCP三次握手再发请求”，漏了DNS、TLS握手和连接复用。原因：把课本分层和真实链路揉在一起。解决：按“DNS→TCP握手→TLS握手→HTTP请求→响应解析→连接关闭或复用”排成一条可复述链路，面试官一般会顺着链路追问每一步异常时看什么，链条完整就不会突然卡壳。
现象2：被问TIME_WAIT堆积只答“调小time_wait”，没说是哪一方触发、影响在哪个环节。原因：只背了优化项，不理解状态机。解决：先说明大量TIME_WAIT常见于服务端主动关闭短连接，不要盲目调tcp_tw_reuse；优先排查应用是否在频繁主动断开，考虑连接池或长连接方案。调参是最后手段，而且新内核里tcp_tw_reuse的生效条件很严格，背错参数比不答更扣分。
现象3：看到抓包里有TCP重传就直接说“网络丢包”。原因：没确认对端ACK与乱序情况。解决：对比seq与ack的差值，观察重复ACK和重传距离，结合业务流量判断是整链路丢包还是单条连接抖动，判定后再决定要不要切链路或调TCP参数。抓包文件里同样一段数据，乱序导致的快速重传和真正的丢包重传，处理方向完全不同。
现象4：DNS排查只用ping不用dig，拿到错误IP还继续查网络。原因：排查顺序不对，习惯先ping。解决：先dig +short拿到解析结果，再ping解析出的IP；如果怀疑本地缓存脏，先刷新缓存再走后续排查。域名解析是HTTP链路的最前端，这步错了，后面所有网络结论都会跑偏。
6. 面试现场技巧：把会的东西用五步框架讲清楚
面试过半，剩下考察的往往是“会不会表达”。我自己的习惯是：准备面试不靠刷题，而是把一台测试虚拟机刻意搞崩再修好，练到手指记得住命令。答题时我用一个五步模板，“现象—定位—确认—恢复—验证”，能套住绝大部分故障场景。
先说答题顺序。面试官问CPU高，不要从Linux启动讲到进程调度，先给结论：“我先用top看us与sy比例，us高查应用，sy高查系统调用与锁”，然后按定位链展开。原理题也一样，先给结论再给依据，例如主从复制先答“主库写binlog、从库IO线程拉取、SQL线程重放”，再展开格式细节。这样面试官能立刻抓到你的逻辑主干，追问也有抓手。
其次是写代码时主动讲边界。面试官看着你写Shell或Python时，强调“逐行读文件防内存占用”“find先试跑再delete”“脚本路径用绝对路径”，这些细节比完整写完脚本更体现生产经验。写脚本前先问一句“数据量大概多大、跑在什么环境”，比闷头写更容易得分，因为面试官考的就是能不能按真实场景收敛方案。
最后一个技巧是主动暴露验证方式。回答完“我用iptables做转发”后补一句“验证方式是临时加规则后从对端实际请求一次，确认生效再写持久化配置”；回答完“我开了慢查询日志”后补一句“取一条慢SQL做EXPLAIN对比优化前后rows变化”。这套“怎么验证它真的对了”的表达，是区分老手和新手最明显的地方。
我组织过很多次备考，最深的教训是：面试中答不出的点，平时在测试环境也多半没有亲手排过。与其背题，不如把七个领域的关键路径各练顺手。祝面试顺利，希望帮到你。
本文还有配套的精品资源，点击获取
