1. 项目概述：为什么这100条命令不是“背诵清单”，而是运维肌肉记忆的起点

“Linux 运维实用 100 条命令”——这个标题在技术社区里出现频率极高，但绝大多数人点开后只做了两件事：复制粘贴到备忘录，或者扫一眼就关掉。我带过十几期运维新人训练营，也给某高校的系统工程课做过三年助教，最常听到的反馈是：“命令记了一堆，一上生产环境还是手抖”“ls -la和ls -al看起来一样，为啥有时候权限显示顺序不一样？”“ps aux里那个STAT列里的S、R、Z到底啥意思？查文档像读天书。”这些问题背后，根本不是记忆力问题，而是对命令的设计哲学、参数组合逻辑、输出字段语义、以及真实故障场景映射关系完全脱节。这100条命令，从来就不是为“考试默写”而生的，它们是Linux内核、Shell解释器、文件系统、进程调度器、网络栈之间长期磨合出的一套最小交互协议。比如df -h，表面看只是“看磁盘空间”，但它的-h参数触发的是human_readable格式化函数，这个函数内部要调用sysconf(_SC_PAGESIZE)获取系统页大小，再根据数值自动选择KB/MB/GB单位；而df -i则绕过块设备统计，直接读取/proc/partitions和ext4_super_block结构体里的inode总数与已用数——同一命令，两个参数，底层走的是两条完全不同的内核路径。再比如netstat -tuln，四个参数缺一不可：-t（TCP）、-u（UDP）、-l（监听态）、-n（不解析DNS），少一个就可能漏掉关键服务，或者让命令卡在DNS超时上。我曾在某次线上数据库连接池耗尽的排查中，因为没加-n，netstat卡了17秒才返回，而故障窗口只有32秒。所以，这篇内容不叫“100条命令速查表”，它是一份命令级故障推演手册：每一条都拆解到系统调用层面，标注真实生产环境中的典型误用、参数陷阱、输出字段解读技巧，以及三个以上必须搭配使用的关联命令。适合两类人：一是刚从虚拟机里跑通hello world的新人，需要知道“为什么chmod 777是危险操作”背后的umask继承机制；二是有三年经验、能写Ansible Playbook但遇到strace输出一堆epoll_wait就发懵的老手，需要补上从Shell命令到内核事件循环的完整链路。你不需要记住全部100条，但只要吃透其中20条的底层逻辑，处理80%的日常告警就不再依赖Google或同事救场。

2. 命令设计逻辑与选型依据：为什么是这100条，而不是101条或99条？

2.1 核心筛选原则：覆盖“运维生命周期”的四个黄金阶段

这100条命令不是随机凑数，而是严格按运维人员每天实际工作流切割的。我用某公司过去两年的2376条工单日志做了聚类分析，发现所有操作可归为四大阶段：环境确认 → 问题定位 → 临时修复 → 持久加固。每个阶段分配25条命令，形成闭环。比如“环境确认”阶段，绝不是简单执行uname -a就完事。uname -r只显示内核版本号（如5.4.0-105-generic），但真正决定驱动兼容性的是uname -v输出的编译时间戳和CONFIG_MODULE_SIG等内核配置标志；而lscpu | grep "CPU\(s\)"看到的逻辑CPU数，必须和cat /sys/devices/system/cpu/online比对——后者才是当前热插拔生效的CPU范围。如果只信lscpu，在云主机缩容后可能误判资源瓶颈。再比如“问题定位”阶段，top是入门必学，但它默认刷新间隔是3秒，而很多瞬时CPU尖刺（如GC停顿）持续不到1秒，就会被平滑掉。这时候必须用pidstat -u 1 5（每秒采样1次，共5次），它的底层是/proc/[pid]/stat的毫秒级时间戳解析，比top的/proc/stat聚合统计精细得多。我们筛掉了一些看似“高大上”但实际低频的命令，比如perf。它功能强大，但学习成本过高，且80%的性能问题用vmstat 1+iostat -x 1+sar -n DEV 1三板斧就能定位。相反，像ss -tuln这种netstat的现代替代品，虽然语法相似，但ss直接读取/proc/net/下的内核socket哈希表，而netstat要遍历所有/proc/[pid]/fd/符号链接再解析，前者在万级连接时耗时0.2秒，后者可能超10秒——这就是为什么它必须入选。

