企业官网建设流程全解析

做技术面试这些年，我最大的感触是：Linux云计算岗位的招聘标准，早就不是“会敲几条命令”就能过关了。尤其是那些号称“深水区”的面试题，题干往往短得离谱，看起来就像送分题，实际上能把一屋子候选人打得鸦雀无声。标题里那句“90%的运维倒在第8题”真不是夸张，我在真实面试现场见过太多次这种场面：一套题前面七题大家都能聊几句，一到第8题——一个关于磁盘空间消失的场景题——整场冷场。这篇文章就把我整理和实际用过的真题，连同答题思路、原理拆解、避坑经验一起摊开讲，适合准备跳槽的运维、云计算方向的同学，也适合要搭面试题库的团队Leader参考。

1. 为什么Linux云计算面试越来越喜欢考“深水区”

1.1 我眼里的深水区题目长什么样

深水区这三个字，不是说题目本身有多生僻，反而恰恰相反，这类题表面上看特别朴素。举个例子：某台服务器磁盘满了，df显示100%，你du去找大文件却找不到，空间去哪了？再比如：服务器负载飙升到几十，top一看CPU却只有个位数，这机器到底忙不忙？这些问题，拉一个干过一两年运维的人来，他都能听懂题目在问什么，可真正能一条链路答完整的人，十个里难挑出一个。

我复盘过很多次这类面试，发现深水区题有三个共同特征。

第一个特征是题干信息量极少。面试官不会把“有一个进程占着已删除文件，导致磁盘无法释放”这种结论喂给你，他只会给你一个现象，剩下的全靠你自己假设和验证。第二个特征是没有标准答案式的背法。你背下来“用lsof查deleted文件”这句口诀没用，面试官一定会追问：为什么lsof能查到？df和du统计维度差在哪？查到了以后怎么处理？第三个特征是可以连环追问。你说完第一步，他会顺着你的回答往下一层挖，直到挖到你知识的真实边界。

1.2 面试官出这道题时，到底在考察什么

我把深水区题的考察目标拆成三个层次，你在准备面试时可以对着自查。

第一层是命令熟练度。知不知道什么时候该用df，什么时候该用du，什么时候该掏出lsof。第二层是系统原理认知。命令背后是Linux文件系统、进程模型、内核调度这些底子，不懂原理的人就只能背输出，换个场景就不会用。第三层是故障处理思维。这也是最值钱的一层。线上出故障时没人给你标准答案，你面对的是大量噪音：一会儿有人说是业务代码问题，一会儿有人说是网络问题，一会儿监控又报警说磁盘满了。你能不能冷静地做假设、做验证、缩小范围，这才是面试官真正想看到的。

说白了，深水区题考的不是记忆力，是“你有没有真正解决过线上问题”的经验沉淀。而这正好也是它能把90%的人挡在门外的主要原因——很多人有背题的勤奋，却没有动手踩坑的积累。

2. 基础题先探虚实：前三题没你想的那么简单

2.1 系统启动流程题：说说1号进程systemd做了什么

这套真题的第一题通常很平和，一般这么问：一台Linux机器从按下电源到出现登录界面，中间发生了什么？你能说清楚几个阶段？这道题大部分人能答出BIOS、引导加载器、内核启动，然后就开始含糊了。

这里最值得展开的是systemd作为1号进程的角色。不少候选人知道systemd是启动总指挥，管理服务、并行启动、做socket激活，但再往下问就答不上来了。我一般会追问：如果有子进程变成了僵尸，systemd会不会管？答案是：PID 1有一个特殊责任叫“收养孤儿进程”，也就是负责给那些父进程先退出的子进程“收尸”，否则整个系统里会积累一堆没人处理的僵尸。

这个点在云计算面试里特别容易延伸。比如在容器环境里，容器内的1号进程往往就是业务进程本身，如果这个进程没写信号处理和子进程回收逻辑，容器内就会堆满僵尸进程。这个坑我在线上见过不止一次：容器跑了一两个月，ps一看几十个僵尸，业务还正常，但心理压力极大，因为你不知道哪天会触发异常。所以答这道题，别停在“systemd启动服务”这个层面，多提一下cgroup管理、日志收集、以及孤儿进程回收，面试官对你的印象会完全不一样。

