开了两台服务器一台是CentOS一台是Ubuntu常年做线上部署和排查问题。用了几年之后最大的感受是Linux命令这东西光靠背没有用你得知道在什么场景下用它、为什么用它、用了之后能看到什么。刚带团队的时候我发现很多新人手里攥着一份“命令大全”但真到线上服务器出问题还是一头雾水——拿top看到load average高了不知道下一步看什么grep出来一堆日志不知道怎么过滤端口被占用了甚至不知道先敲哪条命令。这篇文章就是我实际工作里最常用、最踩坑、也最值得反复看的Linux命令梳理围绕“运维开发”这个真实场景来展开。不是我随手整理的速查表而是每条命令都配合了使用场景、排查思路、以及我自己踩过的坑。不管你是刚入行的运维新人还是写代码但偶尔要上服务器排查的后端开发或者是准备面试想补一下系统知识这篇文章应该都能让你少走点弯路。1. 先建立自己的命令地图运维开发到底该学哪些1.1 别按字母表背命令先分场景很多人学Linux命令的方式是拿着一份“Linux常用命令大全”从头看今天看了ls、cd、pwd明天看cp、mv、rm看着看着就忘了遇到问题还是想不到用哪条。我建议换一种方式按“场景”来组织命令而不是按“字母表”。所谓场景就是你实际干活的几种动作。拿我自己的日常工作来说无非就是这几类找文件、看日志、查进程、看性能、管服务、配权限、网络调试、写脚本。每类场景对应一小撮高频命令把这些“核心组合拳”练熟了已经能覆盖90%以上的日常运维和开发工作。比如找文件这个场景核心命令就三个find、locate、which。其中find最强大locate查得最快which用来确认命令路径。你不需要记几十个参数只要知道find能按名字、类型、时间、大小定位文件遇到问题再临时man find或find --help查一下就行。先有“地图”再补充细节记忆负担会小很多。1.2 从Windows迁移到Linux的三个快速对照团队里很多开发一开始是Windows环境刚上Linux服务器经常找不到北。其实不用慌大部分操作在两边是有对应关系的。我整理了一个高频对照表新人照着看半天就能上手基本操作Windows习惯Linux对照命令差异点dir / 文件夹文件列表ls、llll是ls -l的别名看权限和大小更直观notepad打开文件vi/vim、cat、lessvim是编辑cat/less只读查看任务管理器看进程top、ps auxtop动态刷新ps看快照ipconfig查网络ip addr、ifconfigifconfig在部分新系统需安装net-tools删除文件无回收站rm -rf特别注意删了真没了没有回收站复制/移动cp、mvmv跨文件系统可能变成“复制删除”这里我必须单独强调一下rm -rf。这是Linux新人最容易出的重大事故——在错误的目录上执行了rm -rf后果是整个目录没了而且没有Windows那种回收站兜底。我的习惯是生产服务器上给rm做一个alias改成rm -i删除前必须逐个确认高危操作前先echo $PWD看看当前路径再ls确认一下再删。别觉得麻烦真正出事的时候这几秒钟的确认就是你的保命符。2. 文件和文本处理日常干活的重头戏2.1 文件查找与定位find的高频实战写法find是我每天都要用到的命令尤其是排查问题的时候。按文件名找、按目录找、按时间找、按大小找每种需求都有对应的写法。我把高频用法列一下每一条都是我实际敲过的# 在当前目录下按名字找文件 find . -name *.log # 按名字找忽略大小写 find /opt -iname order*.jar # 按类型找只看目录或只看文件 find . -type d -name conf find . -type f -size 500M # 按修改时间找最近7天内改过的文件 find /app -mtime -7 -type f # 定位并直接执行操作比如批量删除3天前的临时文件 find /tmp -name *.tmp -mtime 3 -exec rm -f {} \;很多教程会告诉你find -mtime的用法但没说清楚7和-7的区别。这里我用自己的话解释一下-mtime -7是“最近7天以内被修改过”-mtime 7是“7天以前被修改过”。一字之差搜索结果天差地别。批量删除老文件这种操作我会先用不带-exec的版本把结果列出来眼睛确认一遍再决定要不要真正执行删除。2.2 日志分析的三个主力grep、awk、sed日志分析是运维开发绕不开的活线上出了问题第一件事就是去翻日志。而日志分析的三个核心工具就是grep、awk、sed。这三个工具的功能有重叠但各有侧重我一般这么用grep用来“筛行”。我想看报错、看关键字第一反应就是grep。高频参数如下# 直接在日志里搜关键字 grep ERROR app.log # 递归搜索整个目录看哪些文件里有目标关键字 grep -r NullPointerException /app/logs/ # 搜出关键字的同时显示前后3行上下文 grep -B 3 -A 3 ERROR app.log # 不命中关键字反向过滤 grep -v healthcheck app.log # 统计关键字出现次数 grep -c Exception app.log这里有个很实际的技巧线上日志文件巨大动辄几个GB直接grep ERROR会刷屏。我会先grep -c看看总量再配合tail或者grep加行数限制来捞取关键片段——先看“有没有”再决定“要不要拉出来看”。awk用来“取列”和“做统计”。日志每一行往往有固定格式比如时间、级别、线程名、消息内容用空格或制表符分割。这时awk是最顺手的工具# 打印每行第1列和第3列 awk {print $1, $3} app.log # 指定分隔符比如按逗号或竖线分割 awk -F| {print $2} data.txt # 统计某个字段出现的次数 awk {count[$1]} END {for (k in count) print k, count[k]} app.log # 按条件过滤行比如找响应时间超过500ms的记录 awk $NF 500 {print $0} access.log可能有人看到awk的语法会觉得头大其实可以先把它当成“按列切数据的工具”来用核心就是{print $1}这种形式。$NF代表“最后一个字段”$0代表“整行”。先把这两点记住awk就能解决工作中80%的字段截取需求。sed用来“改”和“删行”。它最擅长流式编辑虽然平时不会用它写业务代码但处理日志和配置特别好用# 把文件里所有的old替换成new打印到屏幕不改原文件 sed s/old/new/g file.txt # 真正原地修改危险操作建议先备份 sed -i s/127.0.0.1/0.0.0.0/g config.yaml # 删除第5行到第10行 sed 5,10d file.txt # 只打印第20行到第30行 sed -n 20,30p file.txt网上关于这三个工具的教程特别多但我建议你先掌握上面这些高频写法。我见过太多人花两星期去啃awk的全部语法最后工作里用到的就是那么一两个模式。先把“筛行、取列、改串”这三板斧玩熟比什么都强。2.3 查看文件内容的正确打开方式文件内容查看是新手最容易用错工具的地方。我见过有人在几GB的日志文件上直接cat结果终端直接卡死只看到屏幕哗哗滚动。正确的打开方式应该是场景正确工具原因看完整小文件cat文件不大直接输出没问题看大文件末尾最新内容tail -f实时跟踪新增日志看大文件开头head只看头部几行翻页浏览大文件less支持上下翻页、搜索看文件前几行确认格式head -20先看格式再决定怎么处理我工作中用得最多的是tail -f和less。tail -f是“官方推荐的日志跟踪姿势”线上服务只要用systemd管理日志输出到文件我排查问题第一件事就是tail -f盯着看新增内容。但这里有个经典坑日志文件如果按天切割你会看到程序写的是新的日志文件但tail -f还在盯旧文件什么新内容都不显示。原因是tail -f跟踪的是文件句柄不是文件名本身。解决方案是改用tail -F大写它会依照文件名重新打开文件tail -F app.log就一个大小写的区别让我不止一次从满头问号里解脱出来。还有一次更典型我在tail -f日志之后想同时过滤关键字想用管道tail -f app.log | grep ERROR结果grep有输出缓冲终端半天不刷新。后来改成tail -f app.log | grep --line-buffered ERROR实时性立刻好了。这种细节不去踩一遍坑是很难想起来的。3. 性能排查与进程管理线上问题定位的核心能力3.1 从top到ps找到CPU和内存的元凶线上服务出了问题最常见的表现就是CPU飙升、内存爆满、接口变慢。这时候第一步就是顶上去看top。很多人只会敲一个top然后盯着看其实top里有不少交互快捷键排查效率天差地别# 直接查看 top # 进入top后按P按CPU排序按M按内存排序 # 按1查看多核CPU使用率分布 # 按H切换线程视图看具体线程占用top的第一屏信息要会读。load average后面的三个数字分别是过去1分钟、5分钟、15分钟的平均负载如果1分钟的值明显高于15分钟说明系统负载正在快速上升这可能是一个刚刚开始的问题也可能是定时任务在跑如果三个值都很高说明系统已经持续繁忙很久了。配合top -H可以看线程级别的CPU占用这在排查Java、Python、Node这类服务时特别关键——你能直接看到是哪个具体线程在疯狂吃CPU。ps看的是进程快照和top的动态视图互补# 展示所有进程包含完整命令行 ps aux # 精确查找某个进程 ps aux | grep java # 只看PID这在脚本里特别有用 pgrep -f order-service这里我说一个自己的排查套路。遇到CPU高的问题我一般先top看是哪个进程的PID然后ps -p PID -o pid,ppid,%cpu,%mem,cmd看它的启动命令确认是不是我们要找的服务。如果是Java应用下一步就是top -H -p PID找到最耗CPU的线程ID把它转成十六进制再去jstack PID | grep -A 30 nid十六进制数看这个线程到底在执行什么代码。这套组合拳虽然用到了jstack但前面几步都是纯Linux命令思路是通用的。3.2 free、df与日志内存、磁盘排查的常见误区内存和磁盘排查是运维开发面试和工作中都爱考的场景。先说内存free -h是最常用的命令但新手很容易被里面的buffer/cache带偏free -h很多人看到used很高、available很低就觉得内存不够了。其实Linux内核会把空闲内存尽可能用作文件缓存buffer/cache这部分内存在某个应用申请大内存时实际上是可以释放的所以判断内存是否紧张最重要的是看available这一列而不是简单看used。我在公司内部给新人做分享时经常强调一句话used高不代表内存不够available低才是真的不够。磁盘这块df -h和du -sh是两把尺子但量的是完全不同的东西。# 看整个磁盘空间使用情况 df -h # 看某个目录总共占用 du -sh /app # 看某个目录下各子目录的大小定位占空间的“大户” du -h --max-depth1 /app | sort -rhdf量的是文件系统的使用量du量的是目录的实际占用。线上经常出现一个问题df -h显示磁盘满了但du -sh看所有大目录加起来却对不上。这种情况十有八九是有人删了文件但那个文件还被某个进程占用了没有真正释放。这个场景我已经踩过太多次后面会单独写一节来演示怎么排查。还有一个很容易忽略的坑df -h看的是块使用率但你可能遇到一个更隐蔽的“满”——inode满了。df -i可以看inode使用情况如果inode满了即使磁盘还有空间你也无法创建任何新文件、新目录。这种情况常见于某目录下塞了上百万个超小的文件。所以遇到“文件写不进去”的问题别光看df -h顺手敲一下df -i能省很多排查时间。3.3 端口与网络连接排查ss、lsof与curl端口被占用、网络超时、服务连不上这类网络问题在运维开发日常里太常见了。以前大家习惯用netstat但现在很多新装的系统里已经没有netstat了我更推荐直接用ss# 查看某个端口是否被监听 ss -tlnp | grep 8080 # 查看所有监听端口 ss -tln # 查看tcp连接状态统计比如SYN_SENT、TIME_WAIT多不多 ss -sss -tlnp里的-p会显示监听端口的进程信息这一项用途极大。遇到过“端口被占用”的问题一条命令就能把占用进程的PID和名字带出来不用再猜是谁干的。另一个高频命令是lsof它的功能比ss更丰富一些# 查看某个文件被哪个进程打开 lsof /var/log/app.log # 查看某个端口被哪个进程占用 lsof -i :8080 # 列出所有打开的文件这个配合排查文件句柄泄漏特别有用 lsof -p PID我印象最深刻的一次排查服务突然报“too many open files”当时怎么都查不到原因。后来用lsof -p PID | wc -l一数发现那个进程打开的文件句柄数上万再往下细看一堆socket没有正常关闭。那之后我就养成了一个习惯遇到连接数异常、文件句柄泄漏类问题先查lsof比空想快得多。网络连通性排查我常用的命令组合是ping、telnet、curl。ping告诉我们主机通不通telnet ip port告诉我们端口通不通curl则可以直接发HTTP请求测试接口。这里要提醒一下新装的容器镜像里经常没有telnet可以改用nc -vz ip port效果类似# 测端口连通性 nc -vz 192.168.1.100 3306 # 如果nc也没有用curl curl -v telnet://192.168.1.100:3306curl本身也是个强大的调试工具我平时查接口返回、看响应头、看请求耗时都用它# 只看响应头 curl -I https://example.com # 限制超时时间防止命令挂死 curl -m 5 https://example.com # 输出请求耗时明细 curl -w 连接耗时:%{time_connect} 总耗时:%{time_total}\n -o /dev/null -s https://example.com4. 服务管理与自动化从手动操作走向效率工具4.1 systemctl与journalctl现代Linux服务管理现在主流发行版都使用systemd来管理服务systemctl就是和它打交道的核心命令。很多老教程还在讲service xxx start/stop但这些命令在很多系统上只是systemctl的转发器所以我建议直接学systemctl# 启动服务 systemctl start nginx # 停止服务 systemctl stop nginx # 重启服务 systemctl restart nginx # 设置开机自启 systemctl enable nginx # 查看服务状态 systemctl status nginxsystemctl status这命令是排查问题的利器它会一次性显示服务的运行状态、主进程PID、最近日志以及常见的错误提示。我见过不少新人问“我的服务怎么起不来”我都会先让他跑一下systemctl status 服务名把输出贴出来再看下一步这个习惯能帮你省掉大量猜测时间。和systemd配套的日志工具是journalctl这是查看服务日志的第一入口# 查看某个服务的全部日志 journalctl -u nginx # 实时跟踪某个服务的日志 journalctl -u nginx -f # 查看最近10条 journalctl -u nginx -n 10 # 查看某个时间段 journalctl -u nginx --since 2024-12-01 10:00:00 --until 2024-12-01 11:00:00 # 查看错误级别以上的日志 journalctl -u nginx -p err我自己的工作习惯是服务起不来的问题先用systemctl status看状态再用journalctl看最近日志基本十有八九能找到原因。有一种常见情况是服务启动时依赖的配置目录不存在或者权限不对日志里会有明确的Permission denied或No such file or directory提示读完日志再去排查配置思路就非常清晰。4.2 权限、用户与定时任务权限问题是Linux新手最容易绕晕的领域。最基本的chmod和chown我要画一下重点# 修改文件权限r4w2x1 chmod 755 script.sh chmod x script.sh # 修改文件所有者 chown root:root /app/config.yaml # 递归修改目录权限 chown -R deploy:deploy /app/data权限数字的算法其实很简单r读是4w写是2x执行是1三个数相加得到一个权限值。755的意思是所有者可读可写可执行421组和其他人可读可执行41。我这里强烈建议一条最佳实践部署应用不用root用户而是单独创建deploy用户然后把应用目录chown给deploy。这样即使服务被入侵攻击者拿到的也不是root权限能少很多事。用户管理的命令要记的其实不多最常碰到的就是造账号、改密码、加sudo权限# 创建用户 useradd -m deploy # 设置密码 passwd deploy # 加入sudo组CentOS是wheel组Ubuntu是sudo组 usermod -aG wheel deploy # 删除用户 userdel -r deploy定时任务常用crontab。我平时排查问题看到“半夜突然CPU高”的诡异现象第一反应就是去看是不是有定时任务在跑# 查看当前用户的定时任务 crontab -l # 编辑定时任务 crontab -e # 每分钟执行一次 * * * * * /opt/scripts/check_health.sh # 每天凌晨3点执行 0 3 * * * /opt/scripts/backup.shcrontab的五段格式分别是分、时、日、月、星期这个格式如果你理解成“每天哪个时间点执行”上手会更快。需要特别注意的是crontab环境变量和登录环境不一样很多脚本在命令行跑得好好的放进crontab就出错很可能是PATH不对。我自己会习惯在脚本开头写清楚#!/bin/bash和PATH或者在crontab里直接写命令全路径。4.3 shell脚本的几个好习惯运维开发免不了写shell脚本批量部署、日志清理、数据备份都靠它。但脚本质量参差不齐我提几条自己写脚本时坚持的原则第一脚本开头固定两行#!/bin/bash set -euxo pipefailset -e表示一旦某条命令出错就立即退出set -u表示变量未定义就直接报错set -x会打印每一条执行的命令便于调试set -o pipefail可以让管道中任一环节报错导致整条管道返回失败。这一行是血泪教训换来的——不加的话脚本中间某一步静默失败了后面的流程还在“若无其事”往下跑最后结果完全不对排查起来特别痛苦。第二变量一定要加引号# 错误写法 if [ $name root ]; then # 正确写法 if [ $name root ]; then不加引号时如果$name是空值或者包含空格条件判断会直接报错。这个习惯在写脚本时一定要养成它引发的坑特别隐蔽。第三善用“防呆”参数# 拷贝时提示覆盖 cp -i src dest # 交互式删除 rm -i file脚本里跑批量删除、批量拷贝时如果操作对象特别关键我的做法是先打印、后执行必要时加上确认步骤。运维工作做久了你会明白脚本的功能强大大家都喜欢但脚本造成的“事故”往往更可怕。5. 高频场景实录运维开发会遇到的真实问题5.1 日志刷不出来与日志切割有一次线上Java服务访问量突然变大我想实时盯着日志看有没有异常。敲了tail -f app.log等了几分钟屏幕上什么都没动但明明服务在跑、接口在返回。第一反应是服务是不是把日志写到别处去了。后来我意识到这个服务的日志是通过logrotate每天切割的。最近一次切割发生在凌晨旧日志文件被改名成app.log-20241201并新建立了app.log。如果我在切割前就开始tail -f盯的是旧文件句柄而切割后新内容只会写入app.log这期间新日志自然一条都看不到。于是我把命令换成了tail -F app.log问题立刻解决。类似这样的“日志不动了”的问题还可能发生在管道缓冲场景tail -f app.log | grep ERROR --line-buffered不加--line-buffered时grep会启用块缓冲输出要攒满一个块通常是4KB才会打印给人的感觉就像卡死了一样。虽然加了这个参数后性能会有轻微下降但在实时跟踪的场景里实时性远比那点性能损失重要。5.2 磁盘没满却写不进文件那是我印象特别深的一次同事反馈某台服务器上写入文件报错提示“No space left on device”。我先跑了df -h结果吓一跳——磁盘明明有40%的空闲空间。第一反应是是不是挂载点看错了用df -h /app确认应用目录所在分区的确还有空间这就更奇怪了。再跑一下df -i才发现根因是inode已经用满了。df -i显示分区inode使用率100%任何新建文件的操作都会失败。定位到这个根因之后我顺着目录往下查发现是某个服务把大量小文件写进了一个临时目录一个几GB的目录里堆了几百万个几KB的文件把inode吃完了。找到问题后清理掉过期临时文件再创建文件就恢复正常了。这个案例给我的经验就是看到“No space left on device”不要只查磁盘空间一定要把df -h和df -i都跑一下。另外文件系统预留的inode数量在格式化时就固定了很难事后扩充只能从源头避免过多小文件或者换用支持更多inode的文件系统——但这些都属于预防性方案出了问题最需要的是快速定位。5.3 一条命令解决一大类问题管道与组合技Linux命令单用只是“工具”组合起来才是“武器”。我平时很少单独敲一条grep了事更多是几条命令用管道串起来完成一个完整任务。剥开来看每个任务都是“找到目标 - 过滤内容 - 处理结果”这三步。拿一个部署场景举例我需要确认某个Java进程是否健康、端口是否正常监听、日志是否有报错一条命令就能看个大概ps aux | grep order-service | grep -v grep | awk {print $2}拿到PID之后直接传给后面的命令继续处理。我曾经写过一个简单但好用的“一条命令定位谁在占用CPU”ps -eo pid,ppid,%cpu,cmd --sort-%cpu | headps -eo可以自定义要显示的字段--sort-%cpu按CPU使用率倒序排列head取前几条。这一套组合下来CPU狂飙的元凶一两秒就现形了。同样地如果我想查“谁在疯狂写磁盘”可以用iotop需要root或者用lsof配合awk看哪个进程打开的文件最多。我建议每个运维开发都建立自己的“命令工具箱”把常用的组合串存成shell函数或者alias。比如我在自己的.bashrc里配置了几个高频快捷命令# 按CPU占用排序显示top 10进程 alias pstopps -eo pid,ppid,%cpu,%mem,cmd --sort-%cpu | head -10 # 杀掉某个进程的所有实例 alias killallpkill -9 -f # 快速查看某个端口的监听状态 alias portss -tlnp | grep一旦把这些高频操作变成肌肉记忆工作效率的提升是非常明显的。6. Docker与开发环境的常用命令速查6.1 镜像与容器的日常指令现在的运维开发环境里Docker基本是标配了。我在文章中特意把Docker命令也列入常用范围因为你在服务器上排查问题时很多进程其实就是跑在容器里的。最常见的情况是你用ps aux看到了一个进程但操作起来发现它属于某个容器如果没有Docker命令基础会陷入管理混乱。镜像下载和查看最高频的几个操作# 拉取镜像 docker pull nginx:1.24 # 看本地镜像列表 docker images # 删除悬空镜像 docker image prune # 删除指定镜像有容器在跑时删不掉 docker rmi nginx:1.24容器的启动和查看我日常最常用的几个命令# 启动一个后台运行的容器 docker run -d --name myapp -p 8080:80 nginx:1.24 # 查看正在运行的容器 docker ps # 查看所有容器包括已停止的 docker ps -a # 进入容器交互式shell docker exec -it myapp bash # 查看容器日志 docker logs -f myapp # 停止/启动/重启容器 docker stop myapp docker start myapp docker restart myappdocker run参数里有两个是必懂且易错的-p 8080:80表示把宿主机的8080端口映射到容器的80端口顺序千万别写反-v /宿主机目录:/容器目录用于挂载数据卷改了代码不用重建镜像就能生效。排查容器问题时我都会先跑docker ps确认容器状态再docker logs看输出这和排查普通服务时先systemctl status再journalctl是同一套思路。6.2 进入容器后的调试工具缺失问题有一类镜像为了瘦身会把很多调试工具精简掉。我常碰到的情况是进入容器后想用ping提示command not found想用vim也没有连curl都没装。这时我一般这么救急# 在宿主机上直接执行容器里的命令 docker exec myapp cat /etc/nginx/nginx.conf # 在宿主机上直接查看容器日志 docker logs --tail 50 myapp # 如果容器里没有bash用sh docker exec -it myapp sh如果实在需要更完整的调试环境可以临时装一下工具比如基于Debian的镜像用apt-get update apt-get install -y procps curl iputils-ping但这个过程会修改容器不建议对正在运行的生产容器这样做。更好的方式是在写Dockerfile时就把常用调试工具打进去或者挂载宿主机的调试工具目录到容器内。运维开发工作中接触的软件远远不止Docker一个。数据库方面MySQL的命令、Redis的命令几乎每天都会碰到版本管理里Git的常用命令更是基本功。我在团队里带人时会强调命令不需要都会但必须人手一套自己最顺手的“常用清单”用完再查查完再总结很快就能沉淀出适合自己的工具箱。7. 面试常见命令考点与避坑7.1 面试爱问的十条命令细节很多人在面试Linux相关岗位前会专门去背“Linux面试题”。结合我自己的面试和被面试经验这些考点其实非常集中而且很多都和工作场景强相关面试问题正确回答要点容易踩的坑如何查看系统负载top看load averageuptime也能看把load平均值和CPU使用率混为一谈如何查找大文件find / -type f -size 1G忘记排除proc等虚拟目录如何看端口占用ss -tlnp 或 lsof -i:端口只答netstat但新系统可能没装如何实时看日志tail -F区分-f和-F只说tail -f不知道日志切割问题磁盘满了如何排查df -h、du -sh、df -i只查空间不查inode如何找僵尸进程ps aux | grep defunct 或 ps -eo stat不知道怎么处理父进程kill -9和kill -15区别15是优雅终止9是强制杀死动不动就kill -9不顾服务状态如何统计日志中某个IP出现次数awk {print $1} app.log | sort | uniq -c | sort -rn不会组合使用多条命令环境变量在哪个文件里配/etc/profile、~/.bashrc改了不知道source如何查看系统启动时间uptime -s 或 who -b不知道uptime带启动参数顺便说一句sort和uniq是配合起来统计文本的高频组合也是面试爱出的题。sort先排序uniq -c统计重复次数sort -rn按次数倒序输出三连套几乎没有变化cat access.log | awk {print $1} | sort | uniq -c | sort -rn | head这就是面试题“统计访问最多的前10个IP”的标准解法。你不需要背答案理解“提取字段、排序、去重统计、倒序取前N条”这个逻辑链以后遇到类似问题都能自己推导出来。7.2 答题之外的实战表达描述排障思路比背命令更重要面试的时候还有一点特别吃亏很多人命令背得很熟但一被问“线上接口突然变慢了你怎么排查”就开始东一句西一句没有清晰的思路。而面试官其实很吃这一套——他认不认可你往往不是看你会不会背命令而是看你能不能像讲故事一样把排查过程讲清楚。我建议大家按照“从现象到根因”的方式来组织思路。比如接口变慢这个问题我通常的回答链路是先用top看CPU和负载是否异常判断是系统瓶颈还是应用瓶颈再确认是哪个进程占用偏高用ps或top -H定位到线程级别看是不是某个线程在做密集计算如果是Java应用用jstack打印线程栈看卡在哪个调用上同时用free -h看内存是否紧张用df -h看磁盘是否满了排除资源不足再看网络层用ss -tlnp看连接数、用curl -w测一下本机接口响应耗时判断是应用慢还是网络慢最后结合日志用grep和journalctl找异常堆栈和报错时间点。这套思路可能不会一上来就命中根因但它是“有逻辑地逼近问题”而不是无头苍蝇乱撞。我个人在实际带团队时最看重的也是这种能力——命令不会查一查就会了但排障思路混乱给再多工具也没用。所以我建议各位在日常工作中刻意练习一下每次排查完一个问题回头梳理一遍“我是怎么一步步走到根因的”把这条路径记下来。时间长了你会发现自己的排查速度和准确率都在明显提升。最后再说一点私货这个领域的知识更新其实不慢早几年你还在用netstat和service现在主流已经是ss和systemctl了。但核心方法论是不变的——遇到问题先明确现象再缩小范围逐层定位根因。命令只是你的工具思路才是你的核心能力。所以不必贪多把最常用的几十条命令练到条件反射再保持一个“边用边查、查完总结”的习惯你在Linux这条路上的成长会非常快。
运维开发必备Linux命令实战：高频命令与排障思路
开了两台服务器一台是CentOS一台是Ubuntu常年做线上部署和排查问题。用了几年之后最大的感受是Linux命令这东西光靠背没有用你得知道在什么场景下用它、为什么用它、用了之后能看到什么。刚带团队的时候我发现很多新人手里攥着一份“命令大全”但真到线上服务器出问题还是一头雾水——拿top看到load average高了不知道下一步看什么grep出来一堆日志不知道怎么过滤端口被占用了甚至不知道先敲哪条命令。这篇文章就是我实际工作里最常用、最踩坑、也最值得反复看的Linux命令梳理围绕“运维开发”这个真实场景来展开。不是我随手整理的速查表而是每条命令都配合了使用场景、排查思路、以及我自己踩过的坑。不管你是刚入行的运维新人还是写代码但偶尔要上服务器排查的后端开发或者是准备面试想补一下系统知识这篇文章应该都能让你少走点弯路。1. 先建立自己的命令地图运维开发到底该学哪些1.1 别按字母表背命令先分场景很多人学Linux命令的方式是拿着一份“Linux常用命令大全”从头看今天看了ls、cd、pwd明天看cp、mv、rm看着看着就忘了遇到问题还是想不到用哪条。我建议换一种方式按“场景”来组织命令而不是按“字母表”。所谓场景就是你实际干活的几种动作。拿我自己的日常工作来说无非就是这几类找文件、看日志、查进程、看性能、管服务、配权限、网络调试、写脚本。每类场景对应一小撮高频命令把这些“核心组合拳”练熟了已经能覆盖90%以上的日常运维和开发工作。比如找文件这个场景核心命令就三个find、locate、which。其中find最强大locate查得最快which用来确认命令路径。你不需要记几十个参数只要知道find能按名字、类型、时间、大小定位文件遇到问题再临时man find或find --help查一下就行。先有“地图”再补充细节记忆负担会小很多。1.2 从Windows迁移到Linux的三个快速对照团队里很多开发一开始是Windows环境刚上Linux服务器经常找不到北。其实不用慌大部分操作在两边是有对应关系的。我整理了一个高频对照表新人照着看半天就能上手基本操作Windows习惯Linux对照命令差异点dir / 文件夹文件列表ls、llll是ls -l的别名看权限和大小更直观notepad打开文件vi/vim、cat、lessvim是编辑cat/less只读查看任务管理器看进程top、ps auxtop动态刷新ps看快照ipconfig查网络ip addr、ifconfigifconfig在部分新系统需安装net-tools删除文件无回收站rm -rf特别注意删了真没了没有回收站复制/移动cp、mvmv跨文件系统可能变成“复制删除”这里我必须单独强调一下rm -rf。这是Linux新人最容易出的重大事故——在错误的目录上执行了rm -rf后果是整个目录没了而且没有Windows那种回收站兜底。我的习惯是生产服务器上给rm做一个alias改成rm -i删除前必须逐个确认高危操作前先echo $PWD看看当前路径再ls确认一下再删。别觉得麻烦真正出事的时候这几秒钟的确认就是你的保命符。2. 文件和文本处理日常干活的重头戏2.1 文件查找与定位find的高频实战写法find是我每天都要用到的命令尤其是排查问题的时候。按文件名找、按目录找、按时间找、按大小找每种需求都有对应的写法。我把高频用法列一下每一条都是我实际敲过的# 在当前目录下按名字找文件 find . -name *.log # 按名字找忽略大小写 find /opt -iname order*.jar # 按类型找只看目录或只看文件 find . -type d -name conf find . -type f -size 500M # 按修改时间找最近7天内改过的文件 find /app -mtime -7 -type f # 定位并直接执行操作比如批量删除3天前的临时文件 find /tmp -name *.tmp -mtime 3 -exec rm -f {} \;很多教程会告诉你find -mtime的用法但没说清楚7和-7的区别。这里我用自己的话解释一下-mtime -7是“最近7天以内被修改过”-mtime 7是“7天以前被修改过”。一字之差搜索结果天差地别。批量删除老文件这种操作我会先用不带-exec的版本把结果列出来眼睛确认一遍再决定要不要真正执行删除。2.2 日志分析的三个主力grep、awk、sed日志分析是运维开发绕不开的活线上出了问题第一件事就是去翻日志。而日志分析的三个核心工具就是grep、awk、sed。这三个工具的功能有重叠但各有侧重我一般这么用grep用来“筛行”。我想看报错、看关键字第一反应就是grep。高频参数如下# 直接在日志里搜关键字 grep ERROR app.log # 递归搜索整个目录看哪些文件里有目标关键字 grep -r NullPointerException /app/logs/ # 搜出关键字的同时显示前后3行上下文 grep -B 3 -A 3 ERROR app.log # 不命中关键字反向过滤 grep -v healthcheck app.log # 统计关键字出现次数 grep -c Exception app.log这里有个很实际的技巧线上日志文件巨大动辄几个GB直接grep ERROR会刷屏。我会先grep -c看看总量再配合tail或者grep加行数限制来捞取关键片段——先看“有没有”再决定“要不要拉出来看”。awk用来“取列”和“做统计”。日志每一行往往有固定格式比如时间、级别、线程名、消息内容用空格或制表符分割。这时awk是最顺手的工具# 打印每行第1列和第3列 awk {print $1, $3} app.log # 指定分隔符比如按逗号或竖线分割 awk -F| {print $2} data.txt # 统计某个字段出现的次数 awk {count[$1]} END {for (k in count) print k, count[k]} app.log # 按条件过滤行比如找响应时间超过500ms的记录 awk $NF 500 {print $0} access.log可能有人看到awk的语法会觉得头大其实可以先把它当成“按列切数据的工具”来用核心就是{print $1}这种形式。$NF代表“最后一个字段”$0代表“整行”。先把这两点记住awk就能解决工作中80%的字段截取需求。sed用来“改”和“删行”。它最擅长流式编辑虽然平时不会用它写业务代码但处理日志和配置特别好用# 把文件里所有的old替换成new打印到屏幕不改原文件 sed s/old/new/g file.txt # 真正原地修改危险操作建议先备份 sed -i s/127.0.0.1/0.0.0.0/g config.yaml # 删除第5行到第10行 sed 5,10d file.txt # 只打印第20行到第30行 sed -n 20,30p file.txt网上关于这三个工具的教程特别多但我建议你先掌握上面这些高频写法。我见过太多人花两星期去啃awk的全部语法最后工作里用到的就是那么一两个模式。先把“筛行、取列、改串”这三板斧玩熟比什么都强。2.3 查看文件内容的正确打开方式文件内容查看是新手最容易用错工具的地方。我见过有人在几GB的日志文件上直接cat结果终端直接卡死只看到屏幕哗哗滚动。正确的打开方式应该是场景正确工具原因看完整小文件cat文件不大直接输出没问题看大文件末尾最新内容tail -f实时跟踪新增日志看大文件开头head只看头部几行翻页浏览大文件less支持上下翻页、搜索看文件前几行确认格式head -20先看格式再决定怎么处理我工作中用得最多的是tail -f和less。tail -f是“官方推荐的日志跟踪姿势”线上服务只要用systemd管理日志输出到文件我排查问题第一件事就是tail -f盯着看新增内容。但这里有个经典坑日志文件如果按天切割你会看到程序写的是新的日志文件但tail -f还在盯旧文件什么新内容都不显示。原因是tail -f跟踪的是文件句柄不是文件名本身。解决方案是改用tail -F大写它会依照文件名重新打开文件tail -F app.log就一个大小写的区别让我不止一次从满头问号里解脱出来。还有一次更典型我在tail -f日志之后想同时过滤关键字想用管道tail -f app.log | grep ERROR结果grep有输出缓冲终端半天不刷新。后来改成tail -f app.log | grep --line-buffered ERROR实时性立刻好了。这种细节不去踩一遍坑是很难想起来的。3. 性能排查与进程管理线上问题定位的核心能力3.1 从top到ps找到CPU和内存的元凶线上服务出了问题最常见的表现就是CPU飙升、内存爆满、接口变慢。这时候第一步就是顶上去看top。很多人只会敲一个top然后盯着看其实top里有不少交互快捷键排查效率天差地别# 直接查看 top # 进入top后按P按CPU排序按M按内存排序 # 按1查看多核CPU使用率分布 # 按H切换线程视图看具体线程占用top的第一屏信息要会读。load average后面的三个数字分别是过去1分钟、5分钟、15分钟的平均负载如果1分钟的值明显高于15分钟说明系统负载正在快速上升这可能是一个刚刚开始的问题也可能是定时任务在跑如果三个值都很高说明系统已经持续繁忙很久了。配合top -H可以看线程级别的CPU占用这在排查Java、Python、Node这类服务时特别关键——你能直接看到是哪个具体线程在疯狂吃CPU。ps看的是进程快照和top的动态视图互补# 展示所有进程包含完整命令行 ps aux # 精确查找某个进程 ps aux | grep java # 只看PID这在脚本里特别有用 pgrep -f order-service这里我说一个自己的排查套路。遇到CPU高的问题我一般先top看是哪个进程的PID然后ps -p PID -o pid,ppid,%cpu,%mem,cmd看它的启动命令确认是不是我们要找的服务。如果是Java应用下一步就是top -H -p PID找到最耗CPU的线程ID把它转成十六进制再去jstack PID | grep -A 30 nid十六进制数看这个线程到底在执行什么代码。这套组合拳虽然用到了jstack但前面几步都是纯Linux命令思路是通用的。3.2 free、df与日志内存、磁盘排查的常见误区内存和磁盘排查是运维开发面试和工作中都爱考的场景。先说内存free -h是最常用的命令但新手很容易被里面的buffer/cache带偏free -h很多人看到used很高、available很低就觉得内存不够了。其实Linux内核会把空闲内存尽可能用作文件缓存buffer/cache这部分内存在某个应用申请大内存时实际上是可以释放的所以判断内存是否紧张最重要的是看available这一列而不是简单看used。我在公司内部给新人做分享时经常强调一句话used高不代表内存不够available低才是真的不够。磁盘这块df -h和du -sh是两把尺子但量的是完全不同的东西。# 看整个磁盘空间使用情况 df -h # 看某个目录总共占用 du -sh /app # 看某个目录下各子目录的大小定位占空间的“大户” du -h --max-depth1 /app | sort -rhdf量的是文件系统的使用量du量的是目录的实际占用。线上经常出现一个问题df -h显示磁盘满了但du -sh看所有大目录加起来却对不上。这种情况十有八九是有人删了文件但那个文件还被某个进程占用了没有真正释放。这个场景我已经踩过太多次后面会单独写一节来演示怎么排查。还有一个很容易忽略的坑df -h看的是块使用率但你可能遇到一个更隐蔽的“满”——inode满了。df -i可以看inode使用情况如果inode满了即使磁盘还有空间你也无法创建任何新文件、新目录。这种情况常见于某目录下塞了上百万个超小的文件。所以遇到“文件写不进去”的问题别光看df -h顺手敲一下df -i能省很多排查时间。3.3 端口与网络连接排查ss、lsof与curl端口被占用、网络超时、服务连不上这类网络问题在运维开发日常里太常见了。以前大家习惯用netstat但现在很多新装的系统里已经没有netstat了我更推荐直接用ss# 查看某个端口是否被监听 ss -tlnp | grep 8080 # 查看所有监听端口 ss -tln # 查看tcp连接状态统计比如SYN_SENT、TIME_WAIT多不多 ss -sss -tlnp里的-p会显示监听端口的进程信息这一项用途极大。遇到过“端口被占用”的问题一条命令就能把占用进程的PID和名字带出来不用再猜是谁干的。另一个高频命令是lsof它的功能比ss更丰富一些# 查看某个文件被哪个进程打开 lsof /var/log/app.log # 查看某个端口被哪个进程占用 lsof -i :8080 # 列出所有打开的文件这个配合排查文件句柄泄漏特别有用 lsof -p PID我印象最深刻的一次排查服务突然报“too many open files”当时怎么都查不到原因。后来用lsof -p PID | wc -l一数发现那个进程打开的文件句柄数上万再往下细看一堆socket没有正常关闭。那之后我就养成了一个习惯遇到连接数异常、文件句柄泄漏类问题先查lsof比空想快得多。网络连通性排查我常用的命令组合是ping、telnet、curl。ping告诉我们主机通不通telnet ip port告诉我们端口通不通curl则可以直接发HTTP请求测试接口。这里要提醒一下新装的容器镜像里经常没有telnet可以改用nc -vz ip port效果类似# 测端口连通性 nc -vz 192.168.1.100 3306 # 如果nc也没有用curl curl -v telnet://192.168.1.100:3306curl本身也是个强大的调试工具我平时查接口返回、看响应头、看请求耗时都用它# 只看响应头 curl -I https://example.com # 限制超时时间防止命令挂死 curl -m 5 https://example.com # 输出请求耗时明细 curl -w 连接耗时:%{time_connect} 总耗时:%{time_total}\n -o /dev/null -s https://example.com4. 服务管理与自动化从手动操作走向效率工具4.1 systemctl与journalctl现代Linux服务管理现在主流发行版都使用systemd来管理服务systemctl就是和它打交道的核心命令。很多老教程还在讲service xxx start/stop但这些命令在很多系统上只是systemctl的转发器所以我建议直接学systemctl# 启动服务 systemctl start nginx # 停止服务 systemctl stop nginx # 重启服务 systemctl restart nginx # 设置开机自启 systemctl enable nginx # 查看服务状态 systemctl status nginxsystemctl status这命令是排查问题的利器它会一次性显示服务的运行状态、主进程PID、最近日志以及常见的错误提示。我见过不少新人问“我的服务怎么起不来”我都会先让他跑一下systemctl status 服务名把输出贴出来再看下一步这个习惯能帮你省掉大量猜测时间。和systemd配套的日志工具是journalctl这是查看服务日志的第一入口# 查看某个服务的全部日志 journalctl -u nginx # 实时跟踪某个服务的日志 journalctl -u nginx -f # 查看最近10条 journalctl -u nginx -n 10 # 查看某个时间段 journalctl -u nginx --since 2024-12-01 10:00:00 --until 2024-12-01 11:00:00 # 查看错误级别以上的日志 journalctl -u nginx -p err我自己的工作习惯是服务起不来的问题先用systemctl status看状态再用journalctl看最近日志基本十有八九能找到原因。有一种常见情况是服务启动时依赖的配置目录不存在或者权限不对日志里会有明确的Permission denied或No such file or directory提示读完日志再去排查配置思路就非常清晰。4.2 权限、用户与定时任务权限问题是Linux新手最容易绕晕的领域。最基本的chmod和chown我要画一下重点# 修改文件权限r4w2x1 chmod 755 script.sh chmod x script.sh # 修改文件所有者 chown root:root /app/config.yaml # 递归修改目录权限 chown -R deploy:deploy /app/data权限数字的算法其实很简单r读是4w写是2x执行是1三个数相加得到一个权限值。755的意思是所有者可读可写可执行421组和其他人可读可执行41。我这里强烈建议一条最佳实践部署应用不用root用户而是单独创建deploy用户然后把应用目录chown给deploy。这样即使服务被入侵攻击者拿到的也不是root权限能少很多事。用户管理的命令要记的其实不多最常碰到的就是造账号、改密码、加sudo权限# 创建用户 useradd -m deploy # 设置密码 passwd deploy # 加入sudo组CentOS是wheel组Ubuntu是sudo组 usermod -aG wheel deploy # 删除用户 userdel -r deploy定时任务常用crontab。我平时排查问题看到“半夜突然CPU高”的诡异现象第一反应就是去看是不是有定时任务在跑# 查看当前用户的定时任务 crontab -l # 编辑定时任务 crontab -e # 每分钟执行一次 * * * * * /opt/scripts/check_health.sh # 每天凌晨3点执行 0 3 * * * /opt/scripts/backup.shcrontab的五段格式分别是分、时、日、月、星期这个格式如果你理解成“每天哪个时间点执行”上手会更快。需要特别注意的是crontab环境变量和登录环境不一样很多脚本在命令行跑得好好的放进crontab就出错很可能是PATH不对。我自己会习惯在脚本开头写清楚#!/bin/bash和PATH或者在crontab里直接写命令全路径。4.3 shell脚本的几个好习惯运维开发免不了写shell脚本批量部署、日志清理、数据备份都靠它。但脚本质量参差不齐我提几条自己写脚本时坚持的原则第一脚本开头固定两行#!/bin/bash set -euxo pipefailset -e表示一旦某条命令出错就立即退出set -u表示变量未定义就直接报错set -x会打印每一条执行的命令便于调试set -o pipefail可以让管道中任一环节报错导致整条管道返回失败。这一行是血泪教训换来的——不加的话脚本中间某一步静默失败了后面的流程还在“若无其事”往下跑最后结果完全不对排查起来特别痛苦。第二变量一定要加引号# 错误写法 if [ $name root ]; then # 正确写法 if [ $name root ]; then不加引号时如果$name是空值或者包含空格条件判断会直接报错。这个习惯在写脚本时一定要养成它引发的坑特别隐蔽。第三善用“防呆”参数# 拷贝时提示覆盖 cp -i src dest # 交互式删除 rm -i file脚本里跑批量删除、批量拷贝时如果操作对象特别关键我的做法是先打印、后执行必要时加上确认步骤。运维工作做久了你会明白脚本的功能强大大家都喜欢但脚本造成的“事故”往往更可怕。5. 高频场景实录运维开发会遇到的真实问题5.1 日志刷不出来与日志切割有一次线上Java服务访问量突然变大我想实时盯着日志看有没有异常。敲了tail -f app.log等了几分钟屏幕上什么都没动但明明服务在跑、接口在返回。第一反应是服务是不是把日志写到别处去了。后来我意识到这个服务的日志是通过logrotate每天切割的。最近一次切割发生在凌晨旧日志文件被改名成app.log-20241201并新建立了app.log。如果我在切割前就开始tail -f盯的是旧文件句柄而切割后新内容只会写入app.log这期间新日志自然一条都看不到。于是我把命令换成了tail -F app.log问题立刻解决。类似这样的“日志不动了”的问题还可能发生在管道缓冲场景tail -f app.log | grep ERROR --line-buffered不加--line-buffered时grep会启用块缓冲输出要攒满一个块通常是4KB才会打印给人的感觉就像卡死了一样。虽然加了这个参数后性能会有轻微下降但在实时跟踪的场景里实时性远比那点性能损失重要。5.2 磁盘没满却写不进文件那是我印象特别深的一次同事反馈某台服务器上写入文件报错提示“No space left on device”。我先跑了df -h结果吓一跳——磁盘明明有40%的空闲空间。第一反应是是不是挂载点看错了用df -h /app确认应用目录所在分区的确还有空间这就更奇怪了。再跑一下df -i才发现根因是inode已经用满了。df -i显示分区inode使用率100%任何新建文件的操作都会失败。定位到这个根因之后我顺着目录往下查发现是某个服务把大量小文件写进了一个临时目录一个几GB的目录里堆了几百万个几KB的文件把inode吃完了。找到问题后清理掉过期临时文件再创建文件就恢复正常了。这个案例给我的经验就是看到“No space left on device”不要只查磁盘空间一定要把df -h和df -i都跑一下。另外文件系统预留的inode数量在格式化时就固定了很难事后扩充只能从源头避免过多小文件或者换用支持更多inode的文件系统——但这些都属于预防性方案出了问题最需要的是快速定位。5.3 一条命令解决一大类问题管道与组合技Linux命令单用只是“工具”组合起来才是“武器”。我平时很少单独敲一条grep了事更多是几条命令用管道串起来完成一个完整任务。剥开来看每个任务都是“找到目标 - 过滤内容 - 处理结果”这三步。拿一个部署场景举例我需要确认某个Java进程是否健康、端口是否正常监听、日志是否有报错一条命令就能看个大概ps aux | grep order-service | grep -v grep | awk {print $2}拿到PID之后直接传给后面的命令继续处理。我曾经写过一个简单但好用的“一条命令定位谁在占用CPU”ps -eo pid,ppid,%cpu,cmd --sort-%cpu | headps -eo可以自定义要显示的字段--sort-%cpu按CPU使用率倒序排列head取前几条。这一套组合下来CPU狂飙的元凶一两秒就现形了。同样地如果我想查“谁在疯狂写磁盘”可以用iotop需要root或者用lsof配合awk看哪个进程打开的文件最多。我建议每个运维开发都建立自己的“命令工具箱”把常用的组合串存成shell函数或者alias。比如我在自己的.bashrc里配置了几个高频快捷命令# 按CPU占用排序显示top 10进程 alias pstopps -eo pid,ppid,%cpu,%mem,cmd --sort-%cpu | head -10 # 杀掉某个进程的所有实例 alias killallpkill -9 -f # 快速查看某个端口的监听状态 alias portss -tlnp | grep一旦把这些高频操作变成肌肉记忆工作效率的提升是非常明显的。6. Docker与开发环境的常用命令速查6.1 镜像与容器的日常指令现在的运维开发环境里Docker基本是标配了。我在文章中特意把Docker命令也列入常用范围因为你在服务器上排查问题时很多进程其实就是跑在容器里的。最常见的情况是你用ps aux看到了一个进程但操作起来发现它属于某个容器如果没有Docker命令基础会陷入管理混乱。镜像下载和查看最高频的几个操作# 拉取镜像 docker pull nginx:1.24 # 看本地镜像列表 docker images # 删除悬空镜像 docker image prune # 删除指定镜像有容器在跑时删不掉 docker rmi nginx:1.24容器的启动和查看我日常最常用的几个命令# 启动一个后台运行的容器 docker run -d --name myapp -p 8080:80 nginx:1.24 # 查看正在运行的容器 docker ps # 查看所有容器包括已停止的 docker ps -a # 进入容器交互式shell docker exec -it myapp bash # 查看容器日志 docker logs -f myapp # 停止/启动/重启容器 docker stop myapp docker start myapp docker restart myappdocker run参数里有两个是必懂且易错的-p 8080:80表示把宿主机的8080端口映射到容器的80端口顺序千万别写反-v /宿主机目录:/容器目录用于挂载数据卷改了代码不用重建镜像就能生效。排查容器问题时我都会先跑docker ps确认容器状态再docker logs看输出这和排查普通服务时先systemctl status再journalctl是同一套思路。6.2 进入容器后的调试工具缺失问题有一类镜像为了瘦身会把很多调试工具精简掉。我常碰到的情况是进入容器后想用ping提示command not found想用vim也没有连curl都没装。这时我一般这么救急# 在宿主机上直接执行容器里的命令 docker exec myapp cat /etc/nginx/nginx.conf # 在宿主机上直接查看容器日志 docker logs --tail 50 myapp # 如果容器里没有bash用sh docker exec -it myapp sh如果实在需要更完整的调试环境可以临时装一下工具比如基于Debian的镜像用apt-get update apt-get install -y procps curl iputils-ping但这个过程会修改容器不建议对正在运行的生产容器这样做。更好的方式是在写Dockerfile时就把常用调试工具打进去或者挂载宿主机的调试工具目录到容器内。运维开发工作中接触的软件远远不止Docker一个。数据库方面MySQL的命令、Redis的命令几乎每天都会碰到版本管理里Git的常用命令更是基本功。我在团队里带人时会强调命令不需要都会但必须人手一套自己最顺手的“常用清单”用完再查查完再总结很快就能沉淀出适合自己的工具箱。7. 面试常见命令考点与避坑7.1 面试爱问的十条命令细节很多人在面试Linux相关岗位前会专门去背“Linux面试题”。结合我自己的面试和被面试经验这些考点其实非常集中而且很多都和工作场景强相关面试问题正确回答要点容易踩的坑如何查看系统负载top看load averageuptime也能看把load平均值和CPU使用率混为一谈如何查找大文件find / -type f -size 1G忘记排除proc等虚拟目录如何看端口占用ss -tlnp 或 lsof -i:端口只答netstat但新系统可能没装如何实时看日志tail -F区分-f和-F只说tail -f不知道日志切割问题磁盘满了如何排查df -h、du -sh、df -i只查空间不查inode如何找僵尸进程ps aux | grep defunct 或 ps -eo stat不知道怎么处理父进程kill -9和kill -15区别15是优雅终止9是强制杀死动不动就kill -9不顾服务状态如何统计日志中某个IP出现次数awk {print $1} app.log | sort | uniq -c | sort -rn不会组合使用多条命令环境变量在哪个文件里配/etc/profile、~/.bashrc改了不知道source如何查看系统启动时间uptime -s 或 who -b不知道uptime带启动参数顺便说一句sort和uniq是配合起来统计文本的高频组合也是面试爱出的题。sort先排序uniq -c统计重复次数sort -rn按次数倒序输出三连套几乎没有变化cat access.log | awk {print $1} | sort | uniq -c | sort -rn | head这就是面试题“统计访问最多的前10个IP”的标准解法。你不需要背答案理解“提取字段、排序、去重统计、倒序取前N条”这个逻辑链以后遇到类似问题都能自己推导出来。7.2 答题之外的实战表达描述排障思路比背命令更重要面试的时候还有一点特别吃亏很多人命令背得很熟但一被问“线上接口突然变慢了你怎么排查”就开始东一句西一句没有清晰的思路。而面试官其实很吃这一套——他认不认可你往往不是看你会不会背命令而是看你能不能像讲故事一样把排查过程讲清楚。我建议大家按照“从现象到根因”的方式来组织思路。比如接口变慢这个问题我通常的回答链路是先用top看CPU和负载是否异常判断是系统瓶颈还是应用瓶颈再确认是哪个进程占用偏高用ps或top -H定位到线程级别看是不是某个线程在做密集计算如果是Java应用用jstack打印线程栈看卡在哪个调用上同时用free -h看内存是否紧张用df -h看磁盘是否满了排除资源不足再看网络层用ss -tlnp看连接数、用curl -w测一下本机接口响应耗时判断是应用慢还是网络慢最后结合日志用grep和journalctl找异常堆栈和报错时间点。这套思路可能不会一上来就命中根因但它是“有逻辑地逼近问题”而不是无头苍蝇乱撞。我个人在实际带团队时最看重的也是这种能力——命令不会查一查就会了但排障思路混乱给再多工具也没用。所以我建议各位在日常工作中刻意练习一下每次排查完一个问题回头梳理一遍“我是怎么一步步走到根因的”把这条路径记下来。时间长了你会发现自己的排查速度和准确率都在明显提升。最后再说一点私货这个领域的知识更新其实不慢早几年你还在用netstat和service现在主流已经是ss和systemctl了。但核心方法论是不变的——遇到问题先明确现象再缩小范围逐层定位根因。命令只是你的工具思路才是你的核心能力。所以不必贪多把最常用的几十条命令练到条件反射再保持一个“边用边查、查完总结”的习惯你在Linux这条路上的成长会非常快。
