企业官网建设流程全解析

前阵子几个准备换环境的朋友来找我过Linux运维面试题，一轮模拟下来我挺有感触：大家基础命令背得都不差，但一到“磁盘明明没满，业务却说写不进去”这种问题，答案就开始零散拼凑。面完一起复盘，发现问题不在知识量，而是不知道该用哪条顺序把这些命令串成一个可执行的排查方案。这系列文章就不打算罗列八股了，我会以常见面试题为主线，把每道题背后的排查思路、命令细节和工作中踩过的坑一起讲透。第一篇先覆盖：文件系统、进程管理、网络排查、Shell脚本和几个典型的应急场景题，适合准备参加运维面试的读者，也适合想系统把老底子查漏补缺的同学。

1. 先搞懂运维面试官到底想看什么

1.1 面试题不是填空题，是场景题

很多新手背了一堆“命令大全”，却不知道面试官为什么问这些。举个例子，面试官问“df -h 和 df -i 有什么区别”，表面看是考两个参数，实际想考的是：磁盘没空间时你该怎么区分“块空间满了”和“ inode 满了”两种完全不同的情况。如果你只回答“一个是看磁盘容量，一个是看索引节点数”，那这道题只算答了三分之一。

我后来总结，运维面试里的基础题，八成都是披着知识点外衣的场景题。面试官真正想看的，是你能不能把一个模糊的告警“磁盘使用率 100%”变成一套有序的排查动作：先 df -h 看没有容量，再 df -i 看有没有 inode，再用 du 定位目录，再用 lsof 找已删除但未释放的文件。这样一套下来，才能证明你平时是真处理过告警，而不是只在书上看过命令。

所以回答这类题，我建议按“表象 - 假设 - 验证 - 处理 - 预防”的顺序来组织，而不是上来就倒一堆命令。这个结构我在后文还会反复用到，它是运维表达和实际操作通用的骨架。

1.2 基础题是在筛“有没有亲自碰过机器”

基础命令题看起来简单，但它是筛人的第一道网。我问过不少候选人“top 输出里的 load average 什么意思”，有人能背出“1 分钟、5 分钟、15 分钟的平均负载”，但追问“三个数分别越来越高说明什么”，就答不上来了。

Load average 在我理解里是一个“排队等待 CPU 运行的任务数”的加权平均值，它不等于 CPU 使用率。单核机器 load 到 1，说明 CPU 基本饱和；四核机器 load 到 1，说明还有余量。面试官想听的不只是定义，而是你能不能从三个数字的走势里读出一台服务器的状态变化。比如 1 分钟 10、5 分钟 8、15 分钟 2，那说明负载是最近才涨上来的，大概率有突发任务或流量进来，不是长期慢性问题。

这类题没有捷径，平时就得自己连上服务器敲命令。命令背得再熟，没看过真实输出，一面试就露怯。基础题的目的是筛掉那些“只看过书、没动过手”的人，你只要真正处理过告警，答起来会自然很多。

1.3 “不会”比“胡说”更安全，但只承认还不够

运维这行，最怕的是不懂装懂。你乱报一个命令或者瞎改配置，线上是要出事故的。所以面试官一定会设计一两道偏题、怪题，观察你在不确定的时候的反应。

我自己的经验是：遇到不会的题，先大方承认“这个点我不太确定”，然后立刻补一句“我会怎么去查”——比如“先 man 看手册，再在测试环境验证，或者抓包确认”。这个反应比硬着头皮编一个答案强得多。面试官想看到的是你面对未知问题时有没有一套“不会也能查明白”的方法论，这恰恰是运维每天都要做的事。

当然，只说“我不会”也分。你要把“我不会”变成“我会用这个方法查明白”，这才是一个合格运维该有的姿态。后面我会具体讲遇到问题怎么拆解，这里先记住一个原则：答案可以不知道，排查路径不能没有。

2. 高频命令与文件系统面试题拆解

2.1 磁盘告警：一条完整到能背下来的排查套路

“磁盘满了怎么办”大概是运维面试里出现频率最高的题，但大多数人答得没有章法。我给一个可以直接用的排查序列，面试时按这个顺序讲，条理会很清楚：

df -h # 看文件系统容量使用率 df -i # 看 inode 使用率 du -h --max-depth=1 / # 快速定位哪个目录占用最大 lsof +L1 # 找出已删除但仍有进程占用的文件 find / -xdev -size +1G -type f # 找出大文件（可选）