2.2 inode视角的硬链接题：一道能聊十分钟的概念题

第二题是经典的inode题，题干也短：硬链接和软链接有什么区别？很多人的回答只有一句“硬链接不能跨文件系统，软链接可以”。这句话是对的，但这道题真正想让你展示的，是怎么从inode角度去看文件系统。

我建议你现场画一个模型：文件在磁盘上由inode和数据块组成，文件名只是目录里的一条记录，它指向inode。硬链接的本质是在目录里新增一条指向同一个inode的记录，所以inode里的链接计数加一；软链接的本质则是一个独立的文件，有自己的inode，数据块里存的是目标路径。

理解这个模型后，很多现象就能解释通了。比如软链接指向的目标被删了，链接还在，但你访问它就会“No such file or directory”；而硬链接完全不受影响，只要inode没被删除，数据随时还能访问。再比如inode链接计数不为零时，就算你rm掉了所有文件名，数据也还在，恢复工具有时会利用这个原理抢救文件。答这道题如果能主动提一句“我平时会用ls -i配合find -samefile来排查inode相关的问题”，效果会好很多，因为这表明你真的用过，而不是考前背的。

2.3 僵尸进程题：为什么kill -9也无能为力

第三题是进程状态题，一般这么出：你发现服务器上有STAT状态为Z的进程，kill -9杀不掉，怎么办？这道题高频率出现在各类运维面试里，但答完整的人极少。

我问过很多人，他们的第一反应都是“加大kill力度”。实际上僵尸进程已经是死掉的进程了，它唯一留下的是进程表里的一个条目，等着父进程调用wait()系统调用把它“收走”。kill -9对僵尸进程根本不起作用，因为它已经没有代码可以执行了，你要处理的是它的父进程：要么让父进程正常退出，由1号进程接管后再回收；要么找到父进程是哪个服务，评估是否能在窗口期重启它。如果父进程是业务主进程，不能随便重启，那就先确认这个僵尸的子进程是否可以忽略，再考虑灰度切换。

这道题在云计算方向还有个变体：容器里的僵尸进程为什么特别难清理？答案就是前面提到的，容器内PID 1不是systemd，而是业务自己，如果它没做subreaper相关的处理，僵尸就会一直堆积。这一延伸直接把基础概念题拉到了容器原理高度，很能看出候选人有没有真正在K8s环境里干过活。

3. 故障场景题：能不能快速定位问题，比背命令更重要

3.1 场景一：负载飙升但CPU很低，到底谁在“假装忙”

这套真题过掉基础概念题之后，会进入故障场景环节。我比较喜欢先扔一道负载题：某台机器load average已经20了，但top一看CPU空闲90%，这是什么情况？这道题为什么能淘汰很多人？因为大家平时一看到负载高就觉得是CPU满，很少有人真的停下来想Load Average到底统计的是什么。

简单说，Linux的负载统计不只是运行队列中的进程，还包括不可中断睡眠状态的进程。一个进程在等磁盘IO、等网络报文、甚至等锁，它都会让负载上涨，但CPU本身可能很闲。遇到这种情况，第一件事不是抓CPU占用，而是用ps -eo state,pid,comm | grep '^D'看有没有大批D状态进程，再用vmstat 1观察CPU的wa列和IO的bi/bo列，最后用iostat -x 1看磁盘的%util和await。如果%util压到90%以上，而await高得离谱，基本可以断定瓶颈在存储层。

这里有个容易被忽略的细节：某台机器用的如果是云盘，%util不高但await很大时，要额外考虑是否存在底层存储限流。我见过有同事在这种情况里反复重启应用，最后发现是云盘IOPS达到上限导致业务进程全部卡在写日志上。所以这道题的正确答题姿势，是把“负载高”当作一个结果，然后按CPU、内存、磁盘IO、网络四类资源做排除，而不是一上来就杀进程。

3.2 场景二：接口变慢，你的排查路径会不会乱