2.2 参数组合的“最小完备集”：拒绝“全参数罗列”，专注高频致命组合

很多教程把find命令的几十个参数全列出来，结果新人一写find /var/log -name "*.log" -mtime +7 -delete就删光了日志。我们只收“经过血泪验证”的组合。以find为例，只保留三条：

1. find /path -type f -size +100M -exec ls -lh {} \;—— 定位大文件，-exec ls -lh比-print多显示人类可读大小，避免误删；
2. find /path -name "*.tmp" -mmin -30 -delete—— 清理30分钟内修改的临时文件，-mmin比-mtime精确到分钟，防止误伤旧备份；
3. find /path -user nobody -perm -4000 -ls—— 查找被滥用的SUID程序，-perm -4000匹配包含SUID位的文件，-ls输出详细权限，这是提权漏洞自查的核心。
   注意第三条的-perm -4000：很多人写成-perm 4000，后者要求权限恰好等于4000（即-r-s--- ---），而-表示“至少包含”，能匹配-r-sr-xr-x（4755）等更常见的情况。这个细节在某次安全审计中帮我们发现了被植入的恶意/usr/bin/python副本。同理，grep只收-E（扩展正则）、-o（仅输出匹配部分）、-A3 -B2（上下文行）这三个参数组合，因为-E支持+、?等元字符，-o配合-A3能精准提取日志中的错误堆栈片段，比| head -n 100 | grep "ERROR"可靠十倍。

2.3 输出字段的“生存指南”：读懂命令返回值，比记住命令本身更重要

运维不是“执行命令”，而是“解读输出”。比如free -h，新手只看available列，但老手会同时盯住buff/cache和available的差值。当buff/cache高达12G而available只有2G时，说明内核缓存占用了大量内存，但available是内核预估的“可立即回收”量，它低于free列（真正空闲）是正常的。但如果available持续低于free的1/3，就要查/proc/meminfo里的SReclaimable（可回收slab缓存）是否异常——这往往是内核模块内存泄漏的征兆。再比如iostat -x 1，%util列常被误解为“磁盘忙”，其实它是io_queue_time / interval的比值，当队列深度很大时，%util可能100%但IOPS很低，此时要看await（平均IO等待时间）和svctm（平均服务时间）的比值：如果await是svctm的5倍以上，说明IO请求在队列里积压严重，该换SSD了。我们为每条命令的TOP3输出字段配了“生存口诀”：df看Use%但必须核对Inodes%（inode耗尽比空间耗尽更致命）；ps aux看%CPU但更要盯RSS（常驻内存）和VSZ（虚拟内存）的比值，比值>3说明进程有内存碎片；ss -s看total但重点查TCP: time_wait数量，超过65535就可能触发端口耗尽。这些口诀不是凭空而来，而是从某次电商大促期间订单服务雪崩的复盘中提炼的——当时time_wait堆积到12万，但监控只告警%CPU，导致故障延迟47分钟才发现。

3. 核心命令深度解析与实操现场：从“会用”到“懂为什么”的跃迁

3.1 文件系统与磁盘管理：df、du、lsof的三角互证法

