从date到top：Linux运维高频命令实战与故障排查指南

1. 写在前面：运维人的“肌肉记忆”从哪来

做运维这几年，我最大的体会就是：服务器出故障的时候，没人给你留查文档的时间。深夜两点被告警吵醒，登录服务器的那一刻，你能依赖的只有脑子里那点“肌肉记忆”。Linux命令就是运维吃饭的家伙，你要是连 date 和 top 都用不溜，那排查问题的效率至少慢三倍。

这篇文章想聊的，不是那种“把全量命令抄一遍”的字典式教程，而是从 date 到 top 这一条线上，把运维日常最高频、最实用的指令串起来讲。你会发现这些命令之间是有逻辑关联的：date 管时间、uptime 管负载、top 管进程、free 管内存、df 管磁盘、ss 管网络——这一整套组合拳打下来，基本上服务器的“生老病死”你都能摸透。

我不打算写成教科书。我会把我实际踩过的坑、线上故障排查的经历、以及那些“手册里查不到但运维都知道”的小技巧，一并混进这篇文章里。无论你是刚转行想学 Linux 运维的新人，还是干了几年想体系化梳理一遍的老手，这篇文章应该都能给你点东西。

2. 先把手表校准：date 与时间同步的那些坑

2.1 date 命令的日常用法与格式化输出

别小看 date，它远不止“看一眼当前时间”这么简单。我见过不少新手在写脚本的时候，为了获取一个格式化时间戳，硬是绕了很大一圈弯路。

date 最常用的几个姿势，我直接列出来：

bash复制# 默认输出，适合人看
date
# 输出：2025年 01月 06日 星期一 14:23:45 CST

# 标准日志格式，适合写脚本
date "+%Y-%m-%d %H:%M:%S"
# 输出：2025-01-06 14:23:45

# 纯数字时间戳，适合做备份文件名
date +%Y%m%d%H%M%S
# 输出：20250106142345

# 时间戳（epoch秒），适合程序间传参
date +%s
# 输出：1736144625

这里要重点说一下格式符的坑：%Y 是四位数年份，%y 是两位数年份；%m 是月份且带前导零，%M 是分钟，大小写完全两码事。我经常看到有人把 date +%Y-%m-%d %H:%M:%S 写成 date +%y-%M-%d %h:%m:%s，输出结果根本没法看。

另外，如果你想把一个已知日期转换成时间戳，用 date -d 就行：

bash复制# 把字符串解析成时间戳
date -d "2025-01-06 14:23:45" +%s
# 输出：1736144625

# 相对时间计算，备份常用
date -d "7 days ago" +%F
# 输出：2024-12-30
date -d "next monday" +%F

2.2 时间同步：NTP 与 chrony 的选型对比

date 本身只是显示工具，运维真正要关注的是系统时间准不准。服务器时间漂移会导致日志时间错乱、证书校验失败、分布式任务调度错位，这些问题排查起来非常隐蔽。

传统方案是 ntpd，但现在我建议你优先用 chrony。两者的核心区别在于：

你完全可以把 chrony 想成是“自适应巡航”版本的 NTP。它按需平滑调整时间，而不是生硬地把系统时间往前/往后跳，这样对数据库、消息队列这类对时间敏感的应用更友好。

配置方式也很简单，在 /etc/chrony.conf 里指定时间源：

bash复制# 注释掉默认池，换上公司内部的 NTP 服务器或者国家授时中心
server ntp.aliyun.com iburst
server ntp.tencent.com iburst
# 允许本地客户端查询
allow 127.0.0.1
allow 192.168.1.0/24

改完配置后执行：

bash复制systemctl restart chronyd
timedatectl set-ntp true

查看同步状态用 chronyc tracking，它会显示系统时间与参考时间源的偏差，以及最后一次同步的时间点。

2.3 时间不同步引发的故障案例

说一个我至今印象很深的线上事故。当时有一套 Kafka 集群，突然出现消费者拉取消息频繁超时，而且报错时间点完全没有规律。查了网络、查了磁盘、查了 GC 日志，折腾了快两个小时没有任何进展。

最后是一个老同事顺手敲了一句 date，发现集群里有两台机器的系统时间差了整整 3 分钟。Kafka 对消息时间戳有顺序校验机制，时间偏差直接导致 follower 判断 leader 心跳超时，触发频繁的 leader 重选举。整个过程完全绕过了你的直觉，你不看到 date 根本想不到是这个原因。

从那以后，我把时间检查写进了日常巡检脚本里，每次批量登录服务器第一件事就是：

bash复制for ip in $(cat server_list.txt); do
    echo "=== $ip ==="
    ssh $ip "date '+%Y-%m-%d %H:%M:%S'"
done

多台机器时间一对比，谁快了谁慢了立刻清清楚楚。

3. 从 uptime 看整体负载：服务器的“体温计”

3.1 uptime 输出信息逐字段拆解