故障场景题里另一道高频题是：用户反馈接口响应很慢，你从哪开始查？这道题没有固定答案，最怕的是候选人一上来就说“重启服务”。我在面试时会特别关注回答里有没有“分层排查”的意识。

一份合格的回答应该像拆洋葱一样，从外到里逐层剥离。第一步是自己复现，用curl -w把DNS解析时间、TCP连接时间、TLS握手时间、首字节时间、总耗时拆开看，哪一段明显偏高，问题就大概率出在哪一段。如果时间都花在连接阶段，要去查服务端连接队列有没有溢出；如果时间花在首字节之前，多半是应用或数据库慢；如果总耗时高但首字节很快，可能是响应体太大或带宽受限。

我把常见的定位命令列成了一张自查表，面试时可以顺着这个思路讲：

我强烈建议把这套流程在实验环境里完整跑一遍。不是只听别人讲，而是真的把一个服务搞慢，再从客户端到服务端逐层看数据，手熟了之后面试答这种题会非常自然，因为你描述出来的细节是真实的。

3.3 场景三：网络带宽跑满，如何快速揪出占用进程

网络类深水区题喜欢这么出：机房带宽告警，业务响应变慢，你怎么找到是什么在占带宽？很多人的第一反应是登录到交换机看流量，但面试官更想听到的是在服务器端怎么定位。

常用的定位链路是iftop -i eth0看实时流量，按IP和端口排序找到流量异常的对端；再用nettop或ss -s看连接统计；最后用lsof -i :端口或fuser找到对应的PID。这里有个生产经验：高峰期的带宽占用，很多时候不是业务进程，而是备份任务、日志同步agent，或者有人误上传了大文件。我遇到过一次诡异情况，某台机器每周末带宽都跑满，查了一圈发现是冷备中心有脚本把全量日志拉到本地分析，平时没人注意它的运行时间。这种经验面试时讲出来，比单纯背命令生动得多。

4. 云计算方向题：容器和K8s进来之后，题目又深了一层

4.1 CrashLoopBackOff：不是看两行日志就完事

云计算岗位面试如果完全不问K8s，基本说不过去。我这套真题里有一道很典型：一个Pod处于CrashLoopBackOff状态，你怎么排查？初学者会直接把kubectl logs贴出来，但这道题在深水区的点在于，日志可能根本没内容。

正确排查链路是先用kubectl describe pod看Events，很多启动失败在Events里已经写了原因，比如镜像拉取失败、探针失败、OOMKilled；再kubectl logs --previous看上一次容器退出前的输出。如果退出码是137，优先怀疑被OOM Killer杀了；退出码是1或非0，要看业务启动日志；如果容器秒退且日志为空，很可能是启动命令没有以前台方式驻留，镜像里写的entrypoint一执行完就退出了。

这里有个常见误区：很多人忘了检查存活探针和就绪探针。我见过一个真实案例，服务本身启动完全正常，但liveness探针访问的路径返回503，导致容器不断被重启，表现也是CrashLoopBackOff，可业务日志里一点报错都没有。这类题答得好不好，关键看你会不会把排查思路从“看应用日志”扩展到“看容器生命周期事件”。

4.2 Pod DNS解析失败：排查链路比你想的长

K8s方向我还喜欢出一道DNS题：新建的Pod访问Service域名时提示DNS解析失败，怎么排查？这题淘汰率也很高，因为很多人只知道kubectl exec进去nslookup，但不知道线索要从哪一层开始捡。

完整的排查链路是这样：先看Pod里的/etc/resolv.conf，确认nameserver是不是指向CoreDNS的ClusterIP；再看kubectl -n kube-system get pod -l k8s-app=kube-dns，确认CoreDNS副本是否正常；如果Pod在跑，用kubectl logs看CoreDNS有没有报错；最后才是进业务Pod用nslookup做测试。

