这份《运维工程师综合练习卷二》不是我在网上随便抄的题而是把最近半年生产环境里真实踩过的坑、面试候选人高频翻车的点以及团队新人培训时反复强调的常识汇总成的一套自测题。卷一如果考的是“你知道什么”卷二考的就是“你会不会用”。无论你是准备跳槽的运维工程师、刚转行的桌面运维还是想系统梳理 Linux 技术栈的同学都可以拿它做一次体检。下面我按卷面顺序把每道题的出题意图、参考答案和背后的原理逐一说清楚。1. 卷二整体设计与考点分布1.1 为什么这份卷子这么出很多运维候选人花大量时间背命令真到故障现场却连排查思路都没有。卷二的设计目标很明确把考点从“记忆层”拉到“判断层”。比如卷一喜欢考df -h怎么查看磁盘使用率卷二一定会追问如果磁盘明明没满但文件就是创建不出来你会怎么查这种题目没有标准答案却能快速看出一个人是背过题还是真在服务器前面蹲过。出题时我参考了最近一年的生产事故记录和面试题库发现真正拉开差距的集中在四个方向第一是 Linux 基础概念的深度比如 inode、文件描述符、僵尸进程第二是网络排障的实操能力比如抓包、DNS 解析链路、连接状态分析第三是容器与 Kubernetes 的调用链原理尤其是 kubelet 怎么把容器跑起来的第四是桌面运维和工具链的使用熟练度。这四块基本覆盖了从机房到云原生环境的大部分日常场景。1.2 试卷结构与分值分布卷二满分 100 分分为五个模块。基础命令与文件系统占比最大因为这是所有上层技术的底座网络与系统服务紧跟其后毕竟没有网络就没有分布式容器与 K8s 单独划了一块因为现在几乎没有公司不用容器化桌面运维和工具效率占比较小但能看出一个运维工程师的日常习惯最后一道开放题专门考察项目描述和复盘能力这是很多老手都容易丢分的地方。模块题型分值占比考察重点基础命令与文件系统选择题 实操题25%命令理解、内核概念、磁盘与 inode网络与系统服务排障题25%抓包分析、DNS/路由、连接状态容器与 Kubernetes简答 场景题25%CRI 调用链、镜像拉取、Pod 故障恢复桌面运维与效率工具案例分析15%常见故障处理、远程维护、工具箱选型综合运维意识开放题10%故障复盘、项目描述、沟通协作这个分值分布其实也回答了“运维工程师需要学什么”的问题。如果你想走互联网运维路线Linux、网络、容器是铁三角如果偏向国企或传统行业桌面运维、ITIL 流程、国产化系统工具同样重要。卷二没有单纯偏向某一侧而是把通用能力放在前面把场景差异放在后面这样对自测的人更公平。2. 核心理论题深度解析2.1 Linux 基础命令与排查思路卷二里有一道题我每次批改都很感慨生产环境磁盘使用率只有 60%但应用报错“No space left on device”你该如何排查参考答案第一步不是df -h而是df -i查看 inode 是否耗尽。inode 是文件系统用来记录文件元数据的索引节点每个文件或目录都要占用一个。如果小文件数量巨大比如某个日志目录写了几百万个几 KB 的文件inode 就会先于磁盘空间耗尽这时候df -h看起来一切正常但touch新文件会直接失败。实际排查步骤可以这样展开先用df -i确认 inode 使用率再用find /data -xdev -type f | wc -l统计目录下的文件数量定位到具体目录后用ls | wc -l查看文件规模。如果确实是小文件过多应该优先清理过期日志并考虑调整日志轮转策略比如用logrotate按天或按大小分割加上maxage参数定期删除旧日志。这道题考的不只是命令而是你是否理解文件系统的底层结构。另一道高频题是kill -9为什么不能随便用很多人觉得这是最直接的杀进程方式但kill -9会强制内核直接回收进程不给进程任何清理资源的机会。对于数据库、消息队列这类需要保证数据落盘的进程突然被-9杀掉可能导致数据文件损坏或主从不同步。正确顺序是先kill默认发送 SIGTERM让进程自己处理收尾逻辑等待几秒后如果还没退出再考虑逐步升级。2.2 网络运维知识必考点网络这块卷二考的不再是“TCP 三次握手是哪三次”而是给你一个现象让你反推原因。比如这道题用户反馈某天下午网站间歇性打不开ping网关正常dig域名能解析出 IP但curl访问具体接口时卡住直到超时。你会怎么查我的排查路径是这样的先curl -v看卡在哪个阶段是 DNS 解析、TCP 连接还是 TLS 握手然后用telnet ip 443或nc -vz ip 443测试端口连通性再用mtr观察中间链路有没有丢包最后用tcpdump -i eth0 port 80 or port 443 -w /tmp/traffic.pcap抓包分析重点看 TCP 重传和窗口大小。这种问题最常见的原因有两个一是链路 MTU 不一致导致大包被丢弃二是后端连接池被打满导致新连接排队。排查时不能只盯一个点要沿着数据链路一层层往下看。还有一道关于 DNS 的题/etc/resolv.conf里配置了多个 nameserver第一个超时后要等多久才会切换到第二个很多人不知道默认行为和options timeout:1 attempts:2这两个参数的作用。理解这个能解释很多“网络时而通时而不通”的诡异现象。实际上如果第一个 DNS 服务器不可达客户端会先在超时时间后重试然后才切换整个过程可能耗时好几秒应用层就会报超时。卷子里会要求你写出优化方案调小 timeout、增加本地 DNS 缓存或者用nscd、systemd-resolved这类缓存服务来降低解析延迟。2.3 面试高频题Kubernetes 如何调用 containerd这道题几乎成了现在容器运维面试的必考题。要讲清楚得从 kubelet 到容器运行的完整链路说起。kubelet 本身不直接启动容器它通过 CRIContainer Runtime Interface接口与容器运行时通信。当配置了 containerd 作为 runtime 时kubelet 会通过unix:///run/containerd/containerd.sock这个 gRPC 接口向 containerd 发送请求比如PullImage、CreateContainer、StartContainer。containerd 收到请求后并不是直接调用 runc而是会创建一个对应的containerd-shim进程。这个 shim 的作用非常重要它是 containerd 和 runc 之间的中间层负责保持容器标准输入输出、转发信号、上报退出状态。runc 是真正干活的工具它根据 OCI 规范生成容器配置然后通过 Linux 内核的 namespace、cgroups、rootfs 等机制把容器跑起来。容器启动后 runc 退出shim 成为容器的父进程这样即使 containerd 重启也不会导致正在运行的容器退出。生产环境里常用的排查命令是crictl。它和docker命令类似但专门面向 CRI 接口。比如crictl ps -a查看所有容器crictl images查看镜像列表crictl logs查看容器日志crictl inspect查看容器详情。如果遇到 Pod 一直ContainerCreating第一件事就是crictl ps -a看看容器处于什么状态再用crictl logs查看具体报错。如果镜像拉取失败要检查 containerd 的 registry 配置和网络代理。这套调用链是卷二里区分“会用 docker”和“懂容器”的分水岭。2.4 Linux 运维技术栈与运维手册要点卷二里有一道开放问答题请列出你认为的 Linux 运维技术栈并说明每个环节最少要掌握什么。我比较认可的回答是分七层操作系统层、网络层、存储层、中间件层、容器层、监控层和自动化层。操作系统层至少要熟练systemctl、journalctl、ss、lsof这些日常命令网络层要会用tcpdump、mtr、ip、dig存储层要理解 LVM、RAID、NFS 的常见应用中间件层至少会配 Nginx、MySQL、Redis容器层要懂 Dockerfile、docker-compose、K8s 基础对象监控层要会用 Prometheus 加 Grafana 定指标自动化层要会写 Shell 脚本进阶就是 Ansible。和这个配套的是“运维手册包含哪些”这道题。一份可用的运维手册不是把启动命令抄一遍而是要包含四块核心内容系统架构总览所有服务器、服务、端口、依赖关系、日常操作手册常见任务的标准操作步骤、应急预案故障分级、联系人、回滚方案、变更记录每次变更的时间、原因、操作人、影响范围。我见过太多团队靠口口相传维护系统核心人员一离职很多事情就断层了。卷二出的这道题就是希望提醒大家运维工作的可交付物里手册和脚本一样重要。3. 实战操作题全流程复现3.1 从零搭建一个最小化生产系统这道题我要求考生在虚拟机里完成初始化一台 CentOS 或 Ubuntu 服务器部署一个 Nginx MySQL Redis 的应用环境并做好开机自启动和基本监控。这个流程看起来简单但能完整走下来的人不多。第一步是磁盘分区和系统初始化。生产环境不能把所有数据放在一个分区至少要单独划分/data分区给应用数据。如果使用 LVM后续扩容会方便很多例如lvresize -L 10G /dev/vg0/data xfs_growfs /data可以在线扩容。初始化时还要做几件事关闭不需要的防火墙端口、配置时间同步、修改 SSH 默认端口并关闭 root 密码登录、设置文件描述符上限ulimit -n 65535。这些操作每一条都要明白为什么卷子里不允许只背命令。第二步是用 systemd 管理服务。很多新人还在用service nginx start但现代系统里更规范的方式是写一个.service文件。以应用进程为例你需要定义ExecStart、ExecStop、Restartalways、RestartSec3等参数并通过systemctl daemon-reload加载配置。这样应用崩溃后 systemd 会自动拉起不需要额外的守护脚本。注意Restartalways并非万能如果应用因为配置错误导致启动后立即退出systemd 会反复重启形成死循环所以要配合StartLimitIntervalSec和StartLimitBurst配置重试策略。第三步是基础监控和日志归档。搭建生产系统不能只有“能跑”这个目标还要保证“跑挂了能发现、能复盘”。我在卷二里要求至少接入一个 Node Exporter 指标并配置日志按天切割。Prometheus 采集node_cpu_seconds_total、node_filesystem_avail_bytes、node_network_receive_bytes_total这几个基础指标Grafana 上用一个简单的仪表盘展示。日志处理可以先用logrotate避免单文件无限增长把磁盘写满。3.2 桌面运维常见问题处理桌面运维这块卷二里的题都比较接地气。比如有同事反馈开机后卡在 Logo 界面进不了系统你会怎么处理如果系统能进入 GRUB 菜单可以先试试从恢复模式启动如果是 UOS 这类国产系统统信提供了 livecd 运维工具可以用 U 盘启动后挂载根分区检查/var/log里的启动日志修复引导或者重置密码。livecd 是桌面运维人员必须掌握的应急工具它能在系统彻底起不来的时候把数据先捞出来。另一个高频问题是打印机无法打印。很多桌面运维第一反应是重装驱动但实际原因往往是打印服务没启动或端口占用了。Windows 下可以先用net start查看Spooler服务状态再用net stop spooler net start spooler重启打印队列如果打印队列里有卡住的作业要清理C:\Windows\System32\spool\PRINTERS目录下的残留文件。Linux 桌面则是先systemctl status cups查看 CUPS 服务再用lpstat -p -d查看打印机状态和默认打印机。桌面运维还经常遇到 Office 或 WPS 打开文档卡死、Outlook 收件箱报错这类问题。我的经验是先看有没有其他软件冲突再看用户配置文件是否损坏而不是动不动就重装系统。比如 Outlook 频繁提示“正在修复”可以先关闭 Outlook重命名.ost文件让客户端重新同步。这种处理方式比重新配置邮件账号快得多用户体验也好很多。3.3 运维工具箱与效率工具推荐运维工作的效率差距很大程度体现在工具链的使用上。卷二里有一道题是让考生列出自己常用的网络运维工具箱和效率工具。我每次批改都能看出一个人是“经验派”还是“新手村”。网络排查方向我常用的组合是pingmtrtcpdumpWireshark。mtr比traceroute更直观它会持续检测每一跳的丢包率和延迟适合快速定位链路问题。tcpdump抓包之后如果 pcap 文件太大可以用editcap按时间分段再用 Wireshark 的过滤器分析 TCP 重传。命令行效率方向我强烈推荐fzf、ripgrep、jq这三个工具。fzf可以交互式模糊查找文件和历史命令Ctrl R翻历史命令从此变成搜索ripgrep比grep快很多适合在大量日志里搜索关键字jq是处理 JSON 输出的神器比如从curl的 API 响应中直接提取字段省去写 Python 脚本。把这些工具配合 Shell alias 使用日常操作能快一个数量级。现在很多运维工程师也开始用 AI 工具辅助干活。像 DeepSeek harness 这类场景里可以通过插件和 skill 来让模型调用本地命令、解析日志、生成巡检脚本。不过我要提醒一句AI 输出必须经过人工验证尤其是涉及线上变更的命令绝不能直接复制执行。卷子里有一道题就是专门问“如果你用 AI 生成了一段生产环境变更脚本你会怎么验证它”参考答案包括先用bash -n检查语法、在测试环境完整执行、逐行审查涉及删除或重启的命令、准备回滚方案。4. 常见问题与排查技巧实录4.1 答题时最容易被扣分的细节批了这么多份卷子我发现几个反复出现的扣分点。第一个是只写命令不写参数。比如问如何查看某个端口的占用情况只写netstat而不写-tlnp说明根本没有理解参数含义扣一半分。第二个是完全没有权限意识。比如排查系统日志时要求tail -f /var/log/messages但生产环境往往需要sudo很多新人默认自己有 root 权限这在面试里会被视为缺乏生产经验。第三个扣分点是不说影响范围和执行后果。比如问如何重启某个服务答“直接systemctl restart xxx”的人很多但老手会先说“我先确认这个服务是否有健康检查、是否有依赖它的调用方、重启窗口选在低峰期然后执行systemctl status看当前状态再执行 restart最后看日志确认启动成功”。这个差异非常重要因为生产环境里“会重启”和“敢重启”是两码事。第四点是不提回滚方案。很多实际操作题比如修改 Nginx 配置、升级内核参数都必须有回滚路径。我建议在答题时把步骤拆成“操作前备份、执行变更、验证效果、失败回滚”四段这样即使当时没做对也能看出你具备基本的风险意识。4.2 面试答题的话术与思路卷二后面的开放题比如“运维在项目总结时应该如何去描述项目”其实是在考察候选人的表达能力和项目复盘能力。很多运维干了很多活但一开口就是“我负责维护一堆服务器”完全没亮点。比较好的描述方式是先交代项目背景再说明你承担的具体职责然后重点讲你做过哪些优化、解决了哪些疑难问题、带来了什么可量化的结果。举个例子不要说“我负责公司 K8s 集群的日常维护”而要说“我负责生产环境 30 个节点 K8s 集群的稳定性建设通过排查镜像拉取超时和 DNS 解析抖动问题将部署失败率从每周 8 次降到接近 0并输出了一份故障应急文档”。前者是岗位描述后者才是项目总结。如果你用这种结构回答面试官很容易判断你的实际能力和思考深度。另外面试中还常被问到“互联网系统运维和国企系统运维的区别”。这道题没有标准答案但可以从变更流程、技术栈、故障容忍度、合规要求几个角度展开。互联网运维更强调自动化、快速迭代、故障自愈国企或传统行业更看重流程规范、变更审批、责任边界。你要根据自己面试的岗位选择侧重方向而不是一上来就贬低某一方。4.3 我在批卷时印象深刻的错误最后分享几个让我印象深刻的错误答案。有一次问到“如何查看进程启动后是否在监听端口”有人答ps aux | grep nginx这只能说明进程存在不能说明端口监听正常。正确的思路是ss -tlnp | grep 80或者curl -I http://127.0.0.1主动探测。这类题目暴露的问题是把“命令记忆”和“问题解决”混为一谈了。还有一次问“数据库连接数满怎么处理”有人上来就说重启数据库。这在生产环境里是灾难级操作。比较稳妥的思路是先用mysql -e SHOW PROCESSLIST;查看当前连接来源用SHOW VARIABLES LIKE max_connections;看配置上限再分析是否有慢查询或连接泄漏最后才考虑临时调大max_connections或者 kill 掉空闲连接。重启是万不得已的手段而且必须结合主从切换或维护窗口来做。还有一个非常常见的问题不会用journalctl。好多系统日志相关题目有人只会去/var/log/messages里翻。新版本的 systemd 系统里很多服务的标准输出和错误日志都记录在 journal 中journalctl -u nginx.service --since 1 hour ago -p err能快速定位错误。这个习惯看似简单但能极大地提升排障效率。卷二最后我总会写一句话运维不是看谁记得多而是看谁能最快找到根因并把影响降到最低。我个人在实际操作中的体会是这套卷二真正的价值不是拿多少分而是暴露短板。如果你在做题时发现某一块卡了很久说明你已经找到了需要补的方向。建议不要只对着答案看而是开一台虚拟机把命令敲一遍把故障现场重新模拟一遍。踩过的坑多了再遇到类似的问题你才会有那种“我见过、我知道怎么处理”的底气。