很多新人登录服务器，习惯只看 top，但其实应该先看 uptime。它一行输出，信息量很大：

code复制 14:30:01 up 120 days,  3:42,  2 users,  load average: 0.08, 0.03, 0.01

• 14:30:01：当前时间。注意这里哪怕系统时间不准，也会显示系统内部时钟。
• up 120 days, 3:42：服务器已经连续运行了 120 天 3 小时 42 分钟。如果一个机器的 uptime 很长，说明它稳定性不错；但如果长到一年以上，反而要警惕内核版本过旧，没有打过安全补丁。
• 2 users：当前登录的终端会话数。不是一个用户数，而是 session 数。如果你开了两个 SSH 窗口连同一账号，这里会显示 2。
• load average: 0.08, 0.03, 0.01：最后三个数字依次是 1分钟、5分钟、15分钟的平均负载。

3.2 负载均值到底怎么解读才算合适

很多人以为 load average 的合理值是 1.0，超过 1 就危险。这个理解只对单核 CPU 的机器成立。

负载均值的本质是“处于运行状态和不可中断睡眠状态的进程数目的平均值”。你可以简单理解为：平均有多少个任务在排队等 CPU 执行。

判断负载是否过高的标准，要看 CPU 核数：

bash复制nproc
# 直接告诉你 CPU 核数，简洁明了

假设机器是 8 核，那么 load average 到 8 左右才算“满载”，超过 8 意味着有进程在排队。如果 1分钟负载明显高于 15分钟负载，说明系统最近突然繁忙；反过来，1分钟低于 15分钟，说明高峰正在消退。

我看到过不少新手拿一台 4 核服务器，看到负载 2.5 就觉得天塌了，实际上这台机器还远远没到瓶颈。你先 nproc 看核数，再谈负载判断，这个顺序不能乱。

3.3 w 命令与系统状态的联动查看

uptime 是静态快照，想看得更细，用 w：

code复制 14:30:01 up 120 days,  3:42,  2 users,  load average: 0.08, 0.03, 0.01
 USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
 root     pts/0    192.168.1.10    14:20    5.00s  0.02s  0.01s -bash
 root     pts/1    192.168.1.11    14:25    1:02   0.03s  0.03s top

多出来的信息主要是：每个登录用户在跑什么命令，已经空闲多久，占用 CPU 多少。排查“服务器突然卡了，是不是有人跑了重命令”这种问题，w 是第一个该敲的命令。

4. top 命令的深度解读：从入门到实战排查

4.1 top 界面初次见面：两段式布局怎么看

top 是 Linux 运维排查性能问题最常用的命令，没有之一。它的输出分两个大区：上方的系统概况区和下方的进程列表区。

上半部分关键数据：

code复制top - 14:30:01 up 120 days,  3:42,  2 users,  load average: 0.08, 0.03, 0.01
Tasks: 123 total,   1 running, 122 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.5 us,  1.2 sy,  0.0 ni, 95.8 id,  0.2 wa,  0.0 hi,  0.3 si,  0.0 st
MiB Mem :   7977.3 total,   3124.1 free,   2089.4 used,   2763.8 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used,   5550.8 avail Mem 

• Tasks 行：注意僵尸进程数。如果 zombie 持续大于 0 且数量增长，说明有父进程没有正确回收子进程资源，得找到对应进程排查了。
• %Cpu(s) 行：us 是用户态 CPU、sy 是内核态 CPU、id 是空闲、wa 是 IO 等待。如果 wa 长期偏高，说明磁盘 IO 多半是瓶颈，而不是 CPU 不够。
• MiB Mem 行：这里有个误区，很多人看到 used 很大就以为内存不足，其实 buff/cache 这列是内核把空闲内存拿来做了文件缓存，这个数值大说明内存利用充分，不一定是坏事。真正要看的是 avail Mem，它才是“在不触发交换的情况下还能分配给新进程的内存估算值”。

下半部分进程列表，按 CPU 使用率默认排序：

code复制  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1234 root      20   0 1622412 210368  10240 S   12.5   2.6   5:23.45 java
 3456 root      20   0  321456    9800   5200 R    3.1   0.1   0:02.31 top

• VIRT 是虚拟内存总量，包含了共享库、映射文件等，数值大不代表真的占用了这么多物理内存。
• RES 是常驻物理内存，进程实际占用的物理内存大小，分析内存占用优先看这一列。
• SHR 是共享内存，多个进程可能共用这部分。
• %CPU 是进程 CPU 使用率，注意这个值是相对单核计算的，8 核机器上某个进程显示 800% 才说明它用满了所有核。
• TIME+ 是进程累计占用的 CPU 时间，不是实时状态。如果一个进程的 %CPU 不高但 TIME+ 非常大，说明它是个长期运行的“CPU 大户”，需要重点观察。

4.2 top 交互式快捷键：不只是“看一眼”的工具