再深入一层，还有一个经常被忽略的坑：系统默认ndots:5会让只有一段名字的短域名先按“带search后缀”的完整域名查一遍，查不到才回退到原域名查询，这会导致DNS查询次数翻倍。如果你配了很多自定义search域，解析延迟会明显上升。把这些细节讲出来，面试官基本能判断你是真的在K8s网络环境里踩过坑，而不只是看过文档。稍高级一点的，还可以提一下NodeLocal DNSCache这类本地缓存组件，为什么它能降低DNS延迟、减少连接数压力。

4.3 新节点扩容后Pod调度不上去：资源视角的深水区

最后一个K8s场景题是：集群新加了一个节点，但新Pod一直Pending，怎么回事？这道题考察的是调度系统的资源视角。

排查顺序建议是：先用kubectl describe node查看节点状态和Taints，如果是NotReady，后续调度器根本不会把Pod放上去；如果节点Ready但Pod还是Pending，要查节点剩余Allocatable资源是否足够，包括CPU、内存、临时存储。很多人在这一步会忽略ephemeral-storage，以为只看内存和CPU就够了，结果Pod因为镜像解包后本地存储不足一直调度失败。再往下看，还要检查Pod是否配置了nodeSelector或节点亲和性，如果标签和节点不匹配，也会被调度器跳过。还有一种隐蔽情况：节点上有污点，但没有对应容忍，Pod不会调度过去。描述Pod的Events里通常已经写了“didn't match node selector”或“taint”之类的原因，答题时按Events、Taints、资源余量三层走，逻辑就非常清楚。

5. 第8题专题复盘：完整还原一次“磁盘已满但找不到文件”的面试

5.1 题目原文与现场答题过程

现在回到标题里说的第8题。这套真题里系统启动、inode、僵尸进程、负载异常、接口变慢、带宽占用、Pod排障一路答下来，候选人基本已经进入状态，然后第8题来了，题干是：

