简介这份运维工程师面试题库覆盖Linux、Shell、Python、MySQL、Docker、Kubernetes与网络七大方向适合准备中级运维岗位面试或系统自查技术短板的开发者。题目以问答形式整理既包含进程查看与nginx日志统计、根分区满排查、find批量查找并打包等Linux实操也涉及Shell变量含义、批量创建用户脚本、IP连通性检查与URL状态码验证Python部分涵盖数据类型、深浅拷贝、生成器与常用模块MySQL部分讲清delete、drop、truncate区别、主从原理及事务隔离级别容器和编排方面则总结了Docker状态与端口映射、Dockerfile常用指令及COPY与ADD的差异、K8s核心组件与Pod健康监测、数据持久化方式网络模块还覆盖OSI七层、TCP/UDP区别、三次握手与HTTP状态码。资源共1个PDF文件整包约890KB内容紧凑便于离线阅读与快速刷题。目前已有674人学习下载可作为面试冲刺前的集中复习清单。1. 运维工程师面试题面试官到底在考什么运维工程师面试题从来不是靠背题能过的尤其当它同时覆盖 Linux、Shell、Python、MySQL、Docker、K8s、网络这七个方向时面试官真正想看的不是你会敲多少命令而是你遇到故障时有没有一套自己的排查思路。Linux 和 Shell 是基本功Python 是自动化能力MySQL 体现你对数据可靠性的理解Docker 和 K8s 代表你是否跟上了云原生运维的趋势网络则是所有排障绕不开的底层。很多准备面试的朋友容易陷入“刷题模式”把命令和概念背得滚瓜烂熟一到追问环节就露怯。这篇笔记我按七个方向拆成六章每章都从面试官的真实考察意图出发给你答题的切入点和落地细节尽量少讲空话多写能复现的命令和思路。2. Linux与Shell命令、文本处理与手写题的答题套路2.1 Linux高频命令除了背参数还要能说清原理Linux 命令是运维面试的第一关但面试官早就厌倦了“top 看 CPUfree 看内存df 看磁盘”这种流水账回答。他们更希望你解释现象背后的原理。比如被问到“系统负载过高怎么办”你光回答“用 top 看 load average”是不够的要接着说load average 是运行队列的平均长度包含了正在运行的和不可中断睡眠的进程数。如果负载高但 CPU 使用率不高大概率是 IO 等待比如磁盘慢或 NFS 卡住如果 CPU 用户态和系统态都高才考虑是计算密集问题。我一般会给出一套组合命令面试时这样答会比较加分# 先看系统负载1/5/15分钟三个值 uptime # 每秒刷新一次共5次看r和b列 vmstat 1 5 # 再对可疑进程做线程级观察 top -H -p PIDvmstat里r代表运行队列中的进程数b代表不可中断睡眠的进程数。如果b明显很大说明有进程阻塞在 IO 上wa列IO 等待占比也会跟着涨。top -H -p是看某个进程内部的线程消耗定位是线程死循环还是锁等待。还有一个细节经常被问到top默认按 CPU 排序但如果是内存问题应该进去按M键如果找不到了按P切回 CPU 排序。这类快捷键也值得提前练。被问“怎么查某个端口被谁占用”也是高频题。别只答netstat -tunlp要补一句-t是 TCP-u是 UDP-l是监听-p显示进程名。另外还要知道新版系统偏ss因为netstat可能没装而且ss更快ss -tunlp | grep 3306这里grep 3306不是精确匹配如果你见过:3306和:33060都会被筛出来必要时用\b或awk做边界匹配。面试时主动说出这个细节面试官会觉得你真在路上排过障。2.2 文本处理三剑客grep、awk、sed的使用与边界Shell 手写题里文本处理是重头戏。面试官常给一个日志文件让你统计接口调用次数、提取 IP、替换配置。grep负责筛选awk负责列处理sed负责替换。三者的边界要清楚grep只能做匹配不能做算术awk适合做分组统计sed最擅长按行做增删改。一个经典题统计 access.log 中每个 IP 的访问次数按次数倒序。我常用这么写awk {print $1} access.log | sort | uniq -c | sort -rn | head -20逻辑说明awk {print $1}是默认按空格或 tab 分隔取第一列即 IPsort先把相同的 IP 排到一起uniq -c统计去重后的出现次数sort -rn按数字倒序head -20取前 20 行。注意uniq只能去除连续重复的行所以前面必须先sort如果忘记排序统计结果会乱。这一点经常被拿来挖坑。另一个题把配置文件里listen 80;改成listen 8080;但不能用编辑器只能命令行sed -i s/listen 80;/listen 8080;/g nginx.conf-i是原地修改如果担心改错可以先去掉-i预览输出确认后再加。s是替换命令g是全局默认只替换每行第一个匹配。这里有个坑listen 80;也可能匹配listen 8000;因为正则里的80不是单词边界。更稳妥的写法是s/listen 80;/listen 8080;/g之前先sudo grep -n listen 80看上下文或者用\bsed -i s/listen 80\b;/listen 8080;/g加边界。这种细节很体现经验。如果要把日志里所有 DEBUG 行删掉grep -v DEBUG就能做但面试官可能会追问“你为什么不写 sed”这时候你要说grep -v是过滤sed是修改如果只是要看结果grep -v更安全因为不会动原文件如果是脚本里要原地清理才用sed -i。回答这个边界比背命令强得多。2.3 面试手写题统计日志、查找大文件、批量处理运维面试几乎必考“磁盘空间告急怎么快速找出大文件并处理”。我常用的命令是# 找出 /var/log 下大于 500M 的文件并显示大小 find /var/log -type f -size 500M -exec ls -lh {} \; # 如果确认要清理用 truncate 而不是 rm find /var/log -type f -size 500M -exec truncate -s 0 {} \;find的参数要解释清楚-type f只找普通文件避免匹配到目录-size 500M表示大于 500M注意这里不能省略-exec ls -lh {} \;是逐个执行{}是占位符\;表示命令结束。面试中有人会问为什么不用rm清理日志文件如果用rm删除进程可能还持有文件句柄磁盘空间其实不会立刻释放而且日志文件一般需要保留一段时间所以更稳妥是truncate -s 0清空内容。这个区别是加分项。另一个手写题是“批量重命名某目录下的 .txt 文件改成 .bak”。我一般写一个 Shell 循环for f in ./*.txt; do mv $f ${f%.txt}.bak done这里的关键是${f%.txt}它是 Shell 参数扩展表示去掉末尾的.txt后缀。双引号包住$f是为了防止文件名带空格。如果面试官追问“如果你有 10 万个小文件这条命令会不会慢”你要知道./*.txt会先展开成参数列表可能超出 ARG_MAX这时候应该用find ... -exec配合mv比如find . -maxdepth 1 -name *.txt -exec mv {} {}.bak \;但这里改成{}.bak实际上会变成xxx.txt.bak和上面语义不同所以只能说明替代方案。这种“命令边界”的讨论面试官非常喜欢。3. Python与MySQL自动化脚本和数据库排查的实战题3.1 Python运维脚本从字符串处理到系统调用Python 在运维里主要用来做监控、发布、巡检和告警。面试题通常是“写一个脚本检查磁盘使用率超过 80% 告警”。我一般先写最简版本再用追问补充健壮性#!/usr/bin/env python3 import shutil threshold 80 usage shutil.disk_usage(/).percent if usage threshold: print(fWARN: disk usage {usage}% {threshold}%) else: print(fOK: disk usage {usage}%)shutil.disk_usage返回一个元组.percent是已用百分比简单直接。这段代码的逻辑很清楚但面试官可能会问“如果/没满但某个数据盘满了怎么办”这时候应该遍历所有挂载点。另一个角度是“怎么检测 inode 满了”因为磁盘有空间但 inode 耗尽也会报 No space left。这时要用os.statvfs看f_files和f_ffree。能把 inode 问题带出来说明你处理过真实磁盘故障。再一个常见题是“写一个脚本连接数据库查询状态并打印”。很多人会回答pymysql但面试官更希望看到你处理异常和连接超时#!/usr/bin/env python3 import pymysql try: conn pymysql.connect( host127.0.0.1, port3306, usermonitor, passwordsecret, databasemysql, connect_timeout3 ) with conn.cursor() as cur: cur.execute(SHOW GLOBAL STATUS LIKE Threads_connected) row cur.fetchone() print(f{row[0]}: {row[1]}) conn.close() except pymysql.Error as e: print(fERROR: {e})这里重点是connect_timeout3防止数据库无响应时客户端一直卡死with conn.cursor()确保游标自动关闭pymysql.Error捕获数据库错误。面试时你还可以提一句生产环境不应该把密码写在代码里可以放环境变量或配置中心比如os.environ.get(DB_PASSWORD)这句话很能给简历加分。3.2 MySQL必背索引原理、慢查询与备份恢复MySQL 是运维面试的必考项问题集中在索引、慢查询和备份恢复。先说索引原理面试官常问“为什么 MySQL 用 B 树而不是 B 树或哈希索引”。你要答出几个要点B 树所有数据都存储在叶子节点非叶子节点只存索引键这样树更矮更宽减少磁盘 IO 次数叶子节点之间通过双向指针连接适合范围查询而哈希索引只适合等值匹配没办法做范围查询。如果能再提一句“InnoDB 的聚簇索引是主键叶子节点直接存整行数据二级索引存主键值”那基本技术面就过了。慢查询这块面试官给了你一个“线上数据库突然变慢”的场景我一般按这个路径排查-- 查看是否开启慢查询日志 SHOW VARIABLES LIKE slow_query_log; -- 如果有权限开启并设置阈值 SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 2; -- 用 EXPLAIN 分析一条可疑 SQL EXPLAIN SELECT * FROM orders WHERE order_no SN123456;EXPLAIN的输出里重点看type字段从const、eq_ref、ref到ALL是性能变差的方向ALL表示全表扫描说明没走索引。rows是预估扫描行数结合Extra里的Using filesort或Using temporary基本上就知道瓶颈在哪了。面试时可以说“我一般先用EXPLAIN看执行计划再决定是加索引还是改写 SQL”这是标准答案。备份恢复也是高频题。我常用的逻辑备份命令是mysqldump -u root -p --single-transaction --master-data2 mydb mydb_$(date %F).sql参数说明--single-transaction在 InnoDB 下做一致性快照不锁表--master-data2会在备份文件中记录 binlog 位置方便恢复后做主从同步$(date %F)输出今天日期比如mydb_2025-01-01.sql。如果面试官问“线上大表备份要不要锁表”你可以说 InnoDB 下用--single-transaction避免锁表但要注意期间 DDL 可能造成备份不一致。如果表是 MyISAM必须加--lock-all-tables。这又是区分新手和老手的地方。3.3 常见面试题如何写一个数据库监控脚本结合 Python 和 MySQL 的场景题我遇到过一个比较有代表性的监控 MySQL 连接数超过阈值告警。核心思路是查Threads_connected和max_connections计算比例。#!/usr/bin/env python3 import os import pymysql config { host: os.environ.get(DB_HOST, 127.0.0.1), port: 3306, user: os.environ.get(DB_USER, monitor), password: os.environ.get(DB_PASS, ), connect_timeout: 3, } try: conn pymysql.connect(**config) with conn.cursor() as cur: cur.execute(SHOW GLOBAL STATUS LIKE Threads_connected) connected int(cur.fetchone()[1]) cur.execute(SHOW VARIABLES LIKE max_connections) max_conn int(cur.fetchone()[1]) usage connected / max_conn * 100 if usage 80: print(fALERT: connections {connected}/{max_conn} ({usage:.1f}%)) else: print(fOK: connections {connected}/{max_conn} ({usage:.1f}%)) conn.close() except pymysql.Error as e: print(fERROR: {e})这里把连接参数从环境变量读取避免硬编码计算比例时注意要用int()转换因为SHOW返回的是字符串usage:.1f保留一位小数。如果面试官追问“除了连接数还要监控什么”你可以答“慢查询数、主从延迟、缓存命中率”然后重点说主从延迟可以用SHOW SLAVE STATUS里的Seconds_Behind_Master字段但这字段在某些压力下会显示 0更稳妥是对比主从二进制日志位置。有这类实战补充面试官会明显更认真听。4. Docker与K8s容器化和编排的面试高频点4.1 Docker面试题镜像、容器、网络与存储Docker 面试通常从“镜像和容器什么区别”开始。你要答镜像是只读模板容器是镜像的运行实例容器在镜像上增加了一层可写层。常问“为什么镜像是分层的”因为每一层复用后能节省存储比如多个镜像共用同一个基础层构建时能利用缓存。这个知识点最好配合 Dockerfile 来答FROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD [python, app.py]这里FROM指定基础镜像WORKDIR切换目录COPY是复制文件RUN是构建时执行命令CMD是容器启动时执行的命令。我一般会提醒几个坑COPY和ADD的区别ADD能解压本地 tar 包但行为不可控所以优先用COPYCMD和ENTRYPOINT的区别CMD可以被docker run后面的参数覆盖而ENTRYPOINT一般作为固定入口。如果 Dockerfile 里RUN pip install和COPY . .顺序写反了那每次源码改动都会导致pip重新安装构建缓存就废了。这个细节面试时主动说出来会显得你真写过 Dockerfile。网络方面最常问“容器怎么和宿主机通信”。默认 bridge 网络容器通过 NAT 访问外网用端口映射-p 8080:80把宿主机 8080 端口转发到容器 80 端口。host网络则直接使用宿主机网络栈性能好但端口冲突生产环境按需使用。数据存储上-v挂载目录到容器比如docker run -d --name web -p 8080:80 -v /data:/var/www/html nginx-v左边是宿主机目录右边是容器目录。注意目录不存在时 Docker 会创建但如果宿主机目录里有内容它会遮盖容器目录里的原内容这也是常见的“挂载后网站打不开”的原因。4.2 Kubernetes面试题Pod、调度、控制器与服务发现K8s 面试高频题是“Pod 和容器什么关系”以及“为什么需要 Service”。Pod 是 K8s 里最小的调度单元可以包含一个或多个容器一般建议一个 Pod 只跑一个主容器加一个 sidecar 做日志或代理。容器挂了Pod 内重启但 Pod IP 会变化所以需要 Service 提供稳定的 ClusterIP 和 DNS 名称。这个逻辑必须讲清楚。一个标准的 Deployment 部署我写在白板上是这样的apiVersion: apps/v1 kind: Deployment metadata: name: web namespace: production spec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: web image: nginx:1.25 ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 256Mi几个必答点replicas: 3是期望副本数控制器会保证集群里正好有 3 个 Podselector.matchLabels用来匹配管理哪个 Podresources.requests是调度时需要的资源limits是容器可用上限。如果requests和limits不设置Pod 可能会被调度到资源紧张节点也可能被 OOMKill。面试常问“你的服务突然重启怎么办”很大概率就是内存超过了limits被内核 OOM 杀掉了。调度这块常问“Pod 跑到哪个节点怎么控制”。答案有nodeSelector、nodeAffinity、podAntiAffinity、taint/toleration。我一般先说最简单的nodeSelectorspec: nodeSelector: disktype: ssd如果面试官追问“如果你希望两个 Pod 不要调度到同一台机器怎么做”那要用podAntiAffinity比如affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: topologyKey: kubernetes.io/hostname这个有点复杂但你只要能说出来“用 topologyKey 以节点为维度做分散调度”面试官就会觉得你在生产环境用过。4.3 场景题从镜像构建到K8s部署的完整链路这一步是综合题面试官可能让你把“一套应用从代码到 k8s 对外提供服务”讲一遍。我习惯按这条链路走写 Dockerfile→构建镜像→推到镜像仓库→写 Deployment YAML→kubectl apply→创建 Service。# 构建镜像 docker build -t registry.internal/app:v1 . # 推送到私有仓库 docker push registry.internal/app:v1 # 部署到集群 kubectl apply -f deployment.yaml # 查看滚动状态 kubectl rollout status deployment/web # 如果镜像有更新直接设置新版本 kubectl set image deployment/web webregistry.internal/app:v1 # 暴露服务或在YAML里用Service方式 kubectl expose deployment/web --typeClusterIP --port80kubectl expose这里只是快速方式生产环境我一般会单独写 Service YAML因为要指定selector和端口名比如apiVersion: v1 kind: Service metadata: name: web namespace: production spec: type: ClusterIP selector: app: web ports: - port: 80 targetPort: 80port是 Service 对外端口targetPort是容器里的端口。如果面试官问“滚动更新时怎么保证不中断”你可以答kubectl rollout保证旧版本 Pod 逐步减少新版本逐步增加前提是镜像拉取策略和就绪探针要配置好。就绪探针很关键readinessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 5 periodSeconds: 10它决定 Service 是否把流量发给这个 Pod如果某个 Pod 没通过就绪检查会被摘除。这个细节是滚动更新不中断的核心。5. 网络面试题与常见问题避坑五个高频翻车点5.1 网络基础题TCP三次握手、DNS解析、HTTP状态码网络题从三次握手开始。你要能画出来没问题但面试官更爱问“为什么不是两次握手”。标准原因是防止历史失效的连接请求到达服务端导致服务端建立无效连接浪费资源。比如一个旧 SYN 报文本该失效但服务端收到了如果两次握手就建立连接客户端可能没有准备好而三次握手时客户端回应的 ACK 如果丢失或不期望服务端不会确认建立。另一个角度是双方需要共同确认“我的发送、你的接收”都没问题三次才能让双方都确认链路可用。DNS 解析过程也常考。完整的说一遍浏览器缓存查不到→操作系统缓存→检查 hosts 文件→发请求到本地 DNS 服务器→本地 DNS 迭代查询根域名服务器、顶级域名服务器、权威域名服务器→返回 IP。面试官如果追问“怎么排查 DNS 问题”我一般说用nslookup或dignslookup api.example.com dig trace api.example.comdig trace可以看到完整迭代过程能定位是根域还是哪一层出了问题。HTTP 状态码也是高频尤其要分清301 永久重定向、302 临时重定向、403 禁止访问、404 页面不存在、500 服务器内部错误、502 网关错误、503 服务不可用、504 网关超时。容易被问“502 和 504 区别”502 是 Load Balancer 或代理收到了上游无效响应504 是代理等不到上游响应超时。运维场景里 502 常见是后端容器挂了504 常见是后端 SQL 慢或进程阻塞。5.2 网络排查题连接超时、丢包、端口不通的排查路径网络排查是实战题。面试官给一个场景“用户反馈接口超时你怎么排查”。我会按从下往上的顺序先看链路通不通再看端口监听再看服务响应。命令组合如下# 第一步ping 测连通性和延迟 ping -c 5 10.0.0.1 # 第二步检查远程端口是否可连 telnet 10.0.0.1 3306 # 第三步跟踪路由看在哪一跳丢包 traceroute -T -p 3306 10.0.0.1 # 第四步验证 HTTP 接口响应 curl -v -m 5 http://10.0.0.1:8080/api/healthping -c 5是只发 5 个包避免无限跑telnet能快速判断端口通不通但注意有时候 telnet 没安装可以用nc -vz 10.0.0.1 3306替代traceroute -T用 TCP 方式探测更适合看防火墙对 TCP 端口的放行情况普通的traceroute用 UDP 或 ICMP很多网络政策会禁止。curl -m 5是超时 5 秒避免一直挂死。如果端口通但接口超时就要到目标机器上看 CPU、内存、日志比如用top和journalctl -u web --since 10 min ago。面试时被问“ping 通了但业务连不上”原因可能包括防火墙只允许 ICMP 但禁止 TCP 端口服务只监听了 IPv6而客户端用 IPv4 访问服务启动在容器里端口映射没配对。能主动列出几种可能是加分项。5.3 避坑清单面试中的五个经典翻车现场以下五个问题是我在不同面试中看到容易翻车的点每条按现象、原因、解决顺序写准备的时候值得对照自查。翻车点 1被问“TCP 为什么需要三次握手”只背结论现象候选人说“防止服务器端资源浪费”但追问“为什么三次就能防止两次不行”就答不上来。原因只背了面经的简化答案没有真正理解双方同步机制。解决用自己的话解释第一次握手客户端说“我能发”第二次握手服务端说“我收到了并且我也能发”第三次握手客户端说“我收到了你也能发”。第二次握手同时确认了客户端的发送和服务端的接收但服务端的发送还没被客户端确认所以必须第三次。翻车点 2netstat 结果只认 ESTABLISHED 不认 LISTEN现象被问“怎么确认服务在监听”答“netstat -an | grep 端口”看到 ESTABLISHED 才放心。原因混淆了“正在连接的连接”和“等待连接的监听”。解决判断一个服务是否启动要看LISTEN状态比如ss -tln | grep 8080看到LISTEN才说明有人监听这个端口。大量ESTABLISHED只表示当前活跃连接数不能说明监听正常。翻车点 3MySQL 索引失效场景答不全现象面试官问“什么情况下索引会失效”只答出“like %xx”漏掉函数操作和隐式类型转换。原因平时只遇到过前模糊匹配没有系统总结。解决至少记四个典型场景LIKE %abc前模糊匹配、在索引列上做函数运算如DATE(create_time)2025-01-01、条件列发生隐式类型转换比如字符串列不写引号、组合索引不满足最左前缀原则。每一样都要能说原理。翻车点 4kubectl get pods 报错 No resources found只会发慌现象候选人说自己部署了 Deployment但kubectl get pods显示 No resources found以为是集群坏了。原因忽略了当前 namespace。很多 Kubectl 命令默认使用当前上下文里的 namespace而 Deployment 可能部署在production你默认看的default。解决先跑kubectl get pods -A或kubectl get deployment -n production确认 namespace 后再排查。更规范的做法是在 YAML 里显式写namespace比如metadata.namespace: production。翻车点 5Shell 单引号双引号分不清导致脚本报错现象写echo $USER正常改成echo $USER输出原文字符$USER候选人表示没想到。原因没有意识到双引号会做变量展开单引号是原样输出。解决记一个原则需要变量展开和转义用双引号需要原样字符串用单引号。如果要在单引号字符串里再用单引号用\转义或者改用双引号。面试手写脚本时这是最容易暴露出基础不扎实现象的地方。6. 面试进阶如何把运维经验讲出深度6.1 用“问题-分析-方案-验证”讲出你的项目运维面试到了最后环节面试官会问“讲一个你最有成就感的项目”。很多人从头到尾讲功能点讲得无比详细但没有一条主线。我习惯用四段式问题描述、定位分析、落地验证每个环节给出具体数据让人听得能跟着走。比如我处理过某次线上接口周期性超时我先说明现象是每 1 小时左右出现 2 到 3 个超时告警通过排除法发现和定时任务重合分析阶段用perf采样和日志比对最后定位到定时任务里有个 Java 进程发生 GC 停顿方案是把定时任务错峰加容器内存限制同时调低 GC 并发线程数验证方式是连续观察 24 小时超时率从 0.4% 降到 0.02%并且把监控图打到了汇报里。面试官在意的是你能不能清晰说出因果关系而不是“我用 xx 工具解决了 xx”这种功劳簿式描述。注意不要过度关注命令本身更应该讲清你的判断依据为什么查这个指标、为什么排除那个可能。哪怕最后不是最优解只要逻辑闭环也比背命令更有说服力。6.2 面对不会的题答题的“软着陆”技巧一定会有不会的题这并不致命致命的是直接说“不知道”或者硬编。我常用的策略是先复述一遍问题确认自己理解的是不是面试官想问的比如“您是不是想知道当 Pod 反复重启时我们怎么定位是 OOM 还是探针失败”。复述过程中你可能已经想起一部分内容。如果真的一点头绪都没有我会拆成已知和未知“我知道 OOM 会看kill -9或dmesg但这个版本的具体回收策略我不太确定我一般会先看某个指标再下判断。”这样既展示了推理过程也给了面试官补全问题空间的机会而不是冷场。另外一个实用技巧是遇到偏底层或偏内核的问题可以说“这个部分我生产环境接触不多但我理解的机制是……”。不要不懂装懂面试官通常能很快揭穿。错了反而影响整体印象坦诚加推理至少能保住沟通分的下限。6.3 验证自己的准备模拟面试与查漏补缺准备运维面试不能只看我写这几章就完事建议按下面的方向做一次自测。我在准备面试那两周每天随机抽一套题目对着键盘写命令而不是只背概念很多细节是在敲命令时发现的。方向必会内容自测方式Linux排查 CPU、内存、磁盘 IO 思路压测时观察 vmstat 输出Shell写一个多条件文本统计脚本在日志目录手动跑一遍Python写环境变量配置的监控脚本用 pytest 加一个简单断言MySQLEXPLAIN 分析慢 SQL在测试库造数据验证索引效果Docker写 Dockerfile 并看构建缓存变化改动文件顺序后对比时间K8sDeployment 滚动更新和回滚部署后kubectl rollout undo网络模拟丢包后定位链路用tc netem加延迟再做 curl模拟面试最好找同行或朋友互相出题重点不在正确答案而在于你能不能把思路讲完整。前面第 5 章列的那五条翻车点就是我模拟时踩过的坑每一条都来自真实环境里的误操作后来才总结成查漏清单。说回开头那句话运维工程师面试题洋洋洒洒铺开七块内容但核心始终是“你会不会把一个线上异常拆成可验证的假设”。日常多动手多关注命令背后的机制才是对抗面试焦虑的真正靠山。希望这一篇整理能帮你在准备时少走一些弯路祝顺利。本文还有配套的精品资源点击获取