top 最强大的地方在于它是一个交互工具。进入 top 界面后，有几个快捷键必须刻在脑子里：

• P：按 CPU 使用率排序（默认就是，但如果你切走了，按这个切回来）
• M：按内存占用排序（排查内存泄漏时的第一操作）
• T：按累计 CPU 时间排序（找“长期吃 CPU”的进程）
• c：显示完整命令行。我看进程状态经常先按一下 c，因为只有看到完整路径和参数才能判断这个进程到底在干嘛
• k：杀死指定进程。输入 PID 后会让你选择信号，默认是 15（SIGTERM 正常终止），实在杀不掉再用 9（SIGKILL 强制杀掉）
• r：修改进程优先级（renice）。线上环境不建议随意调整优先级，容易引发其他问题
• 1：展开/折叠每个 CPU 核心的使用情况。多核机器上某个核跑满、其他核空闲，问题大概率出在线程绑核或者单线程程序上
• d：修改刷新间隔。默认 3 秒，排查问题可以改成 1 秒，但注意频繁刷新本身也会消耗一点点系统资源

我排查 Java 应用 CPU 飙高问题时有个固定套路：进 top 后按 P 找出 CPU 最高的进程，记下 PID，然后用 top -Hp PID 查看该进程内部所有线程的 CPU 占用。如果发现某个线程的 CPU 飙高，再把线程 ID 转成十六进制，用 jstack 去比对线程栈。这个流程在后面网络排障章节还会再提到。

4.3 top 命令行参数：适合放进脚本的非交互用法

交互式界面适合人肉排查，但在脚本和自动化巡检里，你要用 top 的批处理模式：

bash复制# 非交互模式，只输出一轮结果就退出
top -b -n 1

# 指定 PID 排查单个进程，-H 显示线程维度
top -b -n 1 -H -p 1234

# 按内存占用排序，取前 20 行
top -b -n 1 -o %MEM | head -20

这里有个细节要注意：-b 批处理模式输出结果特别长，因为你没指定排序和行数，它会输出所有进程。实际脚本里我一般这么组合：

bash复制top -b -n 1 -o %CPU | sed -n '1,20p'

这样既保留了头部系统概况，又能快速看到 CPU 占用最高的进程。把这段命令写进巡检脚本，就能自动采集每一轮的性能快照。

4.4 用 top 定位一次真实的 CPU 飙高问题

说个真实的排查经历。某天业务反馈接口响应突然变慢，我登上去先 uptime，发现 1分钟负载 23，15分钟负载只有 1.8，明显是刚刚才开始异常。

进入 top，按下 P 按 CPU 排序，看到一个 java 进程占到了 350%。切换到 top -Hp 1234 查看线程级别，发现其中一个线程稳定占用 100% 以上。

将这个线程号转成十六进制：

bash复制printf "%x\n" 5678

然后使用 jstack 抓线程栈，找到对应线程 ID 的状态，定位到一段正则表达式相关的代码——正则回溯导致 CPU 死循环。修复方式是重写那段正则，加上了贪婪匹配限制和超时机制。

整个过程从上到下只用了不到十分钟。如果没有 top 的线程级排查能力，这个问题的定位时间可能要翻好几倍。

5. 进程管理全家桶：ps、pstree 与 kill

5.1 ps 静态快照：一个命令看出所有进程的真面目

top 是动态追查问题用的实时工具，而 ps 更适合做静态快照、脚本采集进程状态。两条黄金组合命令如下：

bash复制# 查看所有进程，显示完整命令行
ps -ef

# 查看当前用户所有进程，显示完整命令行
ps aux

这两条命令输出格式略有差异，ps aux 会额外显示 %CPU 和 %MEM 列，所以在排查资源占用时我更习惯直接用 aux。

筛选特定进程的常用姿势：

bash复制# 通过名字找 PID
pgrep -f nginx
# 等价于 ps -ef | grep nginx | grep -v grep

# 一个命令同时查到 PID 和完整信息
ps aux | grep [n]ginx

这里有个老运维都懂的技巧：用 grep [n]ginx 而不是 grep nginx，这样不会把 grep 进程自己匹配出来。虽然现在用 pgrep 更正规，但这个技巧在写脚本时依然很实用。

ps 输出中的 STAT 状态列，新手经常一头雾水，挑几个常见的说：

• R：正在运行或可运行队列中。
• S：可中断睡眠态，等待某个事件发生，最常见。
• D：不可中断睡眠态，通常是等待 IO，这个状态在正常情况下不应该长期出现。如果大量进程处于 D 状态，基本可以判断磁盘或存储子系统出问题了。
• Z：僵尸进程，进程已结束但父进程没有回收它。
• T：停止，可能被 Ctrl+Z 挂起或 kill -STOP 停止。

5.2 pstree：一眼看清进程之间的亲属关系

pstree 是排查进程父子关系的神器，尤其当你面对一堆进程搞不清谁是谁的“爹”时。