磁盘空间告警是最高频的工单类型，但90%的“空间不足”其实是假象。真正的根因往往藏在df、du、lsof三者的输出差异里。先看一个经典案例：df -h显示/var分区使用率98%，但du -sh /var/* | sort -hr | head -5加起来才20G。这时必须启动三角互证：
第一步，用lsof +L1 /var查被删除但仍被进程占用的文件（+L1参数专为此设计）。某次我们发现/var/log/nginx/access.log被rm删除，但Nginx主进程仍持有其文件描述符，lsof输出类似：

nginx 12345 root 1w REG 253,1 18454927360 123456 /var/log/nginx/access.log (deleted)

第二步，验证du为何没统计：du只扫描目录树，而lsof读取/proc/12345/fd/1的符号链接，指向/var/log/nginx/access.log (deleted)。这个(deleted)后缀就是关键线索。
第三步，临时释放空间：kill -USR1 12345（Nginx重载日志，自动关闭旧fd并打开新文件），或直接echo > /proc/12345/fd/1清空文件内容（不中断进程）。

提示：lsof +L1比lsof | grep deleted快10倍，因为它直接调用getdents()系统调用扫描/proc/[pid]/fd/，而非全文本过滤。

另一个陷阱是XFS文件系统的df精度。XFS默认启用allocsize=64k，小文件（<64K）会按64K对齐分配，df显示的空间是按块计算的，而du按实际字节数。当du总和比df可用空间小10%以上时，大概率是XFS的小文件膨胀。解决方案是xfs_info /dev/sdb1查allocsize，再用xfs_db -r -c "freesp -h"看空闲空间碎片率。如果碎片率>30%，需xfs_fsr在线整理。这些细节，没有一次真实的磁盘填满事故，是永远学不会的。

3.2 进程与资源监控：ps、top、pidstat的协同作战

ps aux的输出字段常被当成“固定格式”，其实每个字段都是内核task_struct结构体的直译。比如STAT列的S（Sleeping）、R（Running）、Z（Zombie）背后，是进程的state字段值：TASK_INTERRUPTIBLE（2）、TASK_RUNNING（0）、EXIT_ZOMBIE（4）。但ps为了可读性做了简化，<表示高优先级（nice < 0），N表示低优先级（nice > 0），而L表示有页面锁定（mlock()），这往往是内存密集型应用的特征。某次数据库响应慢，ps看到postgres进程STAT是SL，RSS高达8G，但%MEM只有15%——RSS是常驻物理内存，%MEM是占总内存比例，两者矛盾说明系统总内存远大于53G（8G/0.15），而L标志提示它锁定了关键页，不能被swap。这时必须用cat /proc/12345/status | grep -E "VmRSS|MMUPageSize"确认是否启用了HugePages。

top的交互模式常被忽略。按1键显示所有CPU核心负载（而非聚合值），按H切换线程视图，按c显示完整命令路径（/usr/bin/python3 /opt/app/main.py而非python3）。最实用的是f键自定义字段：勾选PPID（父进程ID）和WCHAN（进程等待的内核函数），当看到大量进程WCHAN是ep_poll时，说明卡在epoll事件循环，该查应用层的异步IO配置了。

pidstat则是top的精密手术刀。pidstat -d 1每秒输出每个进程的IO读写字节数，-d参数直接读取/proc/[pid]/io的read_bytes和write_bytes字段，比iotop更轻量。某次存储IO飙升，iostat显示%util100%，但pidstat -d 1发现只有rsync进程在写，其他进程IO为0——立刻定位到是备份脚本未加ionice限速，而非数据库问题。

3.3 网络诊断：ss、tcpdump、nc的分层穿透术

网络问题必须分层诊断：L3（IP）、L4（TCP/UDP）、L7（应用）。ss -tuln是L4层的“CT扫描”，-t（TCP）、-u（UDP）、-l（监听）、-n（数字端口）四参数缺一不可。ss -tuln | grep ":80"比netstat -tuln | grep ":80"快5倍，因为ss用getsockopt()直接读内核socket表，而netstat要遍历/proc/[pid]/fd/。但ss看不到L7层内容，这时要用tcpdump抓包。新手常犯的错是tcpdump port 80，这会捕获所有80端口流量（包括出站请求），而故障通常在入站响应。正确姿势是tcpdump -i eth0 'tcp and dst port 80 and tcp[tcpflags] & tcp-syn != 0'，用BPF过滤器只抓SYN包，再结合-w /tmp/syn.pcap保存，用Wireshark分析三次握手时长。

nc（netcat）是L7层的“探针”。nc -zv example.com 443检查端口连通性，但-z（zero-I/O mode）不发送数据，只能验证TCP层；要验证HTTPS，得用echo -e "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n" | nc example.com 443，手动构造HTTP头。某次API网关超时，nc -zv显示443端口通，但手动HTTP请求卡在HTTP/1.1 100 Continue——立刻定位到是网关的Expect: 100-continue配置问题，而非网络层故障。

注意：tcpdump抓包时务必加-s 0（snaplen 0），否则默认只截取前68字节，HTTP头里的Content-Length可能被截断，导致分析误判。

3.4 用户与权限管理：id、getent、auditctl的权限溯源链

权限问题最难复现，因为涉及用户、组、sudo规则、PAM模块四层叠加。id命令不只是显示UID/GID，id -Gn列出所有组名（含通过/etc/group继承的），id -un显示登录用户名（非$USER环境变量）。某次sudo systemctl restart nginx失败，id显示用户在wheel组，但sudo -l报user is not allowed to run sudo。追查发现/etc/sudoers里%wheel ALL=(ALL) NOPASSWD: /bin/systemctl被注释了，而/etc/sudoers.d/下有个nginx-admin文件，内容是%nginx ALL=(ALL) /bin/systemctl restart nginx——用户不在nginx组，getent group nginx才查到组成员。getent比cat /etc/group可靠，因为它还查询LDAP/NIS等外部源。

更深层的权限审计要用auditctl。auditctl -a always,exit -F arch=b64 -S execve -F uid!=0监控所有非root用户的程序执行，日志写入/var/log/audit/audit.log。某次安全扫描发现异常curl调用，ausearch -m execve -ui 1001 | aureport -f -i精准定位到是某个Python脚本调用的subprocess.Popen(['curl', ...])，而非用户手动执行。这种溯源能力，是history命令永远做不到的。

4. 实战排障流程与命令组合技：把100条命令变成你的“运维瑞士军刀”

4.1 高频故障场景：CPU 100%的五层归因法

CPU 100%告警后，不要急着kill -9。按以下五层顺序排查，每层用1-2条命令：
L1 应用层：top -b -n 1 | head -20看TOP进程，-b批处理模式避免交互。如果java进程CPU高，jstack 12345 > /tmp/jstack.out抓线程快照，grep "RUNNABLE" /tmp/jstack.out | wc -l统计运行中线程数，超200说明有死循环。
L2 JVM/运行时层：jstat -gc 12345 1000 3（每秒采样3次），看YGCT（Young GC时间）是否突增。如果YGCT从0.1s跳到5s，说明年轻代频繁GC，该查-Xmn参数。
L3 内核调度层：pidstat -w 1 3看cswch/s（每秒上下文切换次数）。正常值<1000，若>5000，说明进程在频繁抢锁，用perf top -p 12345看热点函数。
L4 中断层：cat /proc/interrupts | awk '{print $1,$2,$3}' | sort -k3nr | head -5查最高频中断源。如果IO-APIC-fasteoi下的eth0排第一，说明网卡中断风暴，该调ethtool -C eth0 rx off tx off关闭中断合并。
L5 硬件层：dmesg -T | tail -20看是否有Hardware Error或Machine check events。某次CPU 100%持续1小时，dmesg发现EDAC MC0: UE（不可纠正内存错误），更换内存条后解决。
这五层命令组合，覆盖了从代码bug到硬件故障的全链路，比单靠top盲目杀进程靠谱得多。

4.2 磁盘IO瓶颈：iostat、iotop、blktrace的渐进式深挖

iostat -x 1是IO诊断的第一道门，但%util接近100%时，必须用iotop看进程级IO。iotop -o只显示有IO活动的进程，-P显示IO优先级。如果看到mysqld的IO>列持续>10MB/s，但iostat的r/s（读请求数）很低，说明是大块顺序读，该优化MySQL的innodb_read_io_threads。

更深一层用blktrace。blktrace -d /dev/sda -o - | blkparse -i -实时解析块层事件。Q（Queue）、G（Get request）、M（Merge）、I（Issue）事件的时间戳差，能精确定位IO延迟在哪一环。某次存储响应慢，blktrace显示Q->G平均耗时0.5ms（正常），但G->M达15ms——说明IO请求在队列里等待合并，根源是存储控制器的队列深度设置过小，调整/sys/block/sda/device/queue_depth从32升到128后解决。

实操心得：blktrace数据量极大，生产环境慎用。建议先iostat -x 1确认问题存在，再iotop -o定位进程，最后blktrace只采样30秒。blkparse的-f "%5T.%9t %5p %2a %3d %8s %8n %12S %12C"格式能输出毫秒级时间戳、进程PID、操作类型（R/W）、扇区号、字节数、起始扇区、CPU号，比默认输出信息量多3倍。

4.3 网络连接耗尽：ss、netstat、/proc/sys/net的联动分析

TIME_WAIT连接过多是Web服务的常见病。ss -s看TCP: time_wait数量，超65535（端口范围）就危险。但ss -tan state time-wait sport = :80 | wc -l能精确统计80端口的TIME_WAIT数。

根因在内核参数：net.ipv4.tcp_tw_reuse（允许TIME_WAIT socket重用）和net.ipv4.tcp_fin_timeout（FIN超时时间）。某次API服务连接耗尽，ss -s显示time_wait8万，sysctl net.ipv4.tcp_tw_reuse返回0。启用sysctl -w net.ipv4.tcp_tw_reuse=1后，ss -s立刻降到2万。但要注意：tcp_tw_reuse只对客户端有效，服务器端必须确保net.ipv4.tcp_timestamps=1（默认开启），否则会拒绝重用。

更隐蔽的是/proc/sys/net/core/somaxconn（全连接队列长度）和/proc/sys/net/core/netdev_max_backlog（网卡软中断队列）。当ss -s显示orphan（无家可归）连接数突增，说明SYN队列溢出，该调大somaxconn。某次大促，ss -s的orphan从0跳到5000，netstat -s | grep "listen overflows"确认溢出，将somaxconn从128调至65535后解决。

4.4 权限与安全事件：ausearch、aureport、lsattr的证据链构建

安全事件必须留痕。auditctl -w /etc/passwd -p wa -k passwd_change监控/etc/passwd的写和属性修改，-k打标签便于检索。事件发生后，ausearch -k passwd_change | aureport -f -i生成可读报告，包含时间、用户、进程、文件路径。

但auditd日志可能被删，lsattr /etc/passwd是最后一道防线。lsattr读取ext4的i_flags字段，----e-------e---中的e表示extents格式（正常），i表示不可修改（immutable），a表示只能追加。某次/etc/shadow被篡改，ausearch日志已清空，但lsattr /etc/shadow显示----i--------e---，说明攻击者用chattr +i锁定了文件，防止恢复——这个i标志就是关键证据，用chattr -i /etc/shadow才能解锁。

注意：lsattr对XFS文件系统无效，XFS用xfs_io -c "chattr +i" /etc/passwd，查用xfs_io -c "lsattr" /etc/passwd。不同文件系统命令不同，这是新人常踩的坑。

5. 常见问题与避坑指南：那些没人告诉你的“命令潜规则”

5.1grep的正则陷阱：.、*、^在不同模式下的行为差异

grep的-E（扩展正则）和默认基础正则，对元字符的处理完全不同。基础正则中，.匹配任意字符，*是前一个字符的重复（如a*匹配""、"a"、"aa"），而^和$只在行首/行尾。但在-E模式下，+、?、|、()都生效，*的含义不变，但.*能匹配任意长度字符串。最致命的是grep "^root"：在基础模式下，^是字面量，会匹配以^root开头的行；在-E模式下，^才是行首锚点。某次写监控脚本，grep "^root" /etc/passwd在测试机（默认grep）返回空，在生产机（alias grep='grep -E'）却返回root用户——因为生产机的-E让^生效了。解决方案：显式指定grep -E "^root"或grep -F "^root"（固定字符串模式），绝不依赖别名。

5.2find的-exec与\;、+的性能鸿沟

find /var/log -name "*.log" -exec rm {} \;和find /var/log -name "*.log" -exec rm {} +的区别，是运维生死线。\;对每个文件执行一次rm，1000个文件就fork/exec 1000次；+把文件列表拼成rm file1 file2 ... fileN，N由getconf ARG_MAX决定（通常2M），1000个文件可能只需2-3次调用。某次清理日志，前者耗时47秒，后者2.3秒。更糟的是，\;在rm失败时会停止，而+会继续处理剩余文件。+还有个隐藏优势：find会自动按ARG_MAX分组，避免参数过长报错。

5.3awk的字段分割：$0、$1、NF、NR的真实含义与误用

awk '{print $1}'看似简单，但$1是第一个字段，字段分隔符默认是空白（空格、制表符、换行），而$0是整行。NF是字段数，NR是记录号（行号）。误用案例：ps aux | awk '{print $11}'想取COMMAND列，但ps aux的COMMAND列含空格，$11可能只是命令名的一部分。正确做法是ps aux | awk '{$1=$2=$3=$4=$5=$6=$7=$8=$9=$10=""; print $0}' | sed 's/^ *//'，先清空前10列，再打印剩余部分。或者用ps -eo pid,comm,args指定输出格式，comm是命令名，args是完整参数，更可靠。

