Linux综合实战：从部署Nginx到磁盘满故障排查的运维全流程

上个月给自己安排了一个Linux综合实验：独立交付一台内部服务器，要求能提供Web服务、文件共享、定时备份，还得能扛住一次让人头疼的故障排查。真做起来才发现，平时在终端里东敲一个命令西敲一个命令，和完整跑通一个项目之间的差距，比想象中大得多。这篇文章把整个实验过程整理出来，从选发行版、装系统、初始化，到配网络、挂载存储、部署nginx、编写脚本，最后还人为制造了一次磁盘满的故障来做排查演练。如果你正在准备运维面试，或者一直想从"会敲命令"走到"能管机器"，这份记录应该能给你不少可以照着抄的东西。

先说实验环境。我选的是虚拟机加Rocky Linux，原因很简单：它是RHEL系，和市面上多数生产服务器的操作习惯一致，遇到问题时搜到的资料也最多。机器本身配置不高，4核8G，一块80G系统盘加一块200G数据盘，完全够用。综合实验的目的不是跑多复杂的业务，而是把零散知识点串成一条完整的链路。

1. 实验背景：一台"什么都要干"的小服务器

先交代清楚这台机器要承担什么角色，后面所有的操作都是围绕角色来的。我给它的定位是部门内部的小型基础设施：对内提供静态Web页面方便放文档和通知，对外提供文件共享目录，每天凌晨自动备份关键数据，同时还要承担一个局域网出口的角色，让同一网段里的几台办公机器能通过它统一访问外部网络。

这个定位决定了技术选型。Web服务用nginx，文件共享用NFS挂载一块NAS存储，备份用tar加crontab，局域网共享上网通过内核转发加iptables来做。你会发现这些都不是什么新技术，但组合在一起，就构成了一个非常典型的Linux服务器日常运维场景。很多Linux面试题考的无非就是这些东西的变体：进程管理、权限控制、网络配置、磁盘管理、脚本编写。综合实验的价值不在于你会背多少命令，而在于当这些技术点同时出现在一台机器上时，你能不能清楚地知道每一层发生了什么。

当时我还在README文件里给自己列了一份验收清单，包括：新用户能否正常登录、sudo权限是否生效、NAS开机能否自动挂载、nginx是否随系统启动、定时任务是否按计划执行、磁盘满时监控脚本会不会报警。这份清单一开始觉得很基础，后来才发现它在故障演练阶段救了我一命。先把整个实验的路径在脑子里过一遍，再动手，是这类综合项目最值得遵守的规则。

2. 装系统时的三个关键决定：分区、镜像源、网络初始化

2.1 磁盘分区：/home独立分区到底要不要

装系统时我是吃过亏的。早些年贪图省事，一块盘一个根分区全部搞定，结果用户数据越攒越多，根分区一满，整台机器就变得卡顿、服务频繁报错。所以这次分区我做了几件和以前不一样的事。

系统盘80G按这个方案切分：

我之前一直犹豫要不要把/home单独分出去，后来想明白了：这台机器要建用户、要挂共享目录，用户的个人文件如果直接塞在根分区里，后续做数据迁移、备份、配额管理都很难受。单独划一个/home，将来就算要重装系统，用户数据也可以保留，不会跟着系统一起被格式化。这是一个很多人都忽略的细节：重装系统时只要不动/home分区，用户文件就还在。

数据盘200G没有在装系统时就格式化，我打算装完系统之后再用fdisk分区、mkfs.xfs格式化、mount挂载到/backup。这样做有一个额外的好处：完整走一遍"后期加盘"的流程，生产环境里这是常事，早晚会遇到。

2.2 镜像源替换与软件包源

系统装完之后第一件事不是急着配服务，而是先把软件源换掉。Rocky Linux默认的官方源在国外，实际下载速度经常让人血压升高。我这台实验机在国内网络环境下，统一换成清华源，过程很标准：