bash复制pstree -p
# 显示进程树和 PID

pstree -ap | grep nginx
# 查看 nginx 的父进程和子进程关系

以 nginx 为例，主进程（master）负责读取配置、管理 worker 进程，真正处理请求的是 worker 进程。你用 pstree 一眼就能看出 master 和 worker 的身份关系，而不是在 ps -ef 里靠 PPID 硬比对。

排查僵尸进程时，pstree 的作用尤其大：僵尸进程的父进程是谁，通过 pstree -p 一目了然。你只需要对父进程做处理，比如重启它，僵尸进程就会被系统回收。

5.3 kill 与信号机制：别只会 kill -9

说到杀进程，我强调很多次：不要一上来就 kill -9。哪怕在面试环节，这个问题也经常拿来筛选候选人。kill -9 等于直接强制断电，进程没有机会清理临时文件、释放锁、通知下游服务，很容易留下后遗症。比如 MySQL 这种对数据一致性要求高的进程，被 kill -9 之后，恢复时可能要走崩溃恢复流程。

kill 默认发的是信号 15（SIGTERM），让进程有机会做善后。如果进程卡死没有响应，再考虑 kill -9。完整的排查链路应该长这样：

bash复制# 先确认进程 PID
pgrep -f your_app_name

# 发 SIGTERM 请求终止
kill 1234

# 等几秒验证进程是否退出
ps -p 1234

# 确实退不了再 SIGKILL
kill -9 1234

对于需要批量停止的进程，pkill 按命令名匹配释放进程：

bash复制pkill -f "java.*order-service"

-f 表示匹配完整命令行，注意这个匹配是子串匹配，写不好容易误杀其他进程。我见过有人 pkill -f monitor 把监控 agent 全干掉的悲剧，所以脚本里用 pkill 之前一定要先 pgrep 看看匹配范围是否准确。

6. 内存与磁盘：free 和 df/du 的搭配诊断

6.1 free 命令的“可用内存”到底看哪一列

内存排查是运维的日常功课，free 命令输出里有两个历史遗留坑。

第一个坑，是老版本 free -m 的 -/+ buffers/cache 这一行。在老内核版本的语义里，buffers 和 cache 都属于可回收缓存，所以看“真正用过多少内存”要把 buffers/cache 扣除。新版本系统已经不显示 -/+ buffers/cache 行了，直接看 avail Mem 列就行。

第二个坑，是 free -h 的单位显示问题。-h 对人类友好，但脚本解析时尽量不要用，因为 GiB、MiB 这种带单位的值不方便比较大小。我写巡检脚本一般用：

bash复制free -m
# 输出固定单位 MB，方便 awk 解析和阈值比较

判断内存是否够用建议优先看 available 这一列，它考虑了内核可以回收的缓存，比 free 列更贴近“实际还能分配多少”这个语义。如果 available 快见底了，但 free 还有不少，说明文件缓存占了大头，系统仍处于高压力状态。

6.2 swap 的使用策略与常见误区

swap 的争议一直很大。有人觉得 swap 完全没必要，配置了反而拖慢性能；有人觉得 swap 是救命的。我的观点是：swap 可以配置，但不能当成内存的替代品。它更像一个“缓冲垫”，防止物理内存突然用尽触发 OOM killer 把关键进程干掉。当内存马上耗尽时，系统可以先把一部分不活跃的内存页挪到磁盘 swap 分区上，给活跃进程腾出空间。

运维里常用的做法是调整系统的 swap 倾向性：

bash复制# 查看当前 swap 使用倾向（范围 0-100，值越大越倾向于用 swap）
cat /proc/sys/vm/swappiness

# 临时调整，适合在低内存服务器上避免物理内存被耗尽
sysctl vm.swappiness=10

# 永久生效，写入配置文件
echo "vm.swappiness=10" >> /etc/sysctl.conf
sysctl -p

对于数据库类服务，建议把 swappiness 调低甚至归零，让进程尽量使用物理内存；对于普通 Web 服务，10 左右的取值比较合理。但注意这不是万能解药，如果内存真的不够，调 swappiness 只是在延缓问题爆发。

6.3 df 与 du：磁盘告警时先看大小还是先看占用量

磁盘被打满，运维第一时间用 df -h：

bash复制df -h
# 文件系统级别查看磁盘使用率，直观清楚

定位到某个分区满了之后，再深入目录内部找“罪魁祸首”用 du：

bash复制# 统计当前目录下各子目录的大小，按人类可读方式输出
du -sh *

# 统计并排序，找出最大的那个目录
du -sh * | sort -rh | head -20

du -sh * 只能看当前目录一层，如果目录层级很深，建议配合最大深度限制：

bash复制du -h --max-depth=2 /var/log | sort -rh | head -10