5.4systemctl的“假死”状态：active (exited)与inactive (dead)的本质区别

systemctl status nginx显示active (exited)，很多人以为服务挂了，其实是Type=oneshot的服务（如/usr/lib/systemd/system/rc-local.service）正常退出后的状态。active (exited)表示服务单元已成功执行完毕，而inactive (dead)表示从未启动或已终止。判断服务是否真在运行，要看Main PID是否为-，以及CGroup下是否有子进程。systemctl show nginx | grep -E "ActiveState|SubState|MainPID"比status更准确。

5.5curl的SSL证书验证：-k、--cacert、--capath的安全边界

curl -k https://api.example.com跳过证书验证，但-k（--insecure）不仅跳过证书链验证，还跳过域名匹配（SNI）。生产环境必须用curl --cacert /etc/ssl/certs/ca-bundle.crt https://api.example.com，指定CA证书包。--capath指定证书目录时，目录必须用c_rehash生成符号链接，否则curl找不到证书。某次API调用失败，curl -v显示SSL certificate problem: unable to get local issuer certificate，查--capath目录发现缺少c_rehash，执行c_rehash /etc/ssl/certs后解决。

6. 进阶技巧与效率提升：让100条命令成为你的“条件反射”

6.1 命令别名的黄金法则：只封装“安全、高频、易错”的组合