cd /etc/yum.repos.d/ # 先备份原始文件 mkdir /root/repo-backup && cp Rocky-*.repo /root/repo-backup/ # 替换 baseurl，注释掉 mirrorlist sed -i -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^#baseurl=http://dl.rockylinux.org/$contentdir|baseurl=https://mirrors.tuna.tsinghua.edu.cn/rocky|g' \ Rocky-*.repo dnf clean all && dnf makecache

这个操作看起来简单，但有两个细节值得说。第一，一定要先备份repo文件，别小看这一步，我见过有人把源改坏了又忘了原始地址，最后只能手动重建配置文件；第二，不要直接删掉mirrorlist行，用#注释掉就行，万一需要切回去还能快速恢复。至于为什么选清华源而不是其他源，纯粹是个人习惯，它同步快、仓库全、和Rocky的版本对应关系清楚。换完源之后顺手执行dnf update -y把系统补丁打了一遍，这是综合实验的起点，也是生产环境必须养成的习惯。

2.3 首次启动前的网络规划

很多新手喜欢把网络配置留到装完系统再折腾，结果没有网络，dnf都用不了，陷入死循环。我现在都是安装到"网络与主机名"这一步时就把IP、网关、DNS填好，相当于进系统之前网络已经是通的。

不过这次我吃了Rocky Linux的一个亏。新版Rocky默认的网卡名和连接名不一定相同，经常出现"改了IP但NetworkManager不认识连接"的情况。比如我的网卡叫ens33，连接名却叫"System ens33"，用nmcli操作时如果搞错名字，配置半天根本不生效。正确姿势是用nmcli先把连接名看清楚：

nmcli con show # 或者直接查看网卡连接 nmcli device status

如果安装时网络没配好，进系统之后补救也不难，一条命令的事：

nmcli con mod "System ens33" \ ipv4.addresses 192.168.10.10/24 \ ipv4.gateway 192.168.10.1 \ ipv4.dns "223.5.5.5 8.8.8.8" \ ipv4.method manual nmcli con up "System ens33"

刚写到这里我就想把主机名也一起定了。整台机器叫lab-server，修改之后我的提示符立刻就能反映出来，后续写脚本、看日志也更清晰。主机名和进程名管理在Linux里是两回事但经常混着谈，等到后面部署服务时我再细说。

3. 系统初始化：用户、权限、密码策略和目录规划

3.1 新建用户与sudo授权

综合实验里最容易被一笔带过但其实至关重要的，是用户和权限管理。我给自己建了一个日常账号，而不是直接拿root往机器上怼。建用户的流程就三行命令：

useradd zhangsan -m -s /bin/bash passwd zhangsan usermod -aG wheel zhangsan

第三条命令是关键。Rocky Linux的sudo配置中，wheel组的成员默认拥有所有命令的sudo权限。我只需要把用户加进组，就完成了授权，完全不需要直接改/etc/sudoers。如果你非要手动编辑sudoers，请务必用visudo，因为这个工具会在保存前做语法检查，防止你写错一行让整台机器的sudo直接瘫痪。

运维里常说的"提权"，落到实操上其实就是sudo和su的正确使用。我的原则是能sudo就不要切root，sudo执行的所有命令都会被记录到/var/log/secure里，哪天出了事还能回溯到底是谁在什么时间执行了什么操作。直接用root干活，操作记录几乎不可查，这是很多线上事故最后说不清责任人的原因。

有一点要补充：创建用户时如果机器上有/etc/skel目录里的模板文件，useradd会自动复制到用户家目录。我习惯在skel里放一个自用的.bashrc片段，里面设置了alias和PATH，这样后面每建一个新用户，都能继承一套自己熟悉的终端环境，节省大量沟通成本。

3.2 密码过期提醒与登录通知

这个选题是来自一个真实经历。之前公司有一台跳板机，有位同事的密码到期当天才发现自己登不进去了，大半夜打电话让我远程给他重置密码。密码过期本身不是问题，问题在于很多人根本不知道自己的密码什么时候到期。

用chage命令可以给每个用户设置密码有效期和提前警告天数：

chage -M 90 -W 7 zhangsan

这条命令的含义是：密码最长使用90天，到期前7天开始提醒。验证是否生效就查一下：

chage -l zhangsan

