简介面向运维工程师岗位面试的一套 PDF 题库聚焦 Linux、Shell、Python、MySQL、Docker、K8s 与网络七大技术方向适合正在系统准备运维/DevOps 面试的求职者快速查漏补缺。资源仅包含 1 个 PDF 文件大小约 890KB内容按技术模块分层展开题量大且覆盖广Linux 部分涵盖进程查看与统计、nginx 进程数统计、du/df 磁盘排查、find 检索及日志分析Shell 部分包含内置变量含义、批量创建用户、IP 在线检测、URL 可用性检查等实操脚本Python 部分涉及数据类型与特性、深浅拷贝、常用内置函数、常见模块、生成器与迭代器并附带九九乘法表实现MySQL 部分梳理了 delete/drop/truncate 区别、varchar 与 char 差异、主从复制原理与延迟原因、事务隔离级别、优化及备份策略Docker 与 Kubernetes 部分则从镜像容器概念、常用命令、Dockerfile 指令延伸到 K8s 核心组件、etcd 作用、Deployment/Statefulset/Daemonset 控制器、Pod 健康监测与数据持久化方式网络模块覆盖 OSI 七层模型、TCP/UDP 场景与端口、三次握手四次挥手、HTTP 状态码与请求方法并附带 Linux 系统优化实际案例。目前已有 674 人学习适合作为面试前的高密度速览与知识框架梳理资料。1. 运维工程师面试题七条线背后的真实考点运维工程师面试题这个词拆开看就是 Linux、Shell、Python、MySQL、Docker、K8s、网络七条线。Linux 是底座Shell 和 Python 是自动化操作的两只手MySQL 是数据层Docker 和 K8s 是交付形态网络则是贯穿一切的那根线。我面试过不少候选人发现准备面试的人最容易犯两个错一是只刷题不追底层命令会敲但说不出原理二是只背概念不写代码一让手写脚本就卡壳。这篇笔记不列题库而是按面试官追问的习惯把七条线拆成命令怎么用、原理怎么答、现场怎么写、哪里会翻车四个角度覆盖初级到高级的常见考点。适合准备跳槽的运维、转岗开发的测试以及想系统查漏补缺的 SRE。2. Linux 与 Shell先过命令关再过脚本关运维面试的第一关几乎都是 Linux。面试官不太会问 ls 怎么用而是让你现场排查、亲手写命令。这一章按我的习惯分成三块高频命令的精确语义、系统排查的标准路径、Shell 脚本的手写与改错。2.1 高频命令的精确语义df、du、ss、lsof命令人人会敲但面试追问点恰恰藏在最常用的命令里。比如df -h和du -sh的区别很多人答df 看磁盘du 看目录这不算错但面试官真正想听的是df 读的是文件系统超级块里的统计du 是遍历目录树累加文件块所以 df 显示的是已分配空间du 统计的是实际占用。文件被进程删除但未释放时df 看到空间没减少du 却可能已经变小。这才是排查磁盘满但找不到大文件的钥匙。再比如端口排查。netstat -tunlp是老命令现在面试更常问ss因为 ss 直接读内核 socket 哈希表量大时不卡。查端口监听用ss -tlnp查连接状态用ss -tan。如果想知道某个进程打开了哪些文件用lsof -p PID或者用lsof -i :8080看谁占着 8080 端口。这里有个常见追问ss -tlnp里的l是 listeningn是数字显示不做反向解析p是显示进程名。解释了这三个参数才算把这题答完整。文件查找也常被考。find /data -name *.log -mtime 7 -type f -exec rm {} \;这类命令要能一眼说清每个段的作用-name按名字匹配-mtime 7表示修改时间在 7 天前-type f限定普通文件-exec把结果交给 rm。但我会建议候选人用-delete替代-exec rm {} \;写法更短特殊文件名也不会触发参数解析问题代价是少了确认过程。批量操作时用find ... | xargs -n 50能控制每次处理的参数个数避免出现Argument list too long。文本处理三件套 awk、sed、grep 是必考。grep 的关键参数是-E用扩展正则、-v反选、-c计数、-l只列文件名。sed 常被问-i做原地修改s/old/new/g的尾巴g不加的话每行只替换第一处。awk 的核心是{print $1}按空格分列-F改分隔符NR1处理第一行。面试里最常见的一道题是找出日志里访问量最大的 10 个 IP命令如下。awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这条命令的链路是awk 取第一列默认按空白分列sort 把相同 IP 归到一起uniq -c 统计重复次数并输出次数 IPsort -rn 按数字逆向排序head -10 取前十条。考官通常会追问一个变体如果日志格式是IP [时间] GET /url 200第一列还是 IP 吗这是提醒你别背命令要理解字段位置。2.2 系统排查的标准路径从 load average 到 io wait服务器负载高是面试里的开放题考察的是排查路径是否成体系。我一般会按这个顺序走先uptime看 load average 三个数判断负载是持续高还是瞬时冲高然后top看 CPU 占用和进程排序按P键按 CPU 排序、按M键按内存排序再free -h看内存和 swapvmstat 1看 r 和 b 列r 是运行队列b 是不可中断睡眠的进程数最后iostat -x 1看 %util 和 await判断是不是磁盘慢拖累了整体。这几个命令的顺序就是面试答案的骨架。负载高不等于 CPU 高可能卡在 IO 等待内存不足也不一定立刻 OOM可能先触发 swap 抖动。dmesg和/var/log/messages要配合看OOM killer 的日志在这里最明显。曾经有候选人回答负载高就 kill 进程这个思路要纠正先定位是 CPU、内存、磁盘还是应用层问题kill 是最后手段。虚拟内存也别漏。top里 VIRT 和 RES 的区别面试官喜欢追问。VIRT 是进程申请的虚拟地址空间总量RES 是实际驻留在物理内存的部分两个值差距大说明程序申请了很多但没全用。再往下问就是 swap 的 swappiness 参数sysctl vm.swappiness默认 60数据库服务器一般调低到 10 左右避免 Linux 把不常用的内存页换出导致抖动。2.3 Shell 脚本手写变量、引号和 set -e运维面试基本躲不开手写 Shell。常见题目是写一个脚本检测某端口是否监听没有就重启服务并记录日志。这道题的考点不在 if 语法而在两个细节一是怎么优雅地取端口状态二是脚本的健壮性。#!/bin/bash PORT8080 if ss -tln | grep -q :${PORT} ; then echo $(date %F %T) port ok /var/log/port_check.log else echo $(date %F %T) port down, restart /var/log/port_check.log systemctl restart demo-service figrep -q只判断是否匹配不输出内容退出码直接给 if 用。注意 grep 的匹配串写成:${PORT} 带一个空格是为了避免:8080匹配到:80801这种子串。脚本里$(date %F %T)是命令替换双引号把变量和命令替换的结果拼进字符串日志里会有完整时间。systemctl restart之后最好再加一句sleep 2和二次检查不然端口还没起来就进入下一轮判断。面试官常在这道题上加难度要求脚本可以被 crontab 调用且失败时能让人知道。这就要提两个经典坑。第一个是环境变量crontab 里 PATH 往往只有/usr/bin:/bin脚本里用到 ss 或 systemctl 如果不在这个路径里就静默失败解决办法是脚本开头export PATH/usr/local/bin:/usr/bin:/bin或者用绝对路径。第二个是set -e很多候选人知道set -e能让脚本在出错时退出但没意识到在管道里它的行为不一样默认管道的退出码只看最后一个命令前面命令失败不会触发退出。要整条管道严格失败退出需要加set -o pipefail。Shell 面试里还有几个高频追问$和$*的区别$?是上一条命令的退出码$$是当前进程 PID。$把参数当作多个独立的词$*把所有参数拼成一个词在 for 循环里必须用$否则带空格的参数会被拆散或粘连。另一个常考的是双引号里变量会展开、单引号里不展开systemctl restart demo-service在脚本里写成systemctl restart demo-service就变成字符串不会执行。写脚本时养成好习惯统一用双引号包变量局部变量用 local临时文件用trap rm -f /tmp/xxx EXIT做收尾。这些细节在面试里都算加分项。3. Python 与 MySQL自动化是加分项数据层是必考题Python 在运维里不承担业务开发它的定位是把重复操作固化成脚本MySQL 则是数据层的必考题备份、索引、主从三件套跑不掉。这一章我先讲 Python 面试中真正会被问到的东西再进入 MySQL 的核心考点。3.1 Python 手写题的三个高频方向运维岗的 Python 题目不会太难一般在三五十行内。第一个高频方向是读文件做统计比如统计 Nginx 日志里状态码分布或者统计错误日志中某个异常出现的次数。第二个方向是批量操作比如用os.walk遍历目录找超过 500MB 的文件第三个方向是调用 API 或执行远程命令用 requests 或 subprocess。面试官看重的是异常处理和资源释放不是算法。import os def find_big_files(root, size_limit500 * 1024 * 1024): result [] for dirpath, _, filenames in os.walk(root): for name in filenames: path os.path.join(dirpath, name) try: size os.path.getsize(path) except OSError: continue if size size_limit: result.append((path, size)) return result if __name__ __main__: for path, size in find_big_files(/data): print(f{path} - {size / 1024 / 1024:.1f} MB)os.walk返回三元组分别是从根开始的目录路径、子目录列表和文件列表。这里对getsize包了try/except OSError因为文件可能在遍历过程中被删除不处理会整段报错。f{path} - {size / 1024 / 1024:.1f} MB是 f-string.1f保留一位小数。main 段用if __name__ __main__包裹这是 Python 面试里很看重的习惯脚本被 import 时不会执行主逻辑。多线程是 Python 面试躲不开的题目。Python 多线程能提升计算密集型任务的性能吗这个问题很多人答错。因为 GIL计算密集型的多线程在同一时刻只跑一个线程提升有限IO 密集场景多线程才有明显收益因为等待 IO 时锁可以释放给其他线程。运维脚本多数是 IO 密集的比如批量 SSH 或下载文件所以用ThreadPoolExecutor是合理的。如果要追求计算性能用多进程ProcessPoolExecutor。from concurrent.futures import ThreadPoolExecutor import subprocess hosts [10.0.0.1, 10.0.0.2, 10.0.0.3] def ping_host(host): result subprocess.run( [ping, -c, 1, -W, 2, host], capture_outputTrue, textTrue, ) return host, result.returncode 0 with ThreadPoolExecutor(max_workers10) as pool: for host, ok in pool.map(ping_host, hosts): print(f{host} - {up if ok else down})subprocess.run的capture_outputTrue把 stdout 和 stderr 收进结果对象textTrue让输出以字符串返回不加的话返回的是 bytes。-W 2表示 ping 的超时时间是 2 秒批量检测时不给超时会把整个脚本拖垮。ThreadPoolExecutor的max_workers10控制并发数不是越大越好太大会把目标服务器的会话占满。pool.map可以按输入顺序拿结果比as_completed更直观。3.2 MySQL 索引优化explain 和联合索引的面试套路MySQL 的第一道必考题是索引。面试官一般会给你一条慢 SQL问你怎么优化。先确认表结构再看EXPLAIN核心关注 type、key、rows 三列。type 从好到差常见顺序是 system、const、eq_ref、ref、range、index、ALL看到 ALL 基本就是全表扫描。key是实际用到的索引如果possible_keys有值但key是空说明优化器认为全表扫描更快这时要看是不是统计信息没更新ANALYZE TABLE可以刷一下。联合索引是高频追问点。比如(a, b, c)建一个联合索引哪些查询能命中答案是走最左前缀原则a、a,b、a,b,c 都能走b 或 c 单独查走不了。这个规则的物理原因是 B 树的索引节点先按 a 排、a 相同再按 b 排、再按 c 排跳过最左列的查询无法用索引的有序性。还有一个容易忽略的点select * from t where a 1 order by b在联合索引下连排序都省了因为 b 已经有序where a 1 group by b同理。覆盖索引也是个加分概念。如果查询列都在索引里EXPLAIN的 Extra 字段会显示Using index意味着不回表就能拿到数据。比如(a, b)联合索引能覆盖select a, b from t where a 1。面试官问为什么说不要随意 select *除了数据传输量另一个原因是它破坏覆盖索引本来索引覆盖能省一次回表一select *就变成回表了。SQL 优化题还有几个常见场景where date(create_time) 2024-01-01会让索引失效因为列上套了函数where name like %abc%无法走索引但abc%可以隐式类型转换也会失效比如where phone 138xxxxphone 是 varchar 但查询条件用数字MySQL 会把列转成数字再比较索引就废了。这些例子面试出现频率极高最好能顺手讲出原因索引本身是排序结构函数或类型转换破坏了列值与索引键的直接对应关系。3.3 MySQL 备份与主从三个参数和一个排查命令备份是生产环境的基本功。mysqldump 的全量备份命令我一般这样写mysqldump --single-transaction --master-data2 -u backup_user -p --databases demo_db demo_db.sql--single-transaction对 InnoDB 有效它在事务内做一致性快照不加锁不阻塞写这是在线备份的关键。--master-data2会把 binlog 文件名和位置写入备份文件的注释里做增量恢复时要靠这个定位起点。-p后面不直接跟密码否则密码会出现在 history 里交互式输入或从配置文件读更安全。备份文件是文本 SQL恢复时mysql -u root -p demo_db.sql即可。MySQL 8 里 mysqldump 还存在但官方也推荐备用方案 mysqlpump 或物理备份工具后者更适合大数据量场景。面试被问到数据量几十 G 怎么备份时mysqldump 就不够看了需要讲物理备份或者基于 binlog 的增量备份体系。这里重要的不是具体工具而是思路全量加增量定期做恢复演练。主从复制的面试题集中在两个命令上SHOW MASTER STATUS和SHOW REPLICA STATUS。排查延迟时先看Seconds_Behind_Master这个值是 0 不代表没有隐患还要看Replica_IO_Running和Replica_SQL_Running是不是都显示Yes。IO 线程负责从主库拉 binlogSQL 线程负责回放IO 线程断了会显示ConnectingSQL 线程断了常见原因是回放出错。一个经典坑主库大事务跑很久从库落后Seconds_Behind_Master显示延迟但其实约等于主库执行事务的时间等主库提交完从库追起来可能很快。别一看到延迟就紧张。binlog 的三种格式也可以准备一下。STATEMENT记录 SQL 语句日志小但像NOW()这种非确定性函数在从库回放会不一致ROW记录每行变更最准确日志量大MIXED让 MySQL 自己判断。生产库现在基本默认ROW因为误操作恢复时 ROW 格式能定位到具体行变化。4. Docker 与 K8s容器面试不是背命令是讲原理Docker 和 K8s 在面试里的地位已经从加分项变成必考项。这一章按镜像与容器、K8s 核心对象、网络与调度、排障路径展开重点放在面试官爱追问的原理层。4.1 镜像分层、CMD 与 ENTRYPOINT 的区分Docker 面试第一个高频题是镜像为什么能秒级拉取增量。答案是分层存储镜像由只读层叠加每次构建产生新层相同层可以复用。docker history能看到每一层的操作和大小。运行容器时在上层加一个可写层删除文件不是真的删除而是用 whiteout 文件掩盖。这个机制解释了为什么容器内删除大文件不会减小镜像大小。CMD和ENTRYPOINT的区别是现场必考题。简单记ENTRYPOINT 是固定的启动程序CMD 是默认参数。docker run后面跟的命令可以覆盖 CMD但覆盖不了 ENTRYPOINT除非加--entrypoint。常见组合是 ENTRYPOINT 写启动脚本CMD 写默认参数。一个相关考点是docker run和docker exec的区别前者创建新容器后者进入已有容器执行命令exec 进去开 shell 不会重启主进程。Dockerfile 的细节也常被考。RUN是构建时执行CMD是运行时执行COPY和ADD的区别是 ADD 能自动解压本地 tar 并支持 URL但官方建议能用 COPY 就用 COPY因为 ADD 的行为容易让人意外。多阶段构建是高级一点的话题第一个阶段用带编译器的镜像编译二进制第二阶段只拷贝产物和运行库镜像体积能小一个量级。FROM golang:1.21 AS builder WORKDIR /app COPY . . RUN CGO_ENABLED0 go build -o app . FROM alpine:3.19 RUN apk add --no-cache ca-certificates COPY --frombuilder /app/app /usr/local/bin/app EXPOSE 8080 ENTRYPOINT [app]这个 Dockerfile 的两阶段结构要能解释第一阶段 golang 镜像里有完整工具链编译产物打进/app/app第二阶段只拿编译好的二进制和证书alpine 系统库精简所以镜像小。CGO_ENABLED0是为了让 Go 程序静态编译不依赖动态库拷贝到 alpine 里能直接跑。EXPOSE 8080只是声明容器监听的端口不实际发布端口发布是-p的职责。ENTRYPOINT用 JSON 数组格式这是 exec 形式进程是 PID 1信号能正确传进去写成ENTRYPOINT app是 shell 形式会用/bin/sh -c包一层进程不是 PID 1docker stop时的 SIGTERM 可能传不到应用这是容器停不掉的一类原因。4.2 K8s 核心对象的面试逻辑Pod、Deployment、ServiceK8s 面试有个常见误区背一堆资源名词但说不清关系。核心是这条链Pod 是最小运行单元里面可以有一个或多个容器共享网络命名空间和存储卷Deployment 管理一组 Pod 副本负责滚动更新和回滚Service 是访问入口把流量负载均衡到一组 Pod。面试官问为什么有 Pod 还要有容器这个层级因为一个 Pod 里的容器要共享网络和存储比如日志 sidecar 容器挂同一个卷Deployment 又不是直接管容器因为 Pod 会重建、IP 会变需要有个稳定的抽象来管理副本。Deployment 的滚动更新是高频场景题。kubectl set image deployment/demo demonginx:1.25触发滚动更新默认maxUnavailable是 25%maxSurge是 25%意思是更新时最多允许多一个临时 Pod最少保证 75% 的副本可用。面试追问更新到一半发现新版本有问题怎么办回答是kubectl rollout undo deployment/demoK8s 会按更新前的 ReplicaSet 重建 Pod。这个机制的底层是 ReplicaSet每次更新生成新的 ReplicaSet旧的保留回滚就是切回旧的 ReplicaSet 并把副本数调整到目标值。探针是排障和面试都绕不开的知识点。三种探针各自负责什么要能答清livenessProbe失败会重启容器readinessProbe失败会把 Pod 从 Service 的 endpoints 里摘掉但容器不重启startupProbe给启动慢的应用用防止启动过程中被 readiness 杀掉。配置探针时有两个关键参数initialDelaySeconds是容器启动后等多久才开始探测periodSeconds是探测周期。启动快的应用 initialDelay 设 5 到 10 秒足够Java 应用就要看启动时间可能直接给 60 秒。apiVersion: apps/v1 kind: Deployment metadata: name: demo-web spec: replicas: 3 selector: matchLabels: app: demo-web template: metadata: labels: app: demo-web spec: containers: - name: web image: nginx:1.25 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi readinessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: tcpSocket: port: 80 initialDelaySeconds: 15 periodSeconds: 20这段 YAML 的考点集中在 resources 和 probe 上。requests 是调度依据limits 是运行上限只设 limits 不设 requests 容易出问题调度器不知道实际需要多少资源可能把 Pod 塞到一台已经过载的节点。CPU 的100m是 0.1 核CPU limit 超了会被限流内存 limit 超了会直接 OOMKilled这两者的差异也是面试爱问的。Pod 进入CrashLoopBackOff时第一步不是杀 Pod而是kubectl describe pod看 Events再kubectl logs看应用输出。describe 里State: Waiting后面跟的 Reason 是CrashLoopBackOff还是CreateContainerError定位方向完全不同。4.3 集群网络与调度的两道典型题kubectl get nodes显示NotReady这是面试里常见的排障场景题。排查顺序应该是先kubectl describe node看节点上的条件再检查 Kubelet 服务状态systemctl status kubelet接着看 kubelet 日志最后确认 CNI 插件是否正常。很多 NotReady 的原因是 CNI 没配好节点状态就一直起不来。这个例子说明 K8s 排障不是靠感觉是按照控制面、节点服务、容器网络三层往下剥。调度的另一道题是Pod 一直 Pending 怎么办。Pending 的原因最常见是资源不够、节点有污点、PVC 没绑定。kubectl describe pod的 Events 会写明0/3 nodes are available和具体不满足的条件。这里要能答出污点和容忍的关系kubectl taint nodes node1 keyvalue:NoSchedule给节点打污点只有 Pod 上有对应 toleration 才能调度上去。这个机制面试官常用来问怎么让一个节点只跑某个服务答加 taint 再给目标 Pod 加 toleration 就够了。5. 面试避坑与网络排查五个高频翻车点网络是运维面试里看起来简单但翻车率最高的一块也是七条线里最容易被忽略的。这一章把网络考点和面试翻车点合在一起讲每条都按现象、原因、解决来写希望能帮你面试前少踩几个坑。5.1 网络面试题的五个高频考点网络考点集中在四个层级。第一是 TCP 三次握手和四次挥手几乎必考要能画出来、能讲清楚状态迁移。第二是 DNS 解析过程从本地缓存到 hosts 到 DNS 服务器递归查询。第三是 HTTP 和 TCP 的关系以及 HTTPS 握手这里经常和 Nginx 配置连起来问。第四是负载均衡的常见实现LVS、Nginx、HAProxy 的区别。ping、telnet、curl、nc 各自验证什么也要分清楚ping 验证 ICMP 通不通telnet 和 nc 验证 TCP 端口通不通curl 验证 HTTP 应用层通不通。如果服务器上 curl 正常但 ping 不通不要慌。ICMP 和 TCP 是两套协议很多云环境的安全组和防火墙默认禁 ICMP但业务流量正常。面试时能主动说出先确认是测 ICMP 还是 TCP 连通性比背一堆命令显得有条理。反过来 telnet 通但 curl 超时就要往应用层走看 Nginx 配置、后端超时、DNS 解析结果。K8s 里的网络还可以往下追问一层Service 的 ClusterIP 怎么实现负载均衡。答案核心是 kube-proxy它维护一组 iptables 或 ipvs 规则把访问 ClusterIP 的流量转发到后端的 Pod IP。ipvs 模式和 iptables 模式的区别也常被考iptables 是链式匹配规则多时性能下降ipvs 在内核态做哈希查找规则多时更稳定。现在多数集群默认用 ipvs 或 IPVS 模式的 kube-proxy这个点能答上来会显得有实战积累。5.2 坑一把 TCP 三次挥手背成三次握手现象候选人 TCP 状态迁移背得滚瓜烂熟但被问为什么建连是三次断连是四次直接语塞。原因只背了流程没理解报文里的语义。解决用互相对齐来理解——建连阶段SYN 表示我要发起连接ACK 确认对方的 SYN因为双方要互相确认收发能力都正常所以需要三次才能让两边都确认。断连阶段主动方 FIN 表示我没有数据要发了被动方可能还有数据没发完所以先 ACK再等数据发完才回 FIN一来一回就多了一次。能讲出被动方收到 FIN 后还可以继续发数据这层面试官基本就不会再追问。顺带记住 TIME_WAIT 属于主动断开方等待时间默认 60 秒作用是让迟到的报文在网络中自然消失避免污染新连接。5.3 坑二ping 不通就断定网络不通现象给一个从某台机器访问内部服务超时的现场题上来就 pingping 不通就说网络断了。原因没有先区分 ICMP 与业务端口。解决标准路径是先 ping 网关确认三层通再telnet 目标IP 目标端口或nc -zv 目标IP 端口确认四层通再curl -v http://目标地址确认七层通。哪一层先失败故障范围就缩到哪一层往上。比如 ping 网关通、telnet 目标端口不通问题大概率在目标主机的防火墙或服务本身而不是链路。这个排查思路比命令本身值钱答的时候按层次讲面试官会觉得你有章法。5.4 坑三K8s 里看到 Pod 重启就只查容器日志现象kubectl get pods看到CrashLoopBackOff直接kubectl logs日志里什么都没有于是不知道怎么查。原因没意识到容器日志和应用启动是两个层面容器可能根本没起来。解决先kubectl describe pod name看 Events 和容器状态State: Waiting的 Reason 字段是关键。如果 Reason 是CreateContainerError看kubectl logs --previous和容器上一次的退出码如果退出码是 137说明被 SIGKILL 杀掉优先查内存 limit 和 OOMKilled 事件退出码 1 通常是应用自身异常退出才去看业务日志。这条经验来自不止一次的翻车现场先 describe 再看 logs 的顺序能省下大把时间。5.5 坑四主从延迟就狂调网络参数现象MySQL 主从Seconds_Behind_Master很大候选人怀疑是机房网络抖动想调 TCP 参数。原因主从延迟最常见的原因是主库有大事务或从库回放赶不上网络短板反而是少见情况。解决先看SHOW REPLICA STATUS里的Replica_IO_Running和Replica_SQL_Running再判断是 IO 线程拉取慢还是 SQL 线程回放慢。SQL 线程慢的典型场景是主库一条 UPDATE 改了全表几百万行binlog 在从库要一条条回放等主库事务结束从库开始追赶延迟峰值通常能对齐主库大事务的执行时间。更稳妥的架构是开启半同步复制主库提交前等从库确认收到 binlog能显著降低数据丢失概率也会让延迟问题暴露得更早。先看状态命令再定位原因别一开始就动系统参数。5.6 坑五Shell 脚本本地正常crontab 里没输出现象脚本手动执行没问题加到 crontab 后既不报错也没效果。原因crontab 环境变量和交互式 shell 不同PATH 不完整脚本里用到的命令没找到静默失败。解决脚本开头加export PATH/usr/local/bin:/usr/bin:/bin或者所有外部命令写绝对路径调试时把 crontab 执行的输出重定向到日志文件*/5 * * * * /opt/scripts/demo.sh /tmp/demo.log 21。还有一层要注意crontab 默认用的 shell 是/bin/sh如果脚本里有 Bash 语法比如数组首行必须写成#!/bin/bash。遇到没输出的题先查这两处命中率最高。排查这类问题还可以在脚本开头临时加set -x把每一行命令的展开结果打到日志里比盲猜快得多。6. 模拟面试自检七条线怎么算过关准备面试最有效的方法不是背题是按面试官的追问链做自检。我的习惯是把七个方向各拆成一条命令、一个原理、一个场景题。命令关Linux 的ss -tlnp、Shell 的grep -E、Python 的subprocess.run、MySQL 的EXPLAIN参数、Docker 的docker inspect、K8s 的kubectl describe pod、网络的nc -zv每条都要能现场敲出来并解释参数。原理关联合索引的最左前缀、镜像分层与可写层、Pod 与容器的层级关系、TCP 三次建连和四次断连、容器 PID 1 与信号处理。场景题负载高排查、Pod 一直 Pending、主从延迟、端口不通。任选一个能边说边敲命令这关就算过了。这里给你一个可以直接用的自检法拿一台测试机清空一个临时目录把以下动作连续做一遍——写一个 Shell 脚本检查 8080 端口写一个 Python 脚本统计日志文件的行数和错误数用 docker run 起一个 nginx 并映射端口用 kubectl run 跑一个调试 Pod 再kubectl logs。能在一小时内不查资料完成面试里的手写题基本稳了。时间卡不住的话重新看前面章节里代码块的注释重点补不熟的那一段。我自己准备面试时吃过一次亏把 Deployment 的滚动更新参数背得很熟却忽略了kubectl rollout history和undo的实际验证结果模拟面试时一敲命令就露怯。从此之后凡是考点都先在测试环境跑一遍才算过。面试题不需要刷几百道但每道高频题都要能讲出原理、说出命令、复现结果。希望这篇笔记能帮你把七条线串成一张网面试时不是背答案而是像平时干活一样把问题讲清楚。祝顺利。本文还有配套的精品资源点击获取
简介面向运维工程师岗位面试的一套 PDF 题库聚焦 Linux、Shell、Python、MySQL、Docker、K8s 与网络七大技术方向适合正在系统准备运维/DevOps 面试的求职者快速查漏补缺。资源仅包含 1 个 PDF 文件大小约 890KB内容按技术模块分层展开题量大且覆盖广Linux 部分涵盖进程查看与统计、nginx 进程数统计、du/df 磁盘排查、find 检索及日志分析Shell 部分包含内置变量含义、批量创建用户、IP 在线检测、URL 可用性检查等实操脚本Python 部分涉及数据类型与特性、深浅拷贝、常用内置函数、常见模块、生成器与迭代器并附带九九乘法表实现MySQL 部分梳理了 delete/drop/truncate 区别、varchar 与 char 差异、主从复制原理与延迟原因、事务隔离级别、优化及备份策略Docker 与 Kubernetes 部分则从镜像容器概念、常用命令、Dockerfile 指令延伸到 K8s 核心组件、etcd 作用、Deployment/Statefulset/Daemonset 控制器、Pod 健康监测与数据持久化方式网络模块覆盖 OSI 七层模型、TCP/UDP 场景与端口、三次握手四次挥手、HTTP 状态码与请求方法并附带 Linux 系统优化实际案例。目前已有 674 人学习适合作为面试前的高密度速览与知识框架梳理资料。1. 运维工程师面试题七条线背后的真实考点运维工程师面试题这个词拆开看就是 Linux、Shell、Python、MySQL、Docker、K8s、网络七条线。Linux 是底座Shell 和 Python 是自动化操作的两只手MySQL 是数据层Docker 和 K8s 是交付形态网络则是贯穿一切的那根线。我面试过不少候选人发现准备面试的人最容易犯两个错一是只刷题不追底层命令会敲但说不出原理二是只背概念不写代码一让手写脚本就卡壳。这篇笔记不列题库而是按面试官追问的习惯把七条线拆成命令怎么用、原理怎么答、现场怎么写、哪里会翻车四个角度覆盖初级到高级的常见考点。适合准备跳槽的运维、转岗开发的测试以及想系统查漏补缺的 SRE。2. Linux 与 Shell先过命令关再过脚本关运维面试的第一关几乎都是 Linux。面试官不太会问 ls 怎么用而是让你现场排查、亲手写命令。这一章按我的习惯分成三块高频命令的精确语义、系统排查的标准路径、Shell 脚本的手写与改错。2.1 高频命令的精确语义df、du、ss、lsof命令人人会敲但面试追问点恰恰藏在最常用的命令里。比如df -h和du -sh的区别很多人答df 看磁盘du 看目录这不算错但面试官真正想听的是df 读的是文件系统超级块里的统计du 是遍历目录树累加文件块所以 df 显示的是已分配空间du 统计的是实际占用。文件被进程删除但未释放时df 看到空间没减少du 却可能已经变小。这才是排查磁盘满但找不到大文件的钥匙。再比如端口排查。netstat -tunlp是老命令现在面试更常问ss因为 ss 直接读内核 socket 哈希表量大时不卡。查端口监听用ss -tlnp查连接状态用ss -tan。如果想知道某个进程打开了哪些文件用lsof -p PID或者用lsof -i :8080看谁占着 8080 端口。这里有个常见追问ss -tlnp里的l是 listeningn是数字显示不做反向解析p是显示进程名。解释了这三个参数才算把这题答完整。文件查找也常被考。find /data -name *.log -mtime 7 -type f -exec rm {} \;这类命令要能一眼说清每个段的作用-name按名字匹配-mtime 7表示修改时间在 7 天前-type f限定普通文件-exec把结果交给 rm。但我会建议候选人用-delete替代-exec rm {} \;写法更短特殊文件名也不会触发参数解析问题代价是少了确认过程。批量操作时用find ... | xargs -n 50能控制每次处理的参数个数避免出现Argument list too long。文本处理三件套 awk、sed、grep 是必考。grep 的关键参数是-E用扩展正则、-v反选、-c计数、-l只列文件名。sed 常被问-i做原地修改s/old/new/g的尾巴g不加的话每行只替换第一处。awk 的核心是{print $1}按空格分列-F改分隔符NR1处理第一行。面试里最常见的一道题是找出日志里访问量最大的 10 个 IP命令如下。awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这条命令的链路是awk 取第一列默认按空白分列sort 把相同 IP 归到一起uniq -c 统计重复次数并输出次数 IPsort -rn 按数字逆向排序head -10 取前十条。考官通常会追问一个变体如果日志格式是IP [时间] GET /url 200第一列还是 IP 吗这是提醒你别背命令要理解字段位置。2.2 系统排查的标准路径从 load average 到 io wait服务器负载高是面试里的开放题考察的是排查路径是否成体系。我一般会按这个顺序走先uptime看 load average 三个数判断负载是持续高还是瞬时冲高然后top看 CPU 占用和进程排序按P键按 CPU 排序、按M键按内存排序再free -h看内存和 swapvmstat 1看 r 和 b 列r 是运行队列b 是不可中断睡眠的进程数最后iostat -x 1看 %util 和 await判断是不是磁盘慢拖累了整体。这几个命令的顺序就是面试答案的骨架。负载高不等于 CPU 高可能卡在 IO 等待内存不足也不一定立刻 OOM可能先触发 swap 抖动。dmesg和/var/log/messages要配合看OOM killer 的日志在这里最明显。曾经有候选人回答负载高就 kill 进程这个思路要纠正先定位是 CPU、内存、磁盘还是应用层问题kill 是最后手段。虚拟内存也别漏。top里 VIRT 和 RES 的区别面试官喜欢追问。VIRT 是进程申请的虚拟地址空间总量RES 是实际驻留在物理内存的部分两个值差距大说明程序申请了很多但没全用。再往下问就是 swap 的 swappiness 参数sysctl vm.swappiness默认 60数据库服务器一般调低到 10 左右避免 Linux 把不常用的内存页换出导致抖动。2.3 Shell 脚本手写变量、引号和 set -e运维面试基本躲不开手写 Shell。常见题目是写一个脚本检测某端口是否监听没有就重启服务并记录日志。这道题的考点不在 if 语法而在两个细节一是怎么优雅地取端口状态二是脚本的健壮性。#!/bin/bash PORT8080 if ss -tln | grep -q :${PORT} ; then echo $(date %F %T) port ok /var/log/port_check.log else echo $(date %F %T) port down, restart /var/log/port_check.log systemctl restart demo-service figrep -q只判断是否匹配不输出内容退出码直接给 if 用。注意 grep 的匹配串写成:${PORT} 带一个空格是为了避免:8080匹配到:80801这种子串。脚本里$(date %F %T)是命令替换双引号把变量和命令替换的结果拼进字符串日志里会有完整时间。systemctl restart之后最好再加一句sleep 2和二次检查不然端口还没起来就进入下一轮判断。面试官常在这道题上加难度要求脚本可以被 crontab 调用且失败时能让人知道。这就要提两个经典坑。第一个是环境变量crontab 里 PATH 往往只有/usr/bin:/bin脚本里用到 ss 或 systemctl 如果不在这个路径里就静默失败解决办法是脚本开头export PATH/usr/local/bin:/usr/bin:/bin或者用绝对路径。第二个是set -e很多候选人知道set -e能让脚本在出错时退出但没意识到在管道里它的行为不一样默认管道的退出码只看最后一个命令前面命令失败不会触发退出。要整条管道严格失败退出需要加set -o pipefail。Shell 面试里还有几个高频追问$和$*的区别$?是上一条命令的退出码$$是当前进程 PID。$把参数当作多个独立的词$*把所有参数拼成一个词在 for 循环里必须用$否则带空格的参数会被拆散或粘连。另一个常考的是双引号里变量会展开、单引号里不展开systemctl restart demo-service在脚本里写成systemctl restart demo-service就变成字符串不会执行。写脚本时养成好习惯统一用双引号包变量局部变量用 local临时文件用trap rm -f /tmp/xxx EXIT做收尾。这些细节在面试里都算加分项。3. Python 与 MySQL自动化是加分项数据层是必考题Python 在运维里不承担业务开发它的定位是把重复操作固化成脚本MySQL 则是数据层的必考题备份、索引、主从三件套跑不掉。这一章我先讲 Python 面试中真正会被问到的东西再进入 MySQL 的核心考点。3.1 Python 手写题的三个高频方向运维岗的 Python 题目不会太难一般在三五十行内。第一个高频方向是读文件做统计比如统计 Nginx 日志里状态码分布或者统计错误日志中某个异常出现的次数。第二个方向是批量操作比如用os.walk遍历目录找超过 500MB 的文件第三个方向是调用 API 或执行远程命令用 requests 或 subprocess。面试官看重的是异常处理和资源释放不是算法。import os def find_big_files(root, size_limit500 * 1024 * 1024): result [] for dirpath, _, filenames in os.walk(root): for name in filenames: path os.path.join(dirpath, name) try: size os.path.getsize(path) except OSError: continue if size size_limit: result.append((path, size)) return result if __name__ __main__: for path, size in find_big_files(/data): print(f{path} - {size / 1024 / 1024:.1f} MB)os.walk返回三元组分别是从根开始的目录路径、子目录列表和文件列表。这里对getsize包了try/except OSError因为文件可能在遍历过程中被删除不处理会整段报错。f{path} - {size / 1024 / 1024:.1f} MB是 f-string.1f保留一位小数。main 段用if __name__ __main__包裹这是 Python 面试里很看重的习惯脚本被 import 时不会执行主逻辑。多线程是 Python 面试躲不开的题目。Python 多线程能提升计算密集型任务的性能吗这个问题很多人答错。因为 GIL计算密集型的多线程在同一时刻只跑一个线程提升有限IO 密集场景多线程才有明显收益因为等待 IO 时锁可以释放给其他线程。运维脚本多数是 IO 密集的比如批量 SSH 或下载文件所以用ThreadPoolExecutor是合理的。如果要追求计算性能用多进程ProcessPoolExecutor。from concurrent.futures import ThreadPoolExecutor import subprocess hosts [10.0.0.1, 10.0.0.2, 10.0.0.3] def ping_host(host): result subprocess.run( [ping, -c, 1, -W, 2, host], capture_outputTrue, textTrue, ) return host, result.returncode 0 with ThreadPoolExecutor(max_workers10) as pool: for host, ok in pool.map(ping_host, hosts): print(f{host} - {up if ok else down})subprocess.run的capture_outputTrue把 stdout 和 stderr 收进结果对象textTrue让输出以字符串返回不加的话返回的是 bytes。-W 2表示 ping 的超时时间是 2 秒批量检测时不给超时会把整个脚本拖垮。ThreadPoolExecutor的max_workers10控制并发数不是越大越好太大会把目标服务器的会话占满。pool.map可以按输入顺序拿结果比as_completed更直观。3.2 MySQL 索引优化explain 和联合索引的面试套路MySQL 的第一道必考题是索引。面试官一般会给你一条慢 SQL问你怎么优化。先确认表结构再看EXPLAIN核心关注 type、key、rows 三列。type 从好到差常见顺序是 system、const、eq_ref、ref、range、index、ALL看到 ALL 基本就是全表扫描。key是实际用到的索引如果possible_keys有值但key是空说明优化器认为全表扫描更快这时要看是不是统计信息没更新ANALYZE TABLE可以刷一下。联合索引是高频追问点。比如(a, b, c)建一个联合索引哪些查询能命中答案是走最左前缀原则a、a,b、a,b,c 都能走b 或 c 单独查走不了。这个规则的物理原因是 B 树的索引节点先按 a 排、a 相同再按 b 排、再按 c 排跳过最左列的查询无法用索引的有序性。还有一个容易忽略的点select * from t where a 1 order by b在联合索引下连排序都省了因为 b 已经有序where a 1 group by b同理。覆盖索引也是个加分概念。如果查询列都在索引里EXPLAIN的 Extra 字段会显示Using index意味着不回表就能拿到数据。比如(a, b)联合索引能覆盖select a, b from t where a 1。面试官问为什么说不要随意 select *除了数据传输量另一个原因是它破坏覆盖索引本来索引覆盖能省一次回表一select *就变成回表了。SQL 优化题还有几个常见场景where date(create_time) 2024-01-01会让索引失效因为列上套了函数where name like %abc%无法走索引但abc%可以隐式类型转换也会失效比如where phone 138xxxxphone 是 varchar 但查询条件用数字MySQL 会把列转成数字再比较索引就废了。这些例子面试出现频率极高最好能顺手讲出原因索引本身是排序结构函数或类型转换破坏了列值与索引键的直接对应关系。3.3 MySQL 备份与主从三个参数和一个排查命令备份是生产环境的基本功。mysqldump 的全量备份命令我一般这样写mysqldump --single-transaction --master-data2 -u backup_user -p --databases demo_db demo_db.sql--single-transaction对 InnoDB 有效它在事务内做一致性快照不加锁不阻塞写这是在线备份的关键。--master-data2会把 binlog 文件名和位置写入备份文件的注释里做增量恢复时要靠这个定位起点。-p后面不直接跟密码否则密码会出现在 history 里交互式输入或从配置文件读更安全。备份文件是文本 SQL恢复时mysql -u root -p demo_db.sql即可。MySQL 8 里 mysqldump 还存在但官方也推荐备用方案 mysqlpump 或物理备份工具后者更适合大数据量场景。面试被问到数据量几十 G 怎么备份时mysqldump 就不够看了需要讲物理备份或者基于 binlog 的增量备份体系。这里重要的不是具体工具而是思路全量加增量定期做恢复演练。主从复制的面试题集中在两个命令上SHOW MASTER STATUS和SHOW REPLICA STATUS。排查延迟时先看Seconds_Behind_Master这个值是 0 不代表没有隐患还要看Replica_IO_Running和Replica_SQL_Running是不是都显示Yes。IO 线程负责从主库拉 binlogSQL 线程负责回放IO 线程断了会显示ConnectingSQL 线程断了常见原因是回放出错。一个经典坑主库大事务跑很久从库落后Seconds_Behind_Master显示延迟但其实约等于主库执行事务的时间等主库提交完从库追起来可能很快。别一看到延迟就紧张。binlog 的三种格式也可以准备一下。STATEMENT记录 SQL 语句日志小但像NOW()这种非确定性函数在从库回放会不一致ROW记录每行变更最准确日志量大MIXED让 MySQL 自己判断。生产库现在基本默认ROW因为误操作恢复时 ROW 格式能定位到具体行变化。4. Docker 与 K8s容器面试不是背命令是讲原理Docker 和 K8s 在面试里的地位已经从加分项变成必考项。这一章按镜像与容器、K8s 核心对象、网络与调度、排障路径展开重点放在面试官爱追问的原理层。4.1 镜像分层、CMD 与 ENTRYPOINT 的区分Docker 面试第一个高频题是镜像为什么能秒级拉取增量。答案是分层存储镜像由只读层叠加每次构建产生新层相同层可以复用。docker history能看到每一层的操作和大小。运行容器时在上层加一个可写层删除文件不是真的删除而是用 whiteout 文件掩盖。这个机制解释了为什么容器内删除大文件不会减小镜像大小。CMD和ENTRYPOINT的区别是现场必考题。简单记ENTRYPOINT 是固定的启动程序CMD 是默认参数。docker run后面跟的命令可以覆盖 CMD但覆盖不了 ENTRYPOINT除非加--entrypoint。常见组合是 ENTRYPOINT 写启动脚本CMD 写默认参数。一个相关考点是docker run和docker exec的区别前者创建新容器后者进入已有容器执行命令exec 进去开 shell 不会重启主进程。Dockerfile 的细节也常被考。RUN是构建时执行CMD是运行时执行COPY和ADD的区别是 ADD 能自动解压本地 tar 并支持 URL但官方建议能用 COPY 就用 COPY因为 ADD 的行为容易让人意外。多阶段构建是高级一点的话题第一个阶段用带编译器的镜像编译二进制第二阶段只拷贝产物和运行库镜像体积能小一个量级。FROM golang:1.21 AS builder WORKDIR /app COPY . . RUN CGO_ENABLED0 go build -o app . FROM alpine:3.19 RUN apk add --no-cache ca-certificates COPY --frombuilder /app/app /usr/local/bin/app EXPOSE 8080 ENTRYPOINT [app]这个 Dockerfile 的两阶段结构要能解释第一阶段 golang 镜像里有完整工具链编译产物打进/app/app第二阶段只拿编译好的二进制和证书alpine 系统库精简所以镜像小。CGO_ENABLED0是为了让 Go 程序静态编译不依赖动态库拷贝到 alpine 里能直接跑。EXPOSE 8080只是声明容器监听的端口不实际发布端口发布是-p的职责。ENTRYPOINT用 JSON 数组格式这是 exec 形式进程是 PID 1信号能正确传进去写成ENTRYPOINT app是 shell 形式会用/bin/sh -c包一层进程不是 PID 1docker stop时的 SIGTERM 可能传不到应用这是容器停不掉的一类原因。4.2 K8s 核心对象的面试逻辑Pod、Deployment、ServiceK8s 面试有个常见误区背一堆资源名词但说不清关系。核心是这条链Pod 是最小运行单元里面可以有一个或多个容器共享网络命名空间和存储卷Deployment 管理一组 Pod 副本负责滚动更新和回滚Service 是访问入口把流量负载均衡到一组 Pod。面试官问为什么有 Pod 还要有容器这个层级因为一个 Pod 里的容器要共享网络和存储比如日志 sidecar 容器挂同一个卷Deployment 又不是直接管容器因为 Pod 会重建、IP 会变需要有个稳定的抽象来管理副本。Deployment 的滚动更新是高频场景题。kubectl set image deployment/demo demonginx:1.25触发滚动更新默认maxUnavailable是 25%maxSurge是 25%意思是更新时最多允许多一个临时 Pod最少保证 75% 的副本可用。面试追问更新到一半发现新版本有问题怎么办回答是kubectl rollout undo deployment/demoK8s 会按更新前的 ReplicaSet 重建 Pod。这个机制的底层是 ReplicaSet每次更新生成新的 ReplicaSet旧的保留回滚就是切回旧的 ReplicaSet 并把副本数调整到目标值。探针是排障和面试都绕不开的知识点。三种探针各自负责什么要能答清livenessProbe失败会重启容器readinessProbe失败会把 Pod 从 Service 的 endpoints 里摘掉但容器不重启startupProbe给启动慢的应用用防止启动过程中被 readiness 杀掉。配置探针时有两个关键参数initialDelaySeconds是容器启动后等多久才开始探测periodSeconds是探测周期。启动快的应用 initialDelay 设 5 到 10 秒足够Java 应用就要看启动时间可能直接给 60 秒。apiVersion: apps/v1 kind: Deployment metadata: name: demo-web spec: replicas: 3 selector: matchLabels: app: demo-web template: metadata: labels: app: demo-web spec: containers: - name: web image: nginx:1.25 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi readinessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: tcpSocket: port: 80 initialDelaySeconds: 15 periodSeconds: 20这段 YAML 的考点集中在 resources 和 probe 上。requests 是调度依据limits 是运行上限只设 limits 不设 requests 容易出问题调度器不知道实际需要多少资源可能把 Pod 塞到一台已经过载的节点。CPU 的100m是 0.1 核CPU limit 超了会被限流内存 limit 超了会直接 OOMKilled这两者的差异也是面试爱问的。Pod 进入CrashLoopBackOff时第一步不是杀 Pod而是kubectl describe pod看 Events再kubectl logs看应用输出。describe 里State: Waiting后面跟的 Reason 是CrashLoopBackOff还是CreateContainerError定位方向完全不同。4.3 集群网络与调度的两道典型题kubectl get nodes显示NotReady这是面试里常见的排障场景题。排查顺序应该是先kubectl describe node看节点上的条件再检查 Kubelet 服务状态systemctl status kubelet接着看 kubelet 日志最后确认 CNI 插件是否正常。很多 NotReady 的原因是 CNI 没配好节点状态就一直起不来。这个例子说明 K8s 排障不是靠感觉是按照控制面、节点服务、容器网络三层往下剥。调度的另一道题是Pod 一直 Pending 怎么办。Pending 的原因最常见是资源不够、节点有污点、PVC 没绑定。kubectl describe pod的 Events 会写明0/3 nodes are available和具体不满足的条件。这里要能答出污点和容忍的关系kubectl taint nodes node1 keyvalue:NoSchedule给节点打污点只有 Pod 上有对应 toleration 才能调度上去。这个机制面试官常用来问怎么让一个节点只跑某个服务答加 taint 再给目标 Pod 加 toleration 就够了。5. 面试避坑与网络排查五个高频翻车点网络是运维面试里看起来简单但翻车率最高的一块也是七条线里最容易被忽略的。这一章把网络考点和面试翻车点合在一起讲每条都按现象、原因、解决来写希望能帮你面试前少踩几个坑。5.1 网络面试题的五个高频考点网络考点集中在四个层级。第一是 TCP 三次握手和四次挥手几乎必考要能画出来、能讲清楚状态迁移。第二是 DNS 解析过程从本地缓存到 hosts 到 DNS 服务器递归查询。第三是 HTTP 和 TCP 的关系以及 HTTPS 握手这里经常和 Nginx 配置连起来问。第四是负载均衡的常见实现LVS、Nginx、HAProxy 的区别。ping、telnet、curl、nc 各自验证什么也要分清楚ping 验证 ICMP 通不通telnet 和 nc 验证 TCP 端口通不通curl 验证 HTTP 应用层通不通。如果服务器上 curl 正常但 ping 不通不要慌。ICMP 和 TCP 是两套协议很多云环境的安全组和防火墙默认禁 ICMP但业务流量正常。面试时能主动说出先确认是测 ICMP 还是 TCP 连通性比背一堆命令显得有条理。反过来 telnet 通但 curl 超时就要往应用层走看 Nginx 配置、后端超时、DNS 解析结果。K8s 里的网络还可以往下追问一层Service 的 ClusterIP 怎么实现负载均衡。答案核心是 kube-proxy它维护一组 iptables 或 ipvs 规则把访问 ClusterIP 的流量转发到后端的 Pod IP。ipvs 模式和 iptables 模式的区别也常被考iptables 是链式匹配规则多时性能下降ipvs 在内核态做哈希查找规则多时更稳定。现在多数集群默认用 ipvs 或 IPVS 模式的 kube-proxy这个点能答上来会显得有实战积累。5.2 坑一把 TCP 三次挥手背成三次握手现象候选人 TCP 状态迁移背得滚瓜烂熟但被问为什么建连是三次断连是四次直接语塞。原因只背了流程没理解报文里的语义。解决用互相对齐来理解——建连阶段SYN 表示我要发起连接ACK 确认对方的 SYN因为双方要互相确认收发能力都正常所以需要三次才能让两边都确认。断连阶段主动方 FIN 表示我没有数据要发了被动方可能还有数据没发完所以先 ACK再等数据发完才回 FIN一来一回就多了一次。能讲出被动方收到 FIN 后还可以继续发数据这层面试官基本就不会再追问。顺带记住 TIME_WAIT 属于主动断开方等待时间默认 60 秒作用是让迟到的报文在网络中自然消失避免污染新连接。5.3 坑二ping 不通就断定网络不通现象给一个从某台机器访问内部服务超时的现场题上来就 pingping 不通就说网络断了。原因没有先区分 ICMP 与业务端口。解决标准路径是先 ping 网关确认三层通再telnet 目标IP 目标端口或nc -zv 目标IP 端口确认四层通再curl -v http://目标地址确认七层通。哪一层先失败故障范围就缩到哪一层往上。比如 ping 网关通、telnet 目标端口不通问题大概率在目标主机的防火墙或服务本身而不是链路。这个排查思路比命令本身值钱答的时候按层次讲面试官会觉得你有章法。5.4 坑三K8s 里看到 Pod 重启就只查容器日志现象kubectl get pods看到CrashLoopBackOff直接kubectl logs日志里什么都没有于是不知道怎么查。原因没意识到容器日志和应用启动是两个层面容器可能根本没起来。解决先kubectl describe pod name看 Events 和容器状态State: Waiting的 Reason 字段是关键。如果 Reason 是CreateContainerError看kubectl logs --previous和容器上一次的退出码如果退出码是 137说明被 SIGKILL 杀掉优先查内存 limit 和 OOMKilled 事件退出码 1 通常是应用自身异常退出才去看业务日志。这条经验来自不止一次的翻车现场先 describe 再看 logs 的顺序能省下大把时间。5.5 坑四主从延迟就狂调网络参数现象MySQL 主从Seconds_Behind_Master很大候选人怀疑是机房网络抖动想调 TCP 参数。原因主从延迟最常见的原因是主库有大事务或从库回放赶不上网络短板反而是少见情况。解决先看SHOW REPLICA STATUS里的Replica_IO_Running和Replica_SQL_Running再判断是 IO 线程拉取慢还是 SQL 线程回放慢。SQL 线程慢的典型场景是主库一条 UPDATE 改了全表几百万行binlog 在从库要一条条回放等主库事务结束从库开始追赶延迟峰值通常能对齐主库大事务的执行时间。更稳妥的架构是开启半同步复制主库提交前等从库确认收到 binlog能显著降低数据丢失概率也会让延迟问题暴露得更早。先看状态命令再定位原因别一开始就动系统参数。5.6 坑五Shell 脚本本地正常crontab 里没输出现象脚本手动执行没问题加到 crontab 后既不报错也没效果。原因crontab 环境变量和交互式 shell 不同PATH 不完整脚本里用到的命令没找到静默失败。解决脚本开头加export PATH/usr/local/bin:/usr/bin:/bin或者所有外部命令写绝对路径调试时把 crontab 执行的输出重定向到日志文件*/5 * * * * /opt/scripts/demo.sh /tmp/demo.log 21。还有一层要注意crontab 默认用的 shell 是/bin/sh如果脚本里有 Bash 语法比如数组首行必须写成#!/bin/bash。遇到没输出的题先查这两处命中率最高。排查这类问题还可以在脚本开头临时加set -x把每一行命令的展开结果打到日志里比盲猜快得多。6. 模拟面试自检七条线怎么算过关准备面试最有效的方法不是背题是按面试官的追问链做自检。我的习惯是把七个方向各拆成一条命令、一个原理、一个场景题。命令关Linux 的ss -tlnp、Shell 的grep -E、Python 的subprocess.run、MySQL 的EXPLAIN参数、Docker 的docker inspect、K8s 的kubectl describe pod、网络的nc -zv每条都要能现场敲出来并解释参数。原理关联合索引的最左前缀、镜像分层与可写层、Pod 与容器的层级关系、TCP 三次建连和四次断连、容器 PID 1 与信号处理。场景题负载高排查、Pod 一直 Pending、主从延迟、端口不通。任选一个能边说边敲命令这关就算过了。这里给你一个可以直接用的自检法拿一台测试机清空一个临时目录把以下动作连续做一遍——写一个 Shell 脚本检查 8080 端口写一个 Python 脚本统计日志文件的行数和错误数用 docker run 起一个 nginx 并映射端口用 kubectl run 跑一个调试 Pod 再kubectl logs。能在一小时内不查资料完成面试里的手写题基本稳了。时间卡不住的话重新看前面章节里代码块的注释重点补不熟的那一段。我自己准备面试时吃过一次亏把 Deployment 的滚动更新参数背得很熟却忽略了kubectl rollout history和undo的实际验证结果模拟面试时一敲命令就露怯。从此之后凡是考点都先在测试环境跑一遍才算过。面试题不需要刷几百道但每道高频题都要能讲出原理、说出命令、复现结果。希望这篇笔记能帮你把七条线串成一张网面试时不是背答案而是像平时干活一样把问题讲清楚。祝顺利。本文还有配套的精品资源点击获取
