简介一份面向运维工程师岗位的面试题库聚焦 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和awaitdf -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_DAYS7 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}) THRESHOLD20 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, errorsignore) 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使用errorsignore避免日志中个别乱码行让整个脚本中断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或rangekey列是否用到目标索引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通过标签选择器关联Endpointskube-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 KillK8s层面则可能杀掉容器甚至驱逐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参数。抓包文件里同样一段数据乱序导致的快速重传和真正的丢包重传处理方向完全不同。现象4DNS排查只用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变化”。这套“怎么验证它真的对了”的表达是区分老手和新手最明显的地方。我组织过很多次备考最深的教训是面试中答不出的点平时在测试环境也多半没有亲手排过。与其背题不如把七个领域的关键路径各练顺手。祝面试顺利希望帮到你。本文还有配套的精品资源点击获取