不过光靠系统自带的警告还不够，因为用户登录时那行小字"warning: your password will expire in X days"很容易被刷过去。我后来写了一个简单的登录提示脚本放到/etc/profile.d/下面，用户一登录就计算当前密码剩余天数并打印出来。脚本思路很简单，用chage -l输出日期，再用date命令算差值，循环遍历所有普通用户。这样即使是不太细心的同事，也会在登录瞬间看到醒目的"还剩12天密码过期"。

3.3 目录规划：data、logs、backup三层结构

这台机器的目录结构我是花了心思规划的。Linux本身的目录规范很成熟，/usr装程序、/etc放配置、/var存运行时数据，但那是给系统用的。针对业务和数据，我额外建立了三个目录并写进了实验文档：

• /data：放业务数据、共享文件、NAS挂载点
• /logs：放所有应用日志，配合logrotate做滚动
• /backup：放tar备份包，数据盘单独挂在这里

当时有人问我为什么不直接放/var下面，反正系统规范也是这样。我说，/var和根分区在同一个磁盘上，如果日志爆炸式增长，最先被拖垮的是根分区的剩余空间，可能导致整个系统假死。把/data、/logs、/backup做成独立挂载点，日志再大也只是撑爆它自己的分区，不会连累系统盘根分区。这是一个非常关键的容错设计，后面故障演练章节里，这个设计的价值会体现得非常充分。

为了配合这个规划，我在/etc/fstab里把数据盘挂载到/backup，并专门为/logs建了一个逻辑卷。装机时没有给/var单独分区，但现在通过LVM的方式做了一次"无损扩容"，也就是把新增的一块磁盘动态加入卷组，再给/var增加逻辑卷容量。整套路径走完，我对LVM、fstab、mount的理解比单纯看文档深了一个量级。

4. 网络与存储挂载：从静态IP到NAS存储

4.1 静态IP配置

IP配置是很多人能够"启动网卡"但不一定"配置正确"的分水岭。实验机要求固定IP，因为它是文件共享服务器和出口网关，如果IP漂移，所有依赖它的机器都会断连。我在第2章里已经用nmcli配好了静态地址，但静态IP配置完成后，还有一个动作要做：确认NetworkManager的配置确实写入了连接文件。

我见过只执行nmcli命令、没有up连接，结果重启后IP还是原来的场景。实际上nmcli con mod只是把配置写入文件，真正让配置生效需要nmcli con up，或者干脆用nmcli con reload再up。这条教训在故障排查时经常用得上。

另外，如果服务器上配置了静态IP，一定要先确认这个地址没有和局域网里其他机器冲突。最土但有效的办法：在配置之前，先ping一下自己要用的IP，如果通了，说明这个IP已经被占用，赶紧换一个。这个步骤虽简单，却是在真实网络中反复用到的经验。

4.2 NAS挂载与开机自动挂载

文件共享是这台服务器的核心功能之一。内网里有一台NAS，存的是部门公共资料，地址192.168.10.20。我在/data下面建了nas目录作为挂载点，先用命令行测试挂载一次：

mount -t nfs 192.168.10.20:/srv/nfs /data/nas

这一条命令能通，只代表当前会话里挂载成功了。要想重启后还能自动挂载，必须写进/etc/fstab：

192.168.10.20:/srv/nfs /data/nas nfs defaults,_netdev 0 0

这个_netdev参数非常关键。它的作用是告诉系统"等到网络就绪后再挂载这个文件系统"。如果漏了它，系统启动时网络尚未初始化就尝试挂载NFS，极大概率会超时失败，然后启动流程卡在那里，严重一点直接进入急救模式。这个问题在CSDN和各类论坛上出现过无数次，属于挂了NAS但踩坑的经典案例。

挂载CIFS/SMB共享时同理：

mkdir -p /data/share mount -t cifs //192.168.10.20/public /data/share \ -o username=shareuser,password=sharepass,uid=1001,gid=1001,iocharset=utf8,vers=3.0,_netdev

写进fstab后别忘了验证一下：

mount -a

