易行男·龙大崇1. 先说点实话：单机运维根本没有想象中那么简单
前阵子凌晨两点，线上一个单机部署的业务系统突然告警，磁盘使用率99%，服务端口全部无响应。我远程登上去之后，先用df -h看了一眼，再用du -sh /var/log/*定位日志目录，最后journalctl --vacuum-size=200M把系统日志清到可控范围，整个链路不到十分钟。
事后同事说"你那几个命令真熟练"。但说真的，单机运维从来不是"会敲几条命令"这么简单，而是你得知道在什么情况下用哪条命令、命令输出告诉我们什么、下一步往哪查。单机环境没有K8s、没有监控大盘、没有自动扩缩容，所有问题都靠一台机器上的工具链去定位，命令就是唯一的"基础设施"。
很多刚入行的朋友以为单机运维过时了，现在都在上云、上容器、上编排。但实际情况是：大量遗留系统、中小公司内部工具、开发测试环境、边缘节点，依然是单机部署。即便是Kubernetes集群里的Node节点，你登录进去排查问题时，用到的还是这套单机运维命令。所以，单机运维命令不是基本功，而是整个运维体系的地基，地基不牢，后面全是空中楼阁。
这篇东西我不会按命令大全的方式罗列，那种文章你收藏了也不会看。我想按实际排障的思维链路来组织：登机后先做什么、进程怎么管、日志怎么查、网络怎么验、磁盘满了怎么办、文件怎么传、哪些命令容易惹祸。每个部分都结合我实际踩过的坑来写，希望能帮你在真出问题的时候，脑子里有一个清晰的排查地图。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 登机第一件事：用一组命令先给机器做"体检"
2.1 uptime和top：先看负载，再看谁在消耗
登录服务器，我习惯先敲uptime，一条命令就能看到当前时间、运行时长、登录用户数和1/5/15分钟的平均负载。
bash复制[root@localhost ~]# uptime
02:21:33 up 68 days, 4:12, 2 users, load average: 4.53, 3.21, 2.87
很多人看到load average超过CPU核心数就觉得机器挂了，其实要分场景。如果CPU是4核，负载4.53说明任务队列已经排满，需要进一步看是CPU忙、磁盘IO慢、还是内存不够导致频繁换页。这里有个容易忽略的细节：单机环境里，负载高不一定是CPU问题，也可能是D状态的进程卡在IO上。所以uptime只能给你"生病了"的信号，具体诊断要交给top。
top命令进去之后，按P按CPU排序，按M按内存排序，这是最基本的。我建议你先看%Cpu(s)那行的us、sy、wa三个值：us高是用户态程序消耗CPU，sy高是系统调用频繁，wa高说明IO在拖后腿。如果wa长期超过30%，别急着调应用，先查磁盘IO，iostat -x 1可以看%util和await，%util接近100%说明磁盘基本跑满了。
2.2 free千万别只看第一行，还得理解buff/cache
内存排查用free -h，但新手最容易在这里被误导。看一个典型输出：
bash复制[root@localhost ~]# free -h
total used free shared buff/cache available
Mem: 15G 9.1G 1.2G 128M 5.1G 5.6G
Swap: 2.0G 200M 1.8G
used显示9.1G，free只有1.2G，但available还有5.6G。原因在于Linux会把空闲内存用作buff/cache来加速文件读写，这部分内存在需要时可以随时释放给应用程序。所以判断内存够不够，只看available，不要被used吓到。
Swap的使用情况也需要留意。如果Swap长期有大量占用，同时si和so（swap in/out）数值一直跳动，说明物理内存已经不够用了，系统在频繁换页，性能会出现断崖式下跌。这时候与其调应用参数，不如先看看有没有内存泄漏，ps aux --sort=-%mem | head -10可以快速列出最吃内存的进程。
2.3 df和inode：磁盘满有两种"满法"
磁盘检查我固定用df -h，但这里藏着一个大坑：df -h只显示文件系统容量，不显示inode使用情况。inode是文件系统里保存文件元数据的数据结构，当小文件数量爆炸时，即使还有剩余空间，系统也会报"No space left on device"。
bash复制[root@localhost ~]# df -i /var
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda3 655360 654900 460 100% /var
看到IUse%100%但df -h还有空间时，别发呆，这就是典型的inode耗尽。通常是用find /var -type f | wc -l数一下文件数量，然后定位到某个目录下海量小文件，比如邮件队列（/var/spool/mqueue）、session临时文件、没清理的缓存目录。解决办法要么rm掉无用文件，要么调整文件系统参数或换用支持更多inode的文件系统，但这属于后话。
2.4 journalctl和dmesg：日志是你最靠谱的目击证人
很多系统问题，应用日志不一定全面，但内核日志不会撒谎。dmesg -T可以看到带时间戳的内核日志，硬件报错、OOM（内存溢出）、磁盘IO错误都会记录在这里。比如内存不够时，dmesg里会频繁出现Out of memory: Killed process，这就是真凶。
使用systemd的机器上，journalctl是可以替代/var/log/messages的日志入口。我常用的几条：
bash复制# 查看某段时间的日志
journalctl --since "10 min ago"
# 看某个单元的完整日志
journalctl -u nginx.service
# 看内核日志
journalctl -k
# 限制一下日志大小，别让journal把磁盘撑爆
journalctl --vacuum-size=200M
3. 进程管理和服务托管：systemd就是单机运维的"管家"
3.1 systemctl不是"记住就行"，你得知道它管了什么
单机环境里服务能不能开机自启、崩溃后能不能自动拉起，全看systemd。很多应用挂了，系统没感知，就是因为服务的Restart策略没配好。一个典型的service单元文件长这样：
ini复制[Unit]
Description=My Demo Service
After=network.target
[Service]
Type=simple
User=app
ExecStart=/opt/app/bin/server
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
这里最关键的三个字段：Restart=always表示不管什么原因退出都重启，RestartSec是重启间隔，User是指定运行用户。
我遇到过一个坑：服务每次启动几秒后就消失，systemctl status也没看到明确的报错，一查日志发现是ExecStart指定的脚本里用了相对路径，导致找不到依赖文件。这类问题靠systemctl本身debug不出来，得配合journalctl -u 服务名去看。
3.2 ps和top的配合：定位"谁在偷吃资源"
ps是静态快照，top是动态刷新，两者各有用途。我比较常用的组合是：
bash复制# 按内存排序看前10
ps aux --sort=-%mem | head -10
# 按CPU排序
ps aux --sort=-%cpu | head -10
# 查看某个进程的线程数
ps -L -p PID
# 查看进程启动时间和运行时长
ps -eo pid,lstart,etime,cmd | grep server
日常排障中，lstart（启动时间）非常有用。如果某个进程的启动时间比预期晚，说明它中途"死过"，这时候去查journalctl或应用日志，看看是什么原因导致重启。
3.3 nohup、setsid和tmux：后台运行不是只能nohup
单机环境经常需要在终端里启动一个长时间任务，很多人的第一反应是nohup command &。这个方案可以，但有个隐患：进程虽然在后台，但它仍然依附于当前终端会话，如果SSH会话断开，nohup可以防挂断，但输出只能通过重定向查看，管理和交互比较麻烦。
我自己的习惯是：短期任务用nohup，长期交互式任务用tmux。tmux可以在服务器上开一个"虚拟终端"，SSH断开了，会话还在，重新连接可以tmux attach恢复。例如：
bash复制tmux new -s deploy # 新建会话
tmux ls # 查看会话
tmux attach -t deploy # 重新进入
有些云服务器或特殊环境装了screen，功能类似tmux。这俩命令并不难，但用熟了之后，你会在很多场景庆幸自己没单纯依赖nohup。
3.4 crontab定时任务：记得看环境和路径
crontab看起来简单，但坑主要在环境变量。Cron执行脚本时的PATH和你在终端里的PATH不一样，脚本里直接写python可能找不到。最好的做法是脚本开头显式定义环境：
bash复制#!/bin/bash
export PATH=/usr/local/bin:/usr/bin:/bin
export JAVA_HOME=/usr/local/java
/usr/local/python3/bin/python3 /opt/scripts/cleanup.py >> /var/log/cleanup.log 2>&1
同时一定要把标准输出和错误重定向到日志，否则排查时会一头雾水。2>&1把错误输出也并入标准输出，这样日志才完整。
4. 文本处理三板斧：grep、awk、sed，日志分析全靠它们
4.1 grep不只是"找关键词"，组合用法才是精髓
单机日志排查，grep是使用频率最高的命令。但很多人的用法停留在grep "error" app.log。实际工作中更常用的是组合过滤和上下文匹配：
bash复制# 查看错误前后的上下文，-B是before，-A是after
grep -B 5 -A 5 "Exception" app.log
# 同时匹配多个关键词
grep -E "ERROR|FATAL" app.log
# 排除干扰项
grep "ERROR" app.log | grep -v "heartbeat"
# 统计数量
grep -c "ERROR" app.log
这里有个经验：日志里"error"不一定全是错误，很多业务框架会把"预期内的异常"也打为ERROR，比如连接超时后的重试。所以定位问题不能只搜关键词，还得看上下文。grep -B和-A就是为此存在的。
4.2 awk处理列，比你想的更能折腾
awk是列处理的神器。最经典的用法就是把日志里的某一列抽出来统计。比如Nginx访问日志的第九列是响应时间，我想看哪些请求最慢：
bash复制awk '{print $9}' access.log | sort -rn | head -20
更复杂的场景：统计某个接口的平均响应时间。假设日志格式是时间 请求路径 状态码 耗时(ms)，那么可以这样：
bash复制awk '{sum[$2] += $4; count[$2] += 1} END {for (url in sum) print url, sum[url]/count[url]}' access.log | sort -k2 -rn | head
awk的底层逻辑是"按行读入、按分隔符切列、逐个处理"，核心要理解$1、$2这些字段编号。默认分隔符是空格，如果日志格式是逗号或竖线，就用-F ','指定。熟悉之后，你会慢慢发现它不只是一个命令，而是一个微型的文本处理语言。
4.3 sed做替换和原地修改，批量改配置的利器
sed最常见的用途是编辑配置文件。比如要批量把配置文件里的IP从旧地址改成新地址：
bash复制# 把/etc/nginx/nginx.conf里的127.0.0.1替换成192.168.1.10，-i是原地修改
sed -i 's/127.0.0.1/192.168.1.10/g' /etc/nginx/nginx.conf
注意sed -i是直接改原文件，改之前最好先备份。稳妥的做法是：
bash复制cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
sed -i 's/127.0.0.1/192.168.1.10/g' /etc/nginx/nginx.conf
除此之外，sed -n '10,20p' file可以只打印第10到20行，配合日志排查也很常用，适合看指定的区间内容。但sed的正则表达式语法有自己的规则，跟awk和grep不完全一致，初学时容易混淆，建议慢慢来，遇到不生效的写法，先在小样本上测试再批量执行。
4.4 一个日志分析实战：把三者串起来
举一个真实例子。线上有个接口偶发超时，我先从Nginx访问日志里筛出响应时间大于1000ms的请求：
bash复制grep "api/order" access.log | awk '$NF > 1000 {print $0}' | head -50
接着看这些慢请求集中在哪个时间段：
bash复制grep "api/order" access.log | awk '$NF > 1000 {print $4}' | cut -d: -f1-3 | sort | uniq -c
最后核对后端应用日志，看看当时有没有GC停顿或数据库慢查询。整个链路不需要什么可视化工具，三个命令组合，几分钟内就能把范围缩小到"某个时段、某个接口、可能关联某个依赖"。这种思路，比一个个记命令更值钱。
5. 网络排查：从ping到telnet到ss，一层层往下扒
5.1 ping通了，不代表服务就通
很多刚入行的同学遇到"连不上服务器"，第一反应是ping。ping通了说明ICMP协议能通，也就是网络层通；但服务没响应往往是传输层或应用层的问题。比如某个Web服务进程挂了，ping照样通，因为ICMP不经过你的服务端口。所以ping只能确认"主机在不在线"，不能确认"服务在不在线"。
确认服务在不在线，最直接的办法是看端口。传统命令是netstat -tlnp，但新版本的net-tools工具包很多机器默认不装了，现在更推荐ss：
bash复制ss -tlnp | grep 8080
输出里能看到端口、监听地址和进程PID。如果端口没监听，那服务大概率没起来。注意这里-t是TCP，-l是监听状态，-n是数字显示端口（不做DNS反解），-p是显示进程信息。加上-p可能需要root权限，因为有些进程信息对普通用户不可见。
5.2 telnet为什么还是排查利器
远程登录虽然都改成SSH了，但telnet在运维领域依然是端口连通性测试的经典工具：
bash复制telnet 192.168.1.10 3306
如果端口通，屏幕会显示Connected to ...或者进入一个空白界面。如果端口不通，会一直卡住直到超时，或者直接Connection refused。
Connection refused说明端口没人监听；而超时（timeout）则说明网络路径不通，通常被防火墙挡了。这两种现象要区分对待：前者查服务进程，后者查防火墙和安全组。常见的防火墙操作包括：
bash复制# firewalld
systemctl stop firewalld
systemctl disable firewalld
# 或者放行某个端口
firewall-cmd --permanent --add-port=8080/tcp && firewall-cmd --reload
注意：生产环境不要轻易
stop firewalld，建议只放行必要端口，否则等于把机器裸奔在网络上。
5.3 ss显示大量的TIME_WAIT，是好事还是坏事
ss -tan可以查看所有TCP连接状态，经常能看到一堆TIME_WAIT。很多新手以为这是异常，其实**TIME_WAIT是TCP四次挥手后的"等待确认"阶段，属于正常状态**。但数量异常庞大（比如几万个）可能说明：高并发短连接场景下，连接被频繁建立和关闭，出现连接耗尽的风险。
这时候可从两个方向调整：一是应用层改用连接池，减少短连接；二是调整内核参数来加快TIME_WAIT回收，比如net.ipv4.tcp_fin_timeout、net.ipv4.tcp_tw_reuse。不过内核参数调整要谨慎，具体值要结合业务验证，不建议照抄网上的配置。
5.4 curl和wget不止是下载工具
curl是单机排障里最灵活的工具。检查HTTP服务是否正常，可以直接：
bash复制curl -I http://localhost:8080/health
curl -v http://localhost:8080/api/order?id=123
-I只拿响应头，-v显示详细交互过程，可以看到TCP连接、TLS握手、HTTP请求和响应。如果curl直接报Connection refused或超时，先怀疑服务进程和防火墙；如果HTTP返回500，则是应用层问题。配合nc（netcat）还可以做简单的端口测试：
bash复制nc -vz 192.168.1.10 3306
-z表示只扫描端口不发送数据。nc比telnet更轻量，但在某些最小化安装的机器上，nc不一定存在，telnet也不一定存在。所以一个实用的习惯是：把ss、curl、telnet或nc至少记住两个，防止目标机器只装了其中之一。
6. 文件传输与备份：tar、rsync、scp怎么选
6.1 tar命令能"打包"也能"解包"，参数别搞混
备份数据、迁移目录，tar是最常用的。要记住一个核心：c是创建归档，x是解归档，z是gzip压缩，f指定文件名。组合起来：
bash复制# 打包并压缩
tar czf /backup/data_$(date +%F).tar.gz /var/lib/mysql
# 解压并解包
tar xzf data_2025-01-01.tar.gz -C /opt/restore
这里有几个细节容易被坑。
第一，tar czf里的z不是必须的，但它决定了生成的归档文件是gzip格式，文件名约定俗成以.tar.gz结尾。如果你用了tar cf生成.tar文件，再用解压工具去解.tar.gz就会报"gzip: stdin: not in gzip format"。
第二，解包时建议加-C指定目标目录，否则它会直接在当前位置生成文件，可能覆盖现有文件。如果不确定归档里的目录结构，先tar tzf 包名看一眼内容再解。
第三，备份数据库目录前先确认数据一致性。直接tar一个正在写的MySQL数据目录，得到的备份可能是损坏的。稳妥的办法是先用mysqldump导出逻辑备份，再打包导出的文件。
6.2 rsync增量同步，比"全量拷贝"高级在哪
rsync在单机运维里主要用于目录同步和备份。它最大的优势是增量传输，只传变化的部分。
bash复制# 把/var/www同步到备份机的/backup/www，-a保留权限和时间戳，-v显示过程
rsync -av /var/www/ backup_server:/backup/www/
# 本地同步也可以
rsync -av /var/www/ /backup/www/
注意源路径末尾的/很关键：rsync -av /src/ /dst/是把src目录里的内容同步到dst下；不带/则是把src这个目录本身放进去。这个细节弄错，目录层级会完全不一样。同步完再看一个参数--delete，它表示把目标端有而源端没有的文件也删掉，实现"完全镜像"。但**--delete要慎用**，如果源目录挂载异常或者路径写错，可能会把目标端的文件清空。
6.3 scp简单直接，但跨机器传文件别忽略权限
小文件传输，scp确实方便：
bash复制scp /tmp/install.sh user@192.168.1.20:/tmp/
scp -r /data/logs user@192.168.1.20:/backup/
但scp每次都是全量传输，大目录备份效率低。另外，如果目标机器的sshd端口不是22，需要加-P 大写的P 端口号。很多新手在这里栽过跟头，scp的端口参数是大写P，而ssh命令的是小写p，记混了会直接报错。大文件、增量需求，建议优先rsync；一次性小文件，scp就够。云上还可以用对象存储上传工具，比如ossutil、coscmd，但单机服务器之间的互传，rsync + scp足以覆盖90%的诉求。
6.4 校验和：传完文件不校验，等于白传
文件传完之后，一定要校验完整性。最常用的是md5sum和sha256sum。
bash复制md5sum CentOS-7-x86_64-Minimal-2009.iso
sha256sum app.tar.gz
两端分别计算一下校验和，一致才能放心使用。对于大文件，sha256sum安全性更高，md5sum现在已经被发现碰撞问题，虽然日常排查影响不大，但涉及安全加固或合规要求时，尽量用sha256sum。
7. 磁盘吃满后的应急流程：先定位，再动手
7.1 用du和find快速定位大文件
磁盘空间告警时，第一反应永远不该是"删文件"，而是"找出谁占的空间"。一条链路如下：
bash复制df -h
du -sh /* 2>/dev/null | sort -rh | head -10
du -sh /var/* 2>/dev/null | sort -rh | head -10
du -sh /*是统计根目录下每个一级目录的大小，sort -rh按数字倒序排。逐层往下，基本能锁定空间大户。
如果想找某个目录下的超大文件：
bash复制find /data -type f -size +2G -exec ls -lh {} \;
-size +2G表示大于2G的文件，-exec ls -lh是找到后执行ls命令显示详细信息。这个组合可以直接告诉你"哪个文件占了多少空间"，通常答案很快浮出水面，比如一个不断增长的日志或一个没清理的数据库binlog。
7.2 lsof + deleted：文件删了，空间却不释放
有一个极经典的场景：你用rm删了一个大日志文件，df -h一看空间竟然没变。原因是文件被某个进程打开着，虽然目录项删了，但进程还在持有文件句柄，空间只有在进程关闭文件后才释放。这时候用：
bash复制lsof | grep deleted
输出里有进程PID和删除的文件名，确认后重启对应进程（或kill -HUP PID触发它重新打开日志），空间才会真正被释放。这个场景在Nginx、Java应用、MySQL上经常出现，遇到"删了文件空间不释放"，不要怀疑rm命令有问题，先查lsof | grep deleted。
7.3 日志切割：比"清了又涨"更省心的方案
日志导致的磁盘问题，最好的解决办法不是手动删，而是配置logrotate让日志自动轮转。系统自带的logrotate默认每天运行一次，配置文件写在/etc/logrotate.d/下。比如Nginx日志的轮转配置可以写成：
bash复制/var/log/nginx/*.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
sharedscripts
postrotate
/bin/kill -USR1 `cat /var/run/nginx.pid`
endscript
}
rotate 7表示保留7份，compress表示压缩轮转下来的旧日志，delaycompress是推迟一天压缩（方便当天继续排查）。这里有个容易忽略的点：日志轮转后，应用不一定能自动切换到新日志文件，所以postrotate里要执行一个信号通知应用重新打开日志文件，Nginx用的是USR1信号，其他服务可能要重启。
7.4 磁盘真满了，哪些临时操作可以"救急"
应急情况下，能快速释放空间的几个地方：
- 清理系统包管理器缓存：
yum clean all或apt-get clean - 清理journal日志：
journalctl --vacuum-time=3d - 清理
/tmp目录下的临时文件（先确认没有进程在使用） - 清理Docker相关垃圾（如果有）：
docker system prune -a
大家注意，docker system prune -a在清理"悬空镜像"和未使用的数据卷，但风险是可能误删你还需要手动构建的缓存镜像。用之前建议docker system df先看一下占用情况，再决定要不要-a。
8. 单机服务压测与快速验证：别等用户报障
8.1 用简单命令测能力和水位
单机部署完一个服务，能不能扛住预期流量，我习惯先用ab（Apache Bench）做个快速压测。比如：
bash复制ab -n 10000 -c 100 http://localhost:8080/api/health
-n是总请求数，-c是并发数。输出里重点关注Requests per second（吞吐）和Time per request（平均单请求耗时），以及Failed requests是否为0。如果Failed requests很多，说明服务在高并发下出现异常，需要看应用日志和内核参数。
ab只对HTTP接口有效。如果是数据库、中间件，可以用mysqlslap、redis-benchmark等专有压测工具。不过日常排障不一定要上重工具，一个time curl -s http://localhost:8080/api就能大致知道接口响应延迟，简单有效。
8.2 一条命令验证"服务对外可不可用"
排查外部用户反馈"访问不了"时，我习惯在服务器本机、局域网另一台机器、外网三个维度分别测一遍：
bash复制curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" http://127.0.0.1:8080/health
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" http://内网IP:8080/health
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" http://公网IP:8080/health
本机能通、内网不通，多半是防火墙或监听地址绑定了回环地址（127.0.0.1），需要检查服务监听的是0.0.0.0还是127.0.0.1。内网能通、外网不通，多半是安全组、路由器转发或公网入口的问题。这个"三层递进"排查法基本能分清责任边界。ss -tlnp确认再配合一次curl，很快就知道问题在哪个环节。
9. 危险命令清单与安全习惯：有些坑，踩一次就够
9.1 rm -rf的真正风险在哪
rm -rf被反复强调不是没道理的。我最深刻的教训是曾经在一台备份机上执行脚本清理旧备份，变量外层少写了一个路径判断，结果直接执行成了rm -rf /。当时机器上的服务全部崩溃，还好不是核心生产库，但恢复也花了半天。从那以后，凡是脚本里出现rm -rf，我都会手动加一层保险：
bash复制#!/bin/bash
TARGET_DIR="/data/backup/old"
[ -z "$TARGET_DIR" ] && exit 1
[ "$TARGET_DIR" == "/" ] && exit 1
rm -rf "${TARGET_DIR}"/*
这层检查的意义在于：任何从变量拼接出来的路径，在删除之前都要防"空值"和"根目录"这两种极端情况。另外，能在回收站模式下解决的，不要直接rm。很多团队会给服务器装trash-cli，先trash而非rm，但这在纯运维场景不一定适用，关键还是自己要有边界意识。
9.2 chmod、chown、dd这些命令的危险边界
chmod -R 777 /是另一个常见翻车点。递归改权限到根目录，会造成系统文件权限错乱，修复成本比重新部署还高。一个小技巧是：改权限之前先用ls -ld确认当前路径，find /somepath -type d -exec chmod 755 {} \;这种操作也要先在一个子目录试跑。
dd命令同样有杀伤力：
bash复制# 这条命令会把整个磁盘清零
dd if=/dev/zero of=/dev/sda bs=1M
日常用dd主要用于备份分区或制作启动盘，但写目标设备前一定要反复确认盘符。建议先用lsblk查看当前磁盘设备列表，再对照确认，不要在只剩一块数据盘的情况下用of=/dev/sdX。
9.3 把命令整理成自己的速查清单
单机运维命令少说也有上百条，不可能全记在脑子里。我的经验是建立一份自己的速查笔记，按场景分类：磁盘应急、网络排查、日志分析、进程管理、文件传输。不用写得很详细，只要看到命令能回忆起思路即可。比如我的笔记里有一条：
磁盘满 → df -h 看分区 → du -sh /* 逐层定位 → lsof | grep deleted 查文件占用 → logrotate 做轮转
这张清单是长期踩坑后的产物，每踩一次新的坑，我都会更新。一次一次更新下来，你就会有属于自己最顺手的那套"运维地图"。
单机运维听起来传统，但真正把这几条命令用熟、用透，能解决的问题远超想象。我在实际排查里，一半以上的故障都是靠着df、ss、journalctl、grep、awk这几个基础命令完成的，根本不依赖什么重型监控平台。你如果能把上面的链路自己动手跑一遍，遇到真实故障时脑子里就有了一条清晰的路径，不会像无头苍蝇一样到处乱查。最后分享一个小技巧：每学一条新命令，就想想它在你常见的故障场景里怎么发挥作用，然后写进自己的笔记里，这样积累的速度会快很多。