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四个参数缺一不可-tTCP、-uUDP、-l监听态、-n不解析DNS少一个就可能漏掉关键服务或者让命令卡在DNS超时上。我曾在某次线上数据库连接池耗尽的排查中因为没加-nnetstat卡了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 1iostat -x 1sar -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为例只保留三条find /path -type f -size 100M -exec ls -lh {} \;—— 定位大文件-exec ls -lh比-print多显示人类可读大小避免误删find /path -name *.tmp -mmin -30 -delete—— 清理30分钟内修改的临时文件-mmin比-mtime精确到分钟防止误伤旧备份find /path -user nobody -perm -4000 -ls—— 查找被滥用的SUID程序-perm -4000匹配包含SUID位的文件-ls输出详细权限这是提权漏洞自查的核心。注意第三条的-perm -4000很多人写成-perm 4000后者要求权限恰好等于4000即-r-s--- ---而-表示“至少包含”能匹配-r-sr-xr-x4755等更常见的情况。这个细节在某次安全审计中帮我们发现了被植入的恶意/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 12345Nginx重载日志自动关闭旧fd并打开新文件或直接echo /proc/12345/fd/1清空文件内容不中断进程。提示lsof L1比lsof | grep deleted快10倍因为它直接调用getdents()系统调用扫描/proc/[pid]/fd/而非全文本过滤。另一个陷阱是XFS文件系统的df精度。XFS默认启用allocsize64k小文件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列的SSleeping、RRunning、ZZombie背后是进程的state字段值TASK_INTERRUPTIBLE2、TASK_RUNNING0、EXIT_ZOMBIE4。但ps为了可读性做了简化表示高优先级nice 0N表示低优先级nice 0而L表示有页面锁定mlock()这往往是内存密集型应用的特征。某次数据库响应慢ps看到postgres进程STAT是SLRSS高达8G但%MEM只有15%——RSS是常驻物理内存%MEM是占总内存比例两者矛盾说明系统总内存远大于53G8G/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的分层穿透术网络问题必须分层诊断L3IP、L4TCP/UDP、L7应用。ss -tuln是L4层的“CT扫描”-tTCP、-uUDP、-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分析三次握手时长。ncnetcat是L7层的“探针”。nc -zv example.com 443检查端口连通性但-zzero-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 0snaplen 0否则默认只截取前68字节HTTP头里的Content-Length可能被截断导致分析误判。3.4 用户与权限管理id、getent、auditctl的权限溯源链权限问题最难复现因为涉及用户、组、sudo规则、PAM模块四层叠加。id命令不只是显示UID/GIDid -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 archb64 -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次看YGCTYoung 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 -实时解析块层事件。QQueue、GGet request、MMerge、IIssue事件的时间戳差能精确定位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_timeoutFIN超时时间。某次API服务连接耗尽ss -s显示time_wait8万sysctl net.ipv4.tcp_tw_reuse返回0。启用sysctl -w net.ipv4.tcp_tw_reuse1后ss -s立刻降到2万。但要注意tcp_tw_reuse只对客户端有效服务器端必须确保net.ipv4.tcp_timestamps1默认开启否则会拒绝重用。更隐蔽的是/proc/sys/net/core/somaxconn全连接队列长度和/proc/sys/net/core/netdev_max_backlog网卡软中断队列。当ss -s显示orphan无家可归连接数突增说明SYN队列溢出该调大somaxconn。某次大促ss -s的orphan从0跳到5000netstat -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表示不可修改immutablea表示只能追加。某次/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 grepgrep -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 {} 的区别是运维生死线。\;对每个文件执行一次rm1000个文件就fork/exec 1000次把文件列表拼成rm file1 file2 ... fileNN由getconf ARG_MAX决定通常2M1000个文件可能只需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)很多人以为服务挂了其实是Typeoneshot的服务如/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 llls -alF安全但alias rmrm -i危险——在脚本中rm -i会阻塞且-i对rm -rf无效。我们只封装三类安全加固型alias dfdf -h -x tmpfs -x devtmpfs排除内存文件系统干扰高频纠错型alias grepgrep --colorauto高亮关键词避免漏看易错补全型alias docker-psdocker ps --format table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Ports}}强制表格格式避免列错位所有别名必须加-h、-i等安全参数且用command前缀避免递归如alias lscommand 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先预览再确认支持空格文件名-print0xargs -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(.levelERROR) | \(.timestamp) \(.service) \(.message)。jq的-r输出原始字符串select()做条件过滤.field取字段。jq