mount -a会把fstab里所有项目都重新挂载一遍。如果配置有误，它会当场报错，不会等到重启才暴雷。每次改完fstab我都要执行这个命令，相当于给你一次"后悔药"机会。另一个细节是uid和gid参数，CIFS挂载时如果不指定uid，挂载上来的文件属主会显示为root，普通用户只能看不能改。指定uid=1001就映射到zhangsan这个用户，权限问题迎刃而解。

4.3 局域网出口：让办公机器通过实验机统一访问外部网络

这是实验里比较有意思的一步，把Linux当成一台软路由用。需求很简单：同一局域网里几台办公机器的外联访问，希望统一走这台实验机的出口，便于在出口做访问控制。实现它不复杂，两个要点：开启内核转发，再加一条iptables NAT规则。

先开启IP转发：

echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf sysctl -p

然后配置iptables伪装规则：

iptables -t nat -A POSTROUTING -o ens33 -j MASQUERADE iptables-save > /etc/sysconfig/iptables

这条MASQUERADE规则的含义是：凡是经过这台机器转发出去的数据包，源地址都被替换成这台实验机的IP。办公机器的网关指向192.168.10.10后，它们访问外部网络时看起来都是从一个出口出去的。这套NAT机制的学名叫地址伪装，是局域网共享上网最经典的做法。

我再加一步防止自己忘掉如何恢复：iptables的规则是运行时状态，重启就没了，所以必须iptables-save持久化。同时用systemctl enable iptables确保重启后规则自动加载。生产环境里这里应该再加一层限制，比如只允许特定网段的源地址做NAT，而不是所有流量都放行，但实验机上先跑通基本链路最重要。

5. Web服务与脚本自动化：nginx定时任务与进程管理

5.1 编译安装nginx还是yum安装

部署Web服务时，我几乎没有犹豫就选择了dnf安装nginx，而不是去网上找源码包编译。两者的差别是：dnf/yum安装的nginx版本略旧，但和系统集成度高，systemd服务文件、用户、目录结构全都替你安排好了，开机自启只需要systemctl enable --now nginx一条命令；源码编译则会新很多，模块也可以自己裁剪，但升级和维护全靠个人手工，对一个综合实验来说性价比不高。

安装过程就三条命令：

dnf install -y nginx systemctl enable --now nginx curl -I http://127.0.0.1

配置一个简单的静态站点时，我把站点根目录放在了/data/web下，而不是默认的/usr/share/nginx/html。这算是一个刻意为之的决定：所有业务相关的东西都放/data，备份时只需要备份/data这一个目录，不用满系统找散落的文件。nginx默认站点配置放在/etc/nginx/conf.d/default.conf，我建了一个test.conf指向/data/web：

server { listen 80; server_name lab-server; root /data/web; index index.html; }

nginx启动后，用curl -I验证返回200，Web服务这步就算通了。但服务通了不代表万事大吉，后面第6章的故障正是从这里爆发的。

5.2 脚本自动化：日志清理、数据备份、服务检查

服务部署好之后，重头戏是自动化。实验要求三个场景必须用脚本覆盖：日志清理、数据备份、服务存活检查。我统一把脚本放到了/opt/scripts目录，作为这台机器的"运维工具箱"。

日志清理脚本的设计思路是分层处理。对老旧的日志文件，超过30天直接删除；对大而活跃的日志文件，用truncate截断而不是rm删除，因为正在写入的进程还持有文件句柄，你rm了它也不会释放空间。脚本内容大致如下：

#!/bin/bash # find 删除超过30天的历史日志 find /logs -type f -name "*.log" -mtime +30 -delete # 对活跃日志做截断置空，保留文件让进程继续写 truncate -s 0 /var/log/nginx/access.log 2>/dev/null || true

备份脚本用tar配合日期命名，同时做保留策略，只保留最近7天的备份包：

#!/bin/bash backup_dir=/backup data_dir=/data mkdir -p $backup_dir tar czf $backup_dir/data_$(date +%F).tar.gz -C $data_dir . find $backup_dir -name "*.tar.gz" -mtime +7 -delete

服务检查脚本每5分钟跑一次，探测nginx是否还能正常响应，如果失败就尝试重启，并记录到日志：