某台服务器的/data分区告警，df -h显示使用率100%，你登上去用du -sh /data/*找大文件，结果加起来只有30GB，分区明明是500GB。你如何解释这个现象，又该如何处理？

就是这么一道题，我在面试时不夸张地说，早前面过一个上午，连一个能完整讲明白的都没有。这道题看起来不偏不怪，但把“原理认知”和“实操经验”的差距拉得特别明显。

5.2 从df和du的差异开始拆解

绝大多数候选人先卡在第一步：他们不理解为什么df和du会不一致。我平时在带人时经常用一个比喻：df统计的是这个文件系统“账本”上的数据块总数和剩余量，而du是把目录里所有文件名对应的块加起来。正常情况下这两个数字应该差不多，但有一种特殊情况会让它们严重偏离——某个文件已经被删除了，但还有进程打开着它。

你从目录树里看，这个文件的名字已经没了，du遍历目录时根本找不到它，不会算它的块；但文件系统层面，这个文件的inode和data block还实实在在占着，因为打开它的进程还在持有句柄，所以df计算时会把这块空间算成已用。结果就是df显示快满了，du怎么找都找不到大头在哪。这就好比你在清点仓库，账上有100箱货，但货架清单上只找到30箱，剩下70箱被某个人抱在手里没放到货架上，那个人就是“打开着文件的进程”。

5.3 完整排查链路与处理办法

面试时如果能讲出原理，我会继续追问：那你会用什么命令定位？一个能体现真实经验的回答，应该包含这几步。

第一步先验证现象，df -h确认文件系统满，同时用df -i看一眼inode是否也满了，因为有些情况下空间没满但inode耗尽也会导致写不进去。第二步用du确认目录树里确实找不到大文件，排除掉自己漏查了目录的情况。第三步使用lsof +L1，这个命令的意思是列出所有link count为0但还被进程打开的文件，也就是“已经被删除但没释放”的文件：

lsof +L1 | sort -n -k7 -r | head -20

按文件大小排个序，能看到哪个进程占着多大的已删除文件。比如输出里有这样一行：

nginx 1234 root 7w REG 253,0 107374182400 1048577 /var/log/nginx/access.log (deleted)

说明nginx进程还在往一个已经被删除的access.log里写数据，占用约100GB。确认之后，处理方法有两种。如果能重启进程，直接重启，句柄释放，空间就回来了。如果不能重启（比如是数据库一类的有状态服务），可以通过/proc/PID/fd/目录找到文件句柄，然后把文件清空：

ls -l /proc/1234/fd/ | grep deleted : > /proc/1234/fd/7

这里把句柄截断为0，进程还在写，但空间已经被释放了，不需要重启，业务影响非常小。这一步很多人答不出来，其实是很实用的线上救急手法。

5.4 深水区延伸：容器和日志系统里也藏着同样的坑

答完上面这些，这道题在面试里还能继续往下挖：容器环境下这个现象常见吗？答案是极其常见。很多云原生环境里容器日志没有限制大小，docker/containerd在写日志时做了一层轮转，但如果配置不当，或者容器还留着旧句柄，就会出现日志文件被delete但空间不释放。

典型现场是：/var/lib/docker/containers目录很大，docker system df却看不到异常，你得在宿主机上用lsof去翻containerd或dockerd进程持有的deleted文件。K8s场景下，如果容器日志管理策略（比如max-size、max-file）没配好，也一样会慢慢把节点磁盘撑爆。所以答这道题时，能主动提一句“这种问题在容器日志和日志轮转场景里特别容易复发”，面试官会知道你处理过生产环境，而不只是刷过题库。

顺带说一句，这道题做完之后，不要忘了从根上预防：日志落盘分区独立、logrotate定期测试、监控df与du的差值、定期跑一次lsof +L1检查deleted文件。一次故障处理得好是运气，把防复发方案落地才是真正的经验。

6. 面试答题的通用框架，以及考后复盘清单

6.1 五步定位法：不管什么故障题都适用的回答骨架

看到这里，你应该能感觉到，这套真题里每一道题背后都藏着同一种答题思路。我把这种思路总结为五步定位法，面试前可以拿它套各种故障场景：

第一步，复现问题。先把现象稳定复现出来，确认它是不是一个真实问题，别在假问题上浪费时间。第二步，缩小范围。按客户端、网络、服务端、存储、数据库这样的层次做排除，每次排除一个变量。第三步，定位根因。找到确切的证据链，比如某个命令输出、某条日志、某个指标，而不是猜。第四步，验证解决方案。用最小代价处理，处理完观察一段时间，确认指标恢复到正常。第五步，沉淀文档。把故障复盘写成可检索的记录，避免下次再踩同一个坑。

这套框架答哪些题都通用。就算某道题你确实没遇到过，只要你按这五步走，并且每一步都能说出具体用什么命令、看什么指标，面试官也会觉得你具备解决未知问题的能力。

6.2 面试官不会告诉你的考察点对照表

我把这套真题里出现的考察点做成了对照表，方便你准备时自查。

你会发现，深水区题目虽然场景各不相同，但内核高度一致：能不能把一个简单的现象，沿着原理链路往下拆到底。

6.3 考后复盘清单：题目分类和自我检查

面试结束之后，复盘比刷题更重要。我给自己的复盘流程是这样：先把答不上来的题归类，看看是命令不熟、原理不懂，还是思路太乱；然后在实验环境里把这类题真实跑一遍，不用模拟器，就用虚拟机或者一台临时云主机，把故障造出来再自己定位；最后过一周再重新讲一遍这道题，看能不能不看笔记讲清楚。如果讲不清楚，说明还是没消化，不是背答案能解决的。这套方法我推荐给每一位候选人，它比囤几十套题库有用。

最后再分享一个面试时的个人建议：遇到答不上来的题，先说思考方向，千万别沉默。深水区题难就难在你不可能全遇到过，但你的思考路径本身就是得分点。你可以说“这个现象我没直接见过，但如果是我，我会先确认XX，再看XX”，然后用五步法往下推。面试官手里有一张能力地图，他更在意的是你能不能沿着地图往正确方向走，而不是夸你背得一字不差。我自己面人时，遇到那种能思路清晰地承认“这个我没处理过，但我判断应该从A和B两个方向去看”的候选人，分数往往比那种背了标准答案但一问原理就翻车的要高得多。Linux云计算这个领域，经验是攒出来的，面试也是。