这里分享一个日志磁盘排查的真实经验。某次客户反馈磁盘 100%，我 df -h 看了一下，根分区确实满了。du --max-depth=1 / 一层层钻下去，最后定位到 /var/log/messages 一个文件就有 80 多 G。原因是一个服务的日志级别被误调到了 DEBUG，每天产生天量日志，硬生生把磁盘写满了。

遇到这种场景，标准处置流程是：找到大文件、确认是否可以清理或者切割、修改服务日志级别、清理已占用的磁盘空间。如果不改日志级别直接删文件，第二天大概率又会满。

还有一个高频问题：删除了大文件但磁盘空间没释放。这是典型的现象级问题，原因是文件仍被某个进程占用。用 lsof | grep deleted 定位哪条进程还持有这个文件句柄，重启那个应用进程后空间才会真正释放。

6.4 inode 用完：df 还有空间但无法写入的诡异故障

机上还有大量剩余空间，但新建文件却报错提示“No space left on device”，第一反应往往是 df -h，如果空间很充足，那么多半是 inode 用完了。

bash复制# 查看 inode 使用率
df -i

inode 的作用可以理解为“文件系统的户口本”，每个文件都必须占用一个 inode。如果磁盘分区里全是小文件（比如邮件队列、临时会话文件、大量缓存文件），inode 会被提前耗尽。

定位 inode 占用大户的思路和 du 类似：