#!/bin/bash if ! curl -sf http://127.0.0.1 > /dev/null 2>&1; then systemctl restart nginx echo "$(date) nginx was down, restarted" >> /logs/script_monitor.log fi

挂进crontab：

30 2 * * * /opt/scripts/clean_logs.sh >> /logs/script_cron.log 2>&1 0 1 * * * /opt/scripts/backup_data.sh >> /logs/script_cron.log 2>&1 */5 * * * * /opt/scripts/check_service.sh >> /logs/script_cron.log 2>&1

写crontab时最容易忽略的是环境变量。cron执行的环境和登录shell不一样，PATH可能只包含/sbin和/usr/sbin，脚本顶部#!/bin/bash虽然是固定的，但脚本里如果调用某个不存在于PATH的命令就会失败。我的习惯是在每个脚本开头显式export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin。这一个小细节能省掉大量"手动执行成功、cron执行失败"的排查时间。

5.3 进程管理：修改进程名与进程间通信

自动化脚本跑起来后，进程数量变多，ps输出也开始乱糟糟。尤其是多个功能类似的进程同时运行，光靠PID根本分不清谁是谁。这时就体现出修改进程名的重要性。

最简单的改法针对脚本进程：用exec -a直接给进程起一个可辨识的名字。

exec -a "backup-worker" tar czf /backup/data_$(date +%F).tar.gz -C /data .

exec会用新进程替换当前shell，-a参数修改argv[0]显示名称。执行后ps aux里看到的就是backup-worker而不是一串tar命令。

对于Python等服务进程，我会利用/proc/self/comm接口在程序内部给自己改名：

#!/usr/bin/env python3 import time, os def rename_process(name): with open("/proc/self/comm", "w") as f: f.write(name[:15]) # 内核限制最长15字节 rename_process("web-checker") while True: print("working...") time.sleep(5)

这个技巧花了我不少时间才搞明白，因为/proc/self/comm不是普通文件，它映射的是内核里的进程名称字段，写入长度被限制在15个字符内。运维值班时，ps一眼扫过去全是有意义的进程名，比什么都强。

进程间通信在这台机器上我用了一个命名管道FIFO来做示范。mkfifo建一个管道文件，一个进程往里面写事件，另一个进程读出来处理。当时我在脚本监控里加了一个事件源：nginx每次自动重启，监控脚本就往管道里写一条重启记录，另开一个服务进程专门读取管道内容并负责通知告警。脚本只有几行，但模型很完整：生产者写、消费者读、管道作中间缓冲。

mkfifo /tmp/event.pipe # 生产者 echo "nginx restarted" > /tmp/event.pipe # 消费者 cat /tmp/event.pipe

需要说明的是，真实生产系统里进程间通信用得更多的是systemd的socket机制、消息队列、共享内存，但理解FIFO的原理有助于理解所有这些更复杂机制的底层模型：一端产生数据，一端消费数据，中间有一个双方都认可的通道，并伴随阻塞、缓冲、超时等行为。

6. 实战故障排查：一次磁盘满导致的服务假死

6.1 故障现象与初步排查

实验做到这一步，一切看起来都正常。此时我决定人为制造故障来找茬——在/logs目录下快速生成一个大文件，模拟线上日志爆炸的场景。没过多久，系统开始出现诡异现象：访问nginx页面偶尔超时，curl探测时好时坏，nginx error_log里出现"No space left on device"。

排查的第一反应是看系统整体状态。uptime看负载，free -h看内存，df -h看磁盘。结果一眼锁定问题：/logs分区的使用率达到100%，根分区还好，只有62%。这就是当初把/logs独立挂载带来的好处：日志把/logs塞满了，系统盘根分区没有跟着遭殃，整台机器还能通过SSH连进去做修复，而不是彻底卡死。

继续往深处挖。df显示的是文件系统层，还要找到具体是哪个文件在疯狂占空间。用du从顶层开始逐层排查：