先说一个我实际遇到过的案例：某台机器上，业务持续报“No space left on device”，但df -h显示根分区才用了 60%。当时我第一反应也是奇怪，随后敲了df -i，发现/的 inode 已经 100% 了。原因是一个临时目录里产生了海量的 0 字节小文件，把文件系统里可用的 inode 耗光了。这种情况你用du -sh去看容量，一点异常都没有，因为文件本身没有内容。

处理这种问题，先df -i确认是 inode 耗尽，再用for i in /*; do echo $i; find $i -type f | wc -l; done这类循环逐层找哪个目录文件数最多，定位之后再清理。这里有个小心机：find配合-xdev参数，可以避免让你去扫描挂载的其他文件系统，比如/proc、/sys，否则会把排查速度拖得很慢。

还有一个高频考点是“已删除但是空间没释放”，典型场景是日志文件被人用rm删了，但旧进程还握着文件描述符，空间一直被占着。这时df -h还显示满的，但du已经看不到那个文件了。用lsof +L1能直接列出这类文件，看到后面标着(deleted)的条目，记下 PID，和业务确认后重启或者 kill 掉那个进程即可。

fstab也很常考。面试官会问“开机自动挂载配置错了怎么办”，这块我在后面的应急场景里会细讲，这里先记住一个原则：改/etc/fstab之前，最好先执行mount -a验证一遍，它的作用是重新读取 fstab 并挂载所有配置项，能提前发现语法或设备路径问题。

2.2 权限题：rwx 只是开头，SUID/SGID/粘滞位才是拉分点

权限题是面试必问，但大部分人的答案停留在“读、写、执行”。要拿高分，你得能说清楚权限对文件和目录的区别。比如：对文件来说，r 是能读内容，w 是能改内容，x 是能执行；对目录来说，r 是能列出目录内容，w 是能在目录里新建或删除文件，x 是“可进入”目录的权限。很多人不知道，如果目录没有 x 权限，你就算有 r 权限，ls也会报错看不到内容；如果目录没有 w 权限，你就算对里面的文件有 w 权限，也没法删掉这个文件。理解了这些，你才能解释“为什么我在这个目录里删不掉文件，明明文件权限是 666”。

再往下，SUID、SGID、SGID 和 sticky bit 这三个特殊权限是拉分区。用场景记忆最简单：

• SUID（4）：给可执行文件加上，作用是谁执行这个文件，谁就临时拥有文件属主的权限。最典型的是/usr/bin/passwd，普通用户执行它能临时以 root 身份改密码，因为要写/etc/shadow，但你不能顺手拿它去读 shadow。
• SGID（2）：对目录生效时，在这个目录里新建的文件会自动继承目录的属组，常用于团队协作目录。
• Sticky bit（1）：对目录生效时，只有文件属主或 root 才能删除目录里的文件，最典型的是/tmp，任何用户都能往里写，但不能删别人的文件。

检查方式也很简单：ls -l看到s、S、t、T就是特殊权限位，小写代表对应执行位也有，大写代表执行位没有。比如/tmp上那个t就是粘滞位。

还有一个开胃题是 umask。“新建文件默认权限为什么是 644？目录为什么是 755？”答案就是 umask 掩码。文件的默认基值是 666，目录的默认基值是 777，再用“默认基值减掉 umask 中对应的位”得到最终权限，所以 umask 为 022 时，文件就是 666 减去 022 的写权限位，得到 644，目录是 777 减去 022，得到 755。这个题不难，但能一口气说清楚的候选人没有想象中多。

2.3 进程题：把 fork、僵尸进程和孤儿进程讲成一个完整故事

进程这块，面试最常见的是“什么是僵尸进程，怎么产生的，怎么处理”。我建议你放弃死记硬背，把它当故事讲。

一个进程要结束，通常会先变成“僵尸状态”（state 标记为 Z），这个状态的含义是：进程已经退出、内存等资源已经释放，但它还在内核的进程表里占着一个条目，等待父进程来收尸。子进程退出后，父进程应该调用 wait/waitpid 读取它的退出状态，读完之后僵尸条目才会消失。如果父进程一直不读，子进程就一直以僵尸形态挂在进程表里，这就是僵尸进程的来历。

你执行ps -ef或ps aux看到Z状态的进程，又发现它的父进程还活着但没有退出，就可以判断是父进程没处理子进程的退出状态。处理办法不是 kill 僵尸进程本身，因为它已经死了，kill 没用。你要做的是处理它的父进程：确认不影响业务后，重启或 kill 掉父进程，僵尸条目就会由新的父进程（1 号进程 systemd）接手并清理。

和僵尸相对的是孤儿进程：父进程先退出了，子进程还在运行，这时子进程会被 1 号进程收养，这其实是系统有意保底，防止已经变成孤儿的前台或后台进程既没人管，又不知道向谁汇报退出状态。这里有个误区：不是所有没人管的进程都叫僵尸，僵尸的特点是“死了没人收”，孤儿的特点是“活着但没人管”。

面试时再问你“为什么 fork 之后父进程要 wait”，答案就很顺了：一是拿到子进程的退出状态，知道它是正常结束还是异常退出；二是避免子进程变成僵尸；三是处理并发时确保父子进程按预期顺序协作。能讲到这一层，说明你不只是知道ps里有个 Z 状态，而是理解进程生命周期了。

3. 网络排查类场景题实操

3.1 “连不上网”这道题，考的是分层意识

网络场景题是运维面试的重头戏，几乎每场都有。最常见的一道是：“用户说我们的服务连不上数据库，你怎么排查？”如果你一上来就ping数据库 IP，也不是不行，但这是瞎猫撞死耗子的打法。我更推荐先讲一遍分层思路，再一个命令一个命令往下落。

我的习惯是“从近到远、从易到难”。先把范围框清楚，再动手：

ping 目标IP # 先确认链路通不通 ss -tnp # 看本机到目标端口有没有建连 telnet 目标IP 端口 # 或 nc -vz，测试端口可达性 nslookup 域名 # 如果是域名，先看解析对不对 curl -v # 最后看应用层返回

这道题真正的考点是你有没有“分层”的概念。网络模型是分层的：先看物理层和链路层（网卡、交换机），再是网络层（IP、路由），再是传输层（端口、TCP），最后才是应用层。连不上数据库，可能是网络不通、可能路由不对、可能端口被防火墙挡住、可能数据库本身没监听、也可能应用配置连错了地址。你靠 ping 只能测到网络层通不通，但网络层通了不代表端口通；端口通了也不代表数据库能正常认证。

我自己在排查时还有一个习惯：先看“昨天是不是好的”。如果一直没连上，可能是配置或网络从开始就不对；如果突然不通，优先怀疑变更，比如防火墙策略更新了、数据库迁移过、某个服务重启失败。这种“有没有变更”的意识，面试官听到会明显加分，因为线上故障里，变更永远是第一嫌疑人。

还有一个看着基础但很实用的命令是ss。现在很多机器已经不装 netstat 了，用ss -tnp可以看到当前 tcp 连接、监听端口和对应进程，两个参数含义分别是：-t 只看 TCP，-n 不做反向域名解析直接显示 IP 端口，-p 显示对应进程。它比 netstat 快，因为直接读内核 socket 信息，面试时讲这个比张口 netstat 更有“当代运维”的味道。

3.2 TIME_WAIT 别只会背状态，得讲出它会带来什么问题

服务端高并发场景经常出现大量 TIME_WAIT，这也是面试官比较爱问的点。TIME_WAIT 是主动关闭连接的一方在最后进入的状态，要等 2MSL（约 60 秒）才能完全消失。为什么要有它？核心是两个原因：一是保证最后一个 ACK 如果丢了，能让对方重发 FIN；二是防止旧连接的数据包残留，干扰新连接。

问题来了：一台服务器作为代理或客户端主动向外发起大量短连接，它就会产生大量 TIME_WAIT。这些连接本身占着 local 端口，如果处理的够快，一般不是问题；但如果短连接多到端口被占用完，新连接就会因为“Cannot assign requested address”失败。

网上很多帖子说“把 net.ipv4.tcp_tw_reuse 和 tcp_tw_recycle 设为 1”就解决，这里我必须泼盆冷水。tcp_tw_recycle在内核里已经因为设计隐患被移除了，它开启了会干扰 NTP 时间戳，导致跨 NAT 环境连接被莫名丢弃。tcp_tw_reuse可以用，但它主要对客户端连接生效，服务端完全不适用。所以在面试里，你如果能主动说“不建议开 recycle，应该先看连接模型”，这题就稳了。

真正处理大量 TIME_WAIT 的思路是：调整连接复用、改用长连接、或者让连接池来控制连接数量。例如给 nginx 和上游服务之间开 keepalive，或者在应用里用连接池而不是每次请求都新建连接。可以用ss -s看整体连接统计，再ss -tan state TIME-WAIT | wc -l统计数量，确认后再考虑下一步。这么回答，面试官会认为你不仅懂状态，还懂怎么在生产环境稳妥处理。

3.3 tcpdump：抓包不只是一种技能，也是一种面试态度

网络排查里最能体现功力的是 tcpdump。面试时问 tcpdump，一般不是考你背参数，而是给你一个场景：客户端访问服务端很慢，你怎么定位是哪一层慢？这种问题，光在两端各跑一遍 curl 测时间还不够，最好能抓包看交互过程。

一个最小可用的抓包命令是这样：

sudo tcpdump -i eth0 -nn port 3306 -c 100 -w /tmp/db.cap

解释一下：-i 指定网卡，-nn 不做域名和端口反向解析，port 3306 按端口过滤，-c 抓 100 个包就自动停，-w 保存成文件。抓回来后用tcpdump -r /tmp/db.cap读，或者传到本地用 Wireshark 看。面试时讲这个命令，比只说“tcpdump 抓包”强得多，因为它展示了你清楚自己要看什么流量。

抓包最经典的应用是看 TCP 三次握手。正常握手是 SYN、SYN+ACK、ACK 三包；如果只看到 SYN 发出，没有 SYN+ACK 回来，说明包可能被中间设备丢了，或者对端根本没有监听。如果 SYN+ACK 回来了，但你这边不回 ACK，那多半是本地内核/防火墙把包丢了。这种判断，你在面试现场一步步推导出来，比背任何结论都让人信服。

还有一个细节：tcpdump通常要 root 权限，没权限抓包会提示Operation not permitted。遇到这种情况，正确的反应是sudo或者给当前用户加cap_net_raw权限，而不是干瞪眼。面试时如果现场环境没权限，你也可以直接说“我会申请 sudo 或用 cap 方式”，这反而是加分项。

4. Shell 脚本题与自动化现场

4.1 脚本题最容易翻车的几个细节

几乎每次面试都会让手写一小段 Shell，很多人命令行用得溜，一写脚本就露馅，因为脚本和命令行不完全是一回事。最容易翻车的三个点：if 语句的空格、变量的引号、命令出错后的继续执行。

先说空格。Shell 里if [ $? -eq 0 ]，方括号[后面必须有空格，]前面必须有空格，$?前面不是“if$?”连着写。写错成if [$? -eq 0]，脚本会直接报语法错误。这里其实有一个深层原因：[是一个命令，不是 if 的语法符号，所以命令和参数之间必须有分隔符。面试时有人偶尔犯错，可以解释成“中括号其实是 test 命令的别名”，这样显得你懂原理。

第二个坑是变量不加引号。比如你想删除一个目录下的文件，写成rm -rf $dir/*，如果$dir是空，实际执行的就变成rm -rf /*。这是生产事故级别的坑。正确写法是rm -rf -- "$dir"/*，变量加了双引号后，即使为空也只是删一个不存在的路径，而不是把根目录卷进去。再比如统计文件行数，wc -l "$file"比wc -l $file安全，文件名带空格也不会被拆成多个参数。

第三个坑是脚本里某条命令失败但脚本继续执行。默认情况下 Shell 没有set -e时，一条命令失败了照样往下跑，这会导致后续命令处理脏数据。建议写脚本开头加set -euo pipefail，这里面的含义是：-e 出错即停，-u 变量未定义就报错，pipefail 让管道中任何一环失败都让整条管道返回失败。不过面试时如果能主动解释“生产脚本我会开 set -euo pipefail，但交互式命令行不开，因为我不想它随便退出”，这个分寸感非常加分。

4.2 从一到多：批量任务与并发控制

脚本题里经常出现“批量重命名”“批量处理一批文件”“并行执行多个任务”这类的操作。别急着写 for 循环，先问清楚任务量多大，这是脚本思路成熟的标志。

简单粗暴的 for 循环是基础：

for f in *.txt; do mv "$f" "${f%.txt}.log" done

这里用了${f%.txt}这种参数扩展，作用是去掉变量末尾的.txt。对应的${f#prefix}是去掉开头匹配的内容，这是面试手写脚本的高频考点，可以用来实现“把 a.log 改成 2024-01-01-a.log”之类的批量改名需求。

但当文件数是几万的时候，纯 for 循环会很慢，而且容易受目录项数量影响。这就要提到find + xargs的黄金组合：

find /var/log/nginx -name "*.log" -mtime +7 -print0 | xargs -0 -P4 gzip

解释一下：find -print0配合xargs -0，是用空字符分隔文件名，能安全处理带空格和特殊字符的文件名。-P4表示最多同时起 4 个 gzip 进程，这是 xargs 的并发参数，比串行压缩快不少。你甚至可以配合&和wait写一个简单的并发控制：

for i in {1..10}; do process_data "$i" & done wait echo "全部完成"

这个脚本的思路是“给每个任务都放到后台跑，最后用 wait 等全部结束再继续”。它的优点是简单，缺点是如果任务数量很大，一次开太多进程容易把机器打爆。配合xargs -P对并发做限制，才是生产级的写法，面试时如果能把两层都说出来，脚本题的印象分会很高。

4.3 日志按天切割：一个经典却有无数隐藏坑的题

日志切割大概是运维面试里最经典的脚本题了。最容易踩坑的版本是“手动 mv 日志文件后，新日志没有按预期写入新文件”。这是资深运维也会一时卡住的问题，根因是进程的写日志方式。

Nginx 这类服务，主进程在启动时就把日志文件的 fd（文件描述符）打开了，你执行mv access.log access_20250101.log后，它并不会自动重新打开新的 access.log，而是继续往那个已经改了名的 fd 里写。所以正确的切割动作是：先 mv 改名，再让进程重新打开日志文件。

Nginx 的做法是执行kill -USR1 $(cat /var/run/nginx.pid)，USR1 信号在 Nginx 里有特定含义：重新打开日志文件。其他很多服务类似，有的用 HUP 重载配置。所以写切割脚本时，日志路径、PID 文件、信号类型这三样必须核对清楚。

#!/bin/bash LOGDIR=/var/log/nginx YESTERDAY=$(date -d "yesterday" +%Y%m%d) mv $LOGDIR/access.log $LOGDIR/access_$YESTERDAY.log mv $LOGDIR/error.log $LOGDIR/error_$YESTERDAY.log kill -USR1 $(cat /var/run/nginx.pid)

用 logrotate 会更规范，它的核心配置长这样：

/var/log/nginx/*.log { daily rotate 30 compress missingok notifempty sharedscripts postrotate [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid) endscript }

sharedscripts的意思是所有匹配的日志都轮转完之后，只执行一次 postrotate 脚本，而不是每个文件执行一次。Nginx 官方也推荐这种方式。面试时你可以主动对比“手动脚本 vs logrotate”的取舍：手动脚本灵活，适合奇特的目录结构；logrotate 是系统级标准，配置简洁、自带压缩和清理策略。能做到这个对比，基本是加分项。

5. 别小看这些“看似简单”的杀手级问题

5.1 定时任务 cron：为什么脚本手动跑正常，定时任务里不行

cron 几乎是运维每天都要碰的东西，也是面试里被埋坑最多的地方。典型问题是你写了一个脚本，手动执行一切正常，但放进 crontab 就报错，日志文件也不生成。最隐蔽的原因就是 cron 的默认环境变量和你的交互 shell 不一样——它不加载.bash_profile，PATH 通常很窄，比如/usr/bin:/bin，如果你脚本里调用了/usr/local/bin下的命令，直接就是“command not found”。

所以写 cron 里的脚本，第一件事是在脚本开头显式声明环境变量。推荐方式：

#!/bin/bash export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin export LANG=en_US.UTF-8

另一个考点是 crontab 语法。crontab -e是当前用户自己的定时任务，配置文件在/var/spool/cron/用户名；/etc/crontab是系统级定时任务，多了一个用户字段，比如0 2 * * * root /opt/backup.sh。新人在两者之间混着写会踩坑，面试官也喜欢考这个区分。还有cron服务本身可能没检查是否在运行，定时任务不执行先systemctl status cron，或者查/var/log/syslog里的 cron 日志。回答时能把“日志里有没有 task 执行记录”作为排查依据，说明你有实战经验。

5.2 inode 耗尽：空间充足但报错满，别被表象带偏

这个考点我在磁盘小节里提过，但值得单独拿出来，因为它够刁钻。面试官问“用户上传文件报错磁盘满，但 df -h 显示还有 50% 空间”，你如果只答“帮他清理文件”，就掉坑了。正确思路是马上看df -i，因为一个文件系统能容纳的文件数量是有限制的，inode 用完了，就算还剩大量空闲块，也建不了新文件。

这类问题的处理项有几个层级：先用df -i确认，再用for i in /*; do find $i -xdev | wc -l; done找到文件数量最多的目录，逐层下钻，最后清理无效文件。很多时候是某个日志、缓存或临时文件目录堆积了海量小文件。预防手段一般包括：给相关目录配置定期清理策略、在应用层面避免生成小文件、必要时调大 fs.inotify 限制或重新格式化分区时增大 inode 密度。

顺带一提，inode 用完和块空间用完是两个维度的“满”，面试的时候你要能自然地讲出这句话，基本就证明你理解文件系统了。再加一个细节：df -hT和df -i的输出里，那个挂载点一列一样，但使用率不同，是因为它们看的是不同的资源池。stat /命令可以直接看到该文件系统的 inode 总量、剩余和块信息。

5.3 系统启动失败修复：应急题是对综合能力的压测

最后一类高频场景题是“开机后进不了系统，你怎么办”。隐含考点是你对启动流程熟不熟，以及有没有应急处理的冷静。完整启动流程可以简短讲：开机自检、Bootloader（GRUB）、加载内核和 initramfs、挂载根文件系统、交给 systemd 启动各服务。面试时讲清楚这个流程，后面的修复就顺理成章。

最常见的故障是/etc/fstab写错，导致开机挂载失败，系统进入 emergency mode 或直接卡住。这时通常需要进入单用户模式或救援模式修复，改回错误项或注释掉那行。注意一点：进救援后根文件系统通常是只读挂载，你要先mount -o remount,rw /才能改 fstab，忘了这个，你编辑文件会直接报只读系统错误。

别小看这个“先把根文件系统改为可写”的细节，它在面试里是个很经典的坑。能主动说出来，说明你真的进过救援模式。如果在虚拟化环境，还可以通过宿主机把设备挂到另一个系统上修，这也是一个可讲的思路。面试官想看到的是你面对一台启动不了、没有图形界面的机器，依然有办法和它沟通、修复、重启验证。

6. 常见问题速查表与面试表达技巧

6.1 高频题速查表

平时复习难免记不住完整命令，我把最常被问的问题和对应命令整理成一张速查表，面试前扫一眼能快速唤醒记忆。

表格不适合背，更好的用法是拿它当“模拟面试题列表”。看到一个问题，先在脑子里过一遍完整的排查路径，卡住了再查具体命令。这样复习比一行行背命令有效得多。

6.2 面试表达技巧：用“现象 - 假设 - 验证”结构答题

这块算是我面试新人时最看重的软技能。运维面试题没有标准答案，但表达结构决定了你答案的上限。我建议采用“现象描述 - 可能原因列表 - 逐个验证 - 结论处理 - 事后预防”五段式表达。举个例子，面试官问“CPU 使用率 100% 怎么办”，不要一上来就说“我看 top 找进程”。

更好的说法是：先描述现象——“CPU 使用率高，我先要确认是整体高还是某个核高，是用户态高还是内核态高”。再列假设——“可能是一个进程死循环，也可能是中断处理太频繁，还有可能是负载确实大”。然后讲验证步骤——“我执行 top 看进程列表，执行 mpstat -P ALL 1 看每个核的使用情况，再 pidstat 定位具体进程，如果内核态高就用 perf top 看内核热点”。接着给处理方案——“是死循环就果断 kill 或重启，是流量大就扩容”。最后补上预防——“加监控、留存 top 历史记录”。这个结构无论面试还是平时复盘故障，都非常好用。

另外一个面试礼仪要点：面试官描述场景时，信息通常是不完整的。你完全可以先反问“是突然发生还是一直如此？”“是单台机器还是所有机器？”“有没有最近的变更？”这些澄清问题在真实故障里就是首要步骤，在面试里也会让面试官觉得你不是在背答案，而是在用工程师的方式思考。

我个人在实际操作里的体会是：面试准备的最高效方式不是刷题，而是把每一道题都当成一次演习。把答案写下来，然后对着电脑敲一遍相关命令，记录输出，再想一遍“如果这条命令没反应，我下一步怎么办”。这样准备出来的答案，不管怎么追问，你都不会慌。这一篇先到这里，很多细节其实一两句话说不完，后续我会再针对网络进阶、数据库备份恢复、高可用架构这些更深的主题，继续把运维面试里真正值得讲的实战内容拆开聊。