别名不是越短越好。alias ll='ls -alF'安全，但alias rm='rm -i'危险——在脚本中rm -i会阻塞，且-i对rm -rf无效。我们只封装三类：

• 安全加固型：alias df='df -h -x tmpfs -x devtmpfs'（排除内存文件系统干扰）
• 高频纠错型：alias grep='grep --color=auto'（高亮关键词，避免漏看）
• 易错补全型：alias docker-ps='docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Ports}}"（强制表格格式，避免列错位）
  所有别名必须加-h、-i等安全参数，且用command前缀避免递归，如alias ls='command ls -F'。

6.2 Shell函数的实战价值：用5行代码解决find的痛点

find的-delete不安全，-exec rm太慢。写个Shell函数：

safe_rm() { local files=() while IFS= read -r -d '' file; do files+=("$file") done < <(find "$1" -type f -name "$2" -print0 2>/dev/null) if [ ${#files[@]} -eq 0 ]; then echo "No files found" return 1 fi echo "Found ${#files[@]} files:" printf '%s\n' "${files[@]}" | head -20 read -p "Delete all? (y/N) " -n 1 -r echo if [[ $REPLY =~ ^[yY]$ ]]; then printf '%s\0' "${files[@]}" | xargs -0 rm -f echo "Deleted ${#files[@]} files" else echo "Aborted" fi }

用法：safe_rm /tmp "*.log"，先预览再确认，支持空格文件名（-print0+xargs -0），比任何find -delete都安全。

6.3 历史命令的深度挖掘：history的!、^、&魔法

history不仅是回溯，更是生产力工具。!!执行上一条，!$取上条命令最后一个参数，!^取第一个参数。但最强大的是^old^new^：ls /old/path执行后，^old^new^自动执行ls /new/path。&用于重复上条命令的参数：cp file1.txt /backup/后，mv file2.txt /backup/可简写为mv !$（!$取/backup/）。history -n加载新历史，history -s "command"添加命令到历史——这些技巧让重复操作快3倍。

6.4 日志分析的“三剑客”升级：awk、sed、jq的现代组合

纯文本日志用awk '/ERROR/ {print $1,$4,$NF}'，但JSON日志必须用jq。cat app.log | jq -r 'select(.level=="ERROR") | "\(.timestamp) \(.service) \(.message)"'。jq的-r输出原始字符串，select()做条件过滤，.field取字段。jq