bash复制for dir in /*; do
    echo -n "$dir: "
    find $dir -type f 2>/dev/null | wc -l
done

一般来说，/var/spool 下面（比如 postfix 的邮件队列）是 inode 耗尽的重点嫌疑区域。如果还找不到，检查 /tmp 下面是否被某个进程不断写入零碎文件。清理掉之后，inode 使用率就会回落。

7. 日志排查三件套：tail、grep 与 journalctl

7.1 tail -f 为什么会成为运维的“第二生命”

做运维，一半以上的时间花在日志排查上。而日志排查的第一条命令，就是 tail -f：

bash复制# 实时跟踪日志变化，看最新的输出
tail -f /var/log/nginx/access.log

# 看最后 500 行日志，排查较大的文件时比默认 10 行好用太多
tail -n 500 /var/log/messages

tail -f 跟进文件尾部并实时刷新，适合盯着日志诊断问题。但要提一个坑：有些场景下应用的日志文件会做切割，比如每天 0 点重命名一个带日期后缀的文件并新建日志文件。旧版的 tail -f 在高版本内核的 Linux 日志轮转时看不出来新的写入了，此时要用 tail -F（大写），它会按文件名跟踪，即使文件被轮转替换，也会自动打开新文件继续跟踪。

bash复制# 强烈推荐：-F 选项可以应对日志轮转场景
tail -F /var/log/app/application.log

7.2 grep 组合技巧：从海量日志里捞关键行

日志文件动辄几个 G，tail 看不过来，grep 就能派上用场。我总结了几组在真实排障中最高频的组合：

bash复制# 过滤某个关键词，带上行号方便定位
grep -n "ERROR" app.log

# 多条件同时过滤，比如某个用户 ID 在某时间段内报错
grep "user_12345" app.log | grep "ERROR"

# 用 -E 支持正则，批量匹配多个关键字
grep -E "ERROR|FATAL|Exception" app.log

# 在日志目录里递归搜索所有文件，查某个词
grep -r "OutOfMemory" /var/log/app/

一个实战经验：查异常日志时，不要只看 ERROR 级别，很多问题的真正线索藏在 WARN 甚至 INFO 里，要找到“断点”前后各几十行结合起来判断。所以更推荐的做法是：

bash复制# 匹配到 ERROR 后，把这个关键字前后 10 行也一起显示出来
grep -n -A 10 -B 10 "ERROR" app.log

-A 是 after，-B 是 before，有些版本也支持 -C 10，上下各取 10 行。

7.3 journalctl：systemd 时代的统一日志视角

在基于 systemd 的新版发行版上，传统日志文件和管理工具并存的局面，使得 journalctl 有不可替代的地位。它把系统内许多服务的标准输出与错误输出统一收集了起来，查问题不用再挨个翻文件。

bash复制# 查看所有日志，别直接敲，量太大
journalctl -n 100

# 追踪某个服务的最新日志
journalctl -u nginx -f

# 查看指定时间范围的日志
journalctl --since "2025-01-06 14:00:00" --until "2025-01-06 14:30:00"

# 按 PID 过滤某个进程的日志
journalctl _PID=1234

journalctl 还有一个重要特性：对于带服务的应用，可以查它上次启动以来的所有日志。比如服务刚刚被 systemd 重启了，你想看这次启动是否正常：

bash复制journalctl -u your_service -n 300 --no-pager

7.4 日志切割：不重视它，下一个告警就是磁盘满了

日志不切割，迟早会写满磁盘。我前文提到的 80G 日志撑爆根分区的场景，就是因为日志服务没有做轮转切割。生产环境务必要为每个应用规划好日志轮转策略。

以 Linux 自带的 logrotate 为例，配置文件放在 /etc/logrotate.d/ 下面。一个典型的 nginx 日志轮转配置：

bash复制/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 644 nginx adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

要点：rotate 14 保留 14 份，compress 压缩老日志，delaycompress 表示隔一次压缩，防止刚切割的日志还在被进程写入。postrotate 里给 nginx 发 USR1 信号让它重新打开日志文件。

每次配好之后，用 logrotate -d /etc/logrotate.conf 做一次预演，确认配置没有报错再正式上线。

8. 网络排障基础命令：ping、ss、tcpdump 的实战姿势

8.1 ping：不只是“通不通”，还能看出延迟抖动

排查网络问题，第一条命令几乎永远是 ping：

bash复制ping -c 5 192.168.1.1

ping 之外我们常用它来观察网络延迟是否有波动。正常内网延迟应该在 0.x 毫秒上下，如果延迟忽高忽低且伴随丢包，可以先怀疑链路质量问题，再检查网卡速率、双工模式以及交换机端口状态。

但 ping 也有骗人的时候。我遇到过一种情况：ping 网关完全没问题，但业务访问就是超时。排查到最后发现，问题出在服务器的 TCP 连接数被打满，新建连接全部被拒。这说明 ping 只验证了 ICMP 层的连通性，验证不了 TCP 层的应用状态。

8.2 ss 替代 netstat：查看端口与连接状态

很多人还停留在 netstat -anp 时代，但新系统更推荐用 ss，它在连接数量大时性能更好，输出信息也更多。

bash复制# 查看所有监听端口及对应进程
ss -lntp

# 查看所有 TCP 连接
ss -antp

# 按状态统计各连接数量
ss -ant | awk '{print $1}' | sort | uniq -c

ss -lntp 输出中的 State 列若出现大量 SYN-SENT、SYN-RECV，一般说明连接在握手阶段卡住，可能被限流或丢包。若出现大量 TIME_WAIT，这属于正常现象，但如果量级异常大，可能要考虑调整内核参数。

检查某个端口是否被占用是日常最高频操作：

bash复制ss -lntp | grep 8080

如果只显示监听没有进程信息，多半是因为当前用户权限不够，建议用 sudo 执行。

8.3 tcpdump：当所有抽象指标都不够时的终极手段

当网络层面所有指标都正常，但应用就是上报连接被重置或超时，就轮到 tcpdump 出马了。它能直接抓取经过网卡的数据包，让你看清网络上到底发生了什么。

常用抓包姿势：

bash复制# 抓取某个网卡上端口 8080 的流量，保存到文件
tcpdump -i eth0 -nn -s 0 -w /tmp/app.pcap port 8080

# 不看文件，直接实时输出抓包内容，适合分析握手过程
tcpdump -i eth0 -nn tcp port 8080

-nn 不做 DNS 反解和端口名替换，输出速度更快更清晰。-s 0 表示抓取完整数据包，避免截断丢内容。抓完用 Wireshark 打开分析，重点看 TCP 三次握手是否正常完成、是否有 RST 包、重传率是否高。

有一次线上报“偶发性连接失败”，网络部门检查了很多轮都没发现问题。我自己用 tcpdump 抓了几千个包，发现异常连接的特征是服务器在收到 SYN 后返回了 RST。顺着 RST 出现的时间点反查防火墙配置，发现是一条误配的访问控制策略在特定时段生效，把部分 IP 的 TCP 握手直接拒绝了。这类问题如果只看 ping 和 ss，永远查不出来。

8.4 域名解析排查：dig/nslookup 与 DNS 缓存

网络排障很容易忽略 DNS 这一层。服务间调用报“不知道主机名”，很多人第一反应是网络不通，但实际上是域名解析失败。

bash复制# 查看某域名解析到的 IP 地址
dig example.com

# 指定 DNS 服务器查询，绕过本地缓存
dig example.com @8.8.8.8

# 查看本地 DNS 解析顺序
cat /etc/nsswitch.conf | grep hosts

排查 DNS 问题时，有一个经典操作是清空系统解析缓存：

bash复制systemctl restart systemd-resolved
# 或者较老版本的
service nscd restart

如果业务内网用 Java 应用，还需要考虑 JVM 自身的 DNS 缓存机制，默认情况下 JVM 可能缓存 DNS 结果很长时间不刷新。域名 IP 更换后，有些 Java 应用不重启就一直访问旧 IP，这种坑在微服务架构里特别常见。

9. 文件查找与打包：find 和 tar 的高效使用

9.1 find：按时间、大小、类型精准定位文件

排查磁盘占用、清理过期文件、定位特定文件，find 是绕不开的角色。

bash复制# 查找大于 1G 的文件
find / -type f -size +1G 2>/dev/null

# 查找最近 30 分钟内修改过的文件
find /etc/nginx -mmin -30

# 查找 7 天前的日志文件，并直接删除
find /var/log -name "*.log" -mtime +7 -delete

删除操作加不加 -delete，差别非常大。我建议新手在批量删除之前，先不加 -delete 跑一遍看匹配范围是否符合预期，再加执行。比如：

bash复制# 先列出来看看匹配范围
find /tmp -name "*.tmp" -type f
# 确认无误后再删
find /tmp -name "*.tmp" -type f -delete

还有一个常见误区：-mtime +7 表示“7 天前被修改”，-mtime -7 表示“7 天内被修改”，差一个正负号意思完全相反。批量执行前建议先用 -ls 确认结果：

bash复制find /var/log -name "*.log" -mtime +7 -ls

9.2 xargs：让批量操作优雅地跑起来

find 找到一批文件后往往要配合 xargs 做后续处理。xargs 的作用是把前一个命令的输出变成后面命令的参数。

典型场景一：批量改权限。

bash复制find /data/www -type f -name "*.php" -print0 | xargs -0 chmod 644

-print0 和 -0 的配合是为了处理文件名中包含空格的情况。如果不加，文件名一旦带空格，xargs 就会把文件名拆成两段传给后面的命令，很容易报错。

典型场景二：批量统计目录大小。

bash复制find /var/log -type d | xargs du -sh

9.3 tar：打包与压缩分步走，性能与效率兼顾

tar 是备份和迁移的常用工具，高频姿势包括：

bash复制# 打包并压缩
tar czf /backup/app_$(date +%F).tar.gz /data/app

# 解压到指定目录
tar xzf /backup/app_2025-01-06.tar.gz -C /opt/restore

# 查看压缩包里有哪些文件，不解压
tar tzf /backup/app_2025-01-06.tar.gz | head -20

注意 czf 中的 z 表示 gzip 压缩。文件是 mp4、jpg 这类本身已经压缩过的内容时，建议不用压缩选项，直接 tar 打包，节省 CPU 时间：

bash复制tar cf /backup/media.tar /data/media

还有一个实用技巧：排除不想要的目录或文件。比如备份一个应用目录时，想把 node_modules、缓存目录排除在外：

bash复制tar czf /backup/app.tar.gz --exclude=/data/app/node_modules --exclude=/data/app/cache /data/app

10. 用户与权限：新建用户时容易忽略的细节

10.1 useradd 与 adduser：一条命令背后的默认行为

服务器上新员工入职、新项目启动，都要新建系统账号。高频命令是 useradd，在很多发行版上 adduser 是 useradd 的软链接。

bash复制# 一次性指定主目录、Shell、附加组
useradd -m -d /home/devops -s /bin/bash devops

注意 -m 参数：如果不加，很多发行版不会自动创建主目录。新人在测试环境可能没感觉，但一旦上了生产，开发同学登陆后发现自己 cd ~ 进了根目录，肯定会有人来骂你。

创建完用户后设置密码：

bash复制passwd devops

交互式输入密码适合手动操作，自动化脚本里可以用：

bash复制echo "YourPassword" | passwd --stdin devops

不过要说明，--stdin 这个参数在部分发行版上不支持，比如某些 Debian 系发行版默认就没有，需要先安装 whois 包中的 mkpasswd 工具或使用 chpasswd：

bash复制echo "devops:YourPassword" | chpasswd

10.2 sudo 提权：最小权限原则怎么落地

给用户分配 sudo 权限，普遍的做法是编辑 /etc/sudoers 文件，但绝不建议直接手改这个文件——语法错误可能导致所有用户都无法 sudo。正确姿势是用 visudo：

bash复制visudo

典型授权方式：

bash复制# 让 devops 这个用户能执行所有命令（谨慎使用）
devops ALL=(ALL) ALL

# 只允许执行特定命令
devops ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/tail

# 允许一个用户组执行 sudo 且不需要密码（只在特定自动化场景使用）
%devops ALL=(ALL) NOPASSWD: ALL

NOPASSWD 要慎用，等于拆掉了密码这道防线。如果机器被人拿到 shell，等于直接拿到 root。

10.3 用户删除与清理：别把历史坑留给后来人

用户离职或项目下线，清理账号不能只删用户名就完事，还要考虑他留下的文件：

bash复制# 删除用户，同时删除他的主目录和邮件池
userdel -r olduser

# 先查看该用户的所有文件
find / -user olduser 2>/dev/null | head -100

如果直接 userdel 不带 -r，用户主目录残留，磁盘空间会一天天被历史文件吃掉。生产环境做账号清理时，最好先把用户锁定：

bash复制usermod -L olduser

锁完之后再观察几天，确认没有定时任务或服务引用了这个账号，再执行彻底删除。

关于用户组、chmod、chown 这些命令，基本上所有教程都会讲，这里只提一个我实际踩过的坑：给一个目录递归授权时，一定要分清楚文件和目录的差异。比如所有网站文件的权限，应该统一为目录 755、文件 644，一条 chmod -R 777 虽然省事但不安全。新环境我会用：

bash复制find /data/www -type d -exec chmod 755 {} \;
find /data/www -type f -exec chmod 644 {} \;

这样比一刀切 777 安全得多。

11. 指令串联与脚本化：从单条命令到自动巡检

11.1 管道思维：把命令串成生产线

单条命令解决单个问题，但真实运维场景往往是复合问题。管道 | 可以让你把多条命令串成一条生产线。前面也提到过不少组合，这里再分享几个高频的：

按内存占用排序，显示 top 10 进程：

bash复制ps aux --sort=-%mem | head -11

排查某个端口上的连接数，判断是不是连接泄漏：

bash复制ss -ant | grep 8080 | wc -l

统计访问量最高的十个 IP：

bash复制awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

这套“找字段、排重、计数、排序、取前 N”的模板，是我日常处理日志最常用的模式。只要数据能变成文本流，这个套路就能套用。

11.2 一个完整的巡检脚本参考

把前面所有命令串起来，可以写出一个非常实用的巡检脚本框架。不需要多复杂，按顺序输出系统时间、负载、内存、磁盘、TCP 状态，就能覆盖日常 90% 的“看一眼”需求：

bash复制#!/bin/bash
# 系统巡检脚本：输出关键性能指标快照

echo "===== 当前时间 ====="
date "+%Y-%m-%d %H:%M:%S"

echo "===== 系统负载 ====="
uptime

echo "===== 内存使用 ====="
free -m

echo "===== 磁盘使用 TOP ====="
df -h | grep -vE '^(tmpfs|devtmpfs)' 

echo "===== TOP 5 CPU 进程 ====="
top -b -n 1 -o %CPU | sed -n '1,10p'

echo "===== TOP 5 内存进程 ====="
top -b -n 1 -o %MEM | sed -n '1,10p'

echo "===== 监听端口 ====="
ss -lntp | head -20

echo "===== TCP 连接状态统计 ====="
ss -ant | awk '{print $1}' | sort | uniq -c

这个脚本可以直接配合 crontab 定时产出巡检报告：

bash复制*/30 * * * * /usr/local/bin/check.sh >> /var/log/sys_check.log 2>&1