du -sh /logs/* 2>/dev/null

结果发现/var/log/nginx/access.log竟然有90多G。这台机器才跑了一天，正常情况下access.log不该这么大，一定是某个服务在循环写请求日志，大概率是之前的探测脚本每5秒访问一次导致日志疯狂增长。真相来得比想象中快，但要清理它，却引出了更经典的问题。

6.2 定位根因：文件被删除但空间不释放

我先尝试删除这个巨大的日志文件，心想rm之后空间总该回来了吧。结果rm之后df再看，/logs还是100%，一点变化都没有。这个现象几乎每个Linux运维都遇到过，原因在于：nginx进程仍然持有这个被删除文件的文件句柄，只要进程不释放句柄，磁盘空间就不会真正归还。

用lsof确认：

lsof | grep deleted

输出里赫然躺着几个nginx worker进程，句柄指向已经unlink的access.log。这时候只有两条路：要么重启nginx，让进程重新打开日志文件；要么优雅地发信号让nginx重新打开日志，也不需要重启服务。nginx提供了USR1信号用于日志重开：

kill -USR1 $(cat /var/run/nginx.pid)

执行完再看df，/logs的使用率终于降下来了。这个排查链路虽然只有几步，但每一步都踩在经典的Linux文件系统机制上：目录项、文件句柄、inode生命周期。文件被rm只是删除目录项，只要还有进程持有句柄，inode就不会释放，磁盘空间也就一直被占用。这个知识点面试经常考，但亲手复现一次带来的理解深度完全不同。

6.3 修复与预防：logrotate与监控告警

故障恢复只是第一步，怎么防止它再次发生才是重点。我的修复分三层。

第一层是日志滚动配置。Linux自带的logrotate完全可以解决日志无限增长的问题。nginx的日志轮转配置文件放在/etc/logrotate.d/nginx，我改成了每天滚动、压缩、缺失不报错、截断式复制：

/var/log/nginx/*.log { daily missingok rotate 30 compress create 0640 nginx adm sharedscripts postrotate if [ -f /var/run/nginx.pid ]; then kill -USR1 $(cat /var/run/nginx.pid) fi endscript }

这样日志永远只保留30份压缩文件，最老的自动清除，从根本上避免日志撑爆磁盘。

第二层是监控告警。我在第5章的check_service.sh里加了一段磁盘检查逻辑：当任何分区使用率超过80%时，把告警写入日志并打印到控制台。更严肃的做法是接邮件或IM告警，但实验机上先把检测能力做出来就够了。

第三层是目录规划的收益验证。因为/logs是独立挂载点，这次日志爆炸只影响/logs分区，没有拖垮根分区，SSH还能连、诊断命令还能跑。如果在生产环境里不把日志和系统盘分开，一个日志文件就能把根分区塞满，导致整台机器连登录都做不到，那种情况只能强制重启或者进救援模式。这次故障演练让我对"目录规划"这四个字有了实打实的理解，而不再只是文档上的一段规范。

由此我还想提一个进阶概念：fence机制。单机上日志爆炸顶多自己假死，但换到集群环境，一台机器假死会造成整个集群状态分裂。这时就需要fence机制来"物理隔离"故障节点，常见手段是断开电源或锁住共享存储，保证故障节点不会再产生错误数据。这次的磁盘故障演练虽然离集群还很远，但它让我意识到故障处理和故障隔离是两件事，真正上生产之前，fence、监控、备份这三样一个都不能少。

7. 实验验收清单与个人体会

实验做完，我把自己的验收清单逐项打勾：

这份清单本身也是给面试准备的素材。当被问到"你做过什么项目"时，能说清楚一台机器的完整交付、故障处理过程、每一步背后的原因，比报一串技术名词有说服力得多。

最后说一点个人体会。综合实验最值得花时间的不是那些"看起来高级"的操作，而是反复演练故障排查那条线：df、du、lsof、fstab、logrotate这些基础命令和配置文件，在真正出事的时候一个都不能少。我建议每个做完实验的人，都试着故意把系统弄坏几次，比如删掉nginx的pid文件、把fstab里的挂载项写错、用dd塞满磁盘，再一步步把它救回来。亲手处理过故障，再看到生产环境的报警通知，心里才有底。