我个人习惯写脚本时总是以绝对路径调用命令，尽量避免在 cron 环境变量不全时找不到命令：

bash复制#!/bin/bash
DATE=/usr/bin/date
UPTIME=/usr/bin/uptime
FREE=/usr/bin/free
DF=/usr/bin/df

这种做法虽稍显繁琐，但在生产环境的 cron 任务里能救你很多次。

11.3 批量运维：for 循环处理多台服务器

日常维护动辄几十台服务器，如果一台台手动敲命令，效率太低。我常用 for 循环配合 SSH 批量采集信息：

bash复制for ip in 192.168.1.10 192.168.1.11 192.168.1.12; do
    echo "===== $ip ====="
    ssh root@$ip "uptime && free -m | head -2"
done

写这类脚本时注意，如果服务器数量多，建议加 -o ConnectTimeout=3 避免某台机器不通时一直卡住：

bash复制ssh -o ConnectTimeout=3 -o StrictHostKeyChecking=no root@$ip "uptime"

StrictHostKeyChecking=no 可以避免首次连接时交互确认，但只建议在可信内网环境用。

11.4 小心命令编排带来的连锁风险

命令串联提高了效率，也放大了风险。一个典型的反面例子：

bash复制find / -name "*.log" -mtime +30 -delete

看起来是清理 30 天前的日志，但如果在 / 下执行且没有排除系统目录，可能把系统日志、应用日志一并删掉。这就是我在前面一直强调“先列后删”的原因。

另一个常见风险是 rsync 和 rm 的组合误操作。比如你想同步某个目录，结果路径写错，把空目录同步过去导致目标目录被清空。这类事故一旦发生，恢复成本极高。所以我的操作习惯是：批量操作之前，先在测试机跑一遍 echo 验证命令结果，再上生产执行。

12. 常用命令速查表：贴在手边的最后一页

文章写到这里，已经覆盖了 date 到 top 这条线上最核心的命令。为了方便日后查阅，我把高频命令整理成一张速查表：

这张表适合贴在工位旁边。真的记不住的时候直接查表，比翻手册快多了。

最后说一点个人体会。命令本身只是工具，真正值钱的是“在合适的场景用合适的命令，并且知道这个命令背后可能带来的连锁反应”。我见过太多人把 kill -9 当万金油，把 chmod -R 777 当救命稻草，短期内解决了问题，长期看却埋了更大的雷。

如果你能把 date 到 top 这一串命令吃透，并且理解了它们之间的联系——时间影响日志定位，负载关联进程排查，内存和磁盘互相印证，网络排障层层递进——你就已经超过了大多数只会“背命令”的运维新人。剩下的，就是多上几台真实服务器，多踩几个坑，把这些命令用成肌肉记忆。