★ FEATURED ARTICLE Linux下干活绕不开的就是那几件事在文件系统里折腾文件、从日志和文本里捞出想要的信息、把一堆文件打包搬走、顺手再管管系统状态。这四件事看着基础可恰恰是它们决定了你在终端里的效率天花板。经常看到新手把mv当cp用、把grep和find搞混、tar解包不知道到底该不该带z参数这些真不是记性差而是没人把背后的逻辑讲透。这篇东西就按实际干活的路子把文件操作、文本处理、高效搜索、压缩归档再加几项高频系统管理操作串起来讲一遍会附带我在生产环境里踩过的坑和验证过的写法。适合刚接触 Linux 不久、想在命令层面真正上手的朋友也适合平时写脚本时想查个明白的老手——哪怕你已经很熟里面几个关于权限、软链接和find -exec的细节也值得再扫一眼。1. 先把文件操作这层地基打牢文件操作是 Linux 里最频繁的动作但恰恰因为太常用很多人反而没认真抠过细节。我见过有人在线上服务器执行cp把软链接原样复制过去结果应用启动直接报错也见过rm -rf后面跟了个变量没展开差点把目录删穿。这一部分就把复制、移动、删除、权限和链接这些基础操作里的关键细节说清楚。1.1 复制、移动、删除的反直觉细节cp、mv、rm这三兄弟人人会用但它们的隐藏参数和底层行为才是真正拉开效率差距的地方。先说cp。默认情况下cp只复制文件内容不保留时间戳、属主和权限位。如果你用cp备份配置文件备份出来的文件 mtime 是当前时间权限也可能变成当前用户的 umask 默认值等要恢复时才发现一堆坑。所以备份场景我几乎永远用cp -a-a等价于-dR --preserveall能保留链接属性、递归复制并原样保留权限和时间戳。有一次我在迁移一个项目目录时图省事用cp -r结果软链接全部变成普通文件的拷贝程序启动后一堆路径找不到后来改成cp -a一次就干净了。再说mv。很多人没意识到mv在同一个文件系统内只是改个目录项秒完成但跨文件系统移动时它实际执行的是复制删除速度会慢很多而且会改变文件的 inode。这也是为什么你在/home和/data两个分区之间移动大文件时感觉特别慢。判断是否跨分区用df看两个路径所在文件系统是否一致就行。另外mv默认会覆盖目标文件而不询问想安全一点可以加-i或者给mv设置 shell 别名让它交互式确认。最后是rm这是全 Linux 里最需要敬畏的命令。rm -rf的破坏力不用多说但真正容易出事的场景是变量为空或路径拼接错误。比如脚本里写了rm -rf $DIR/$SUBDIR而$SUBDIR因为上层逻辑没赋值导致为空命令就变成了rm -rf $DIR/如果$DIR恰好是根目录或父目录事故就来了。我的习惯是凡是脚本里出现rm -rf前面一定加一个[ -n $SUBDIR ]判断或者改用rm -rf $DIR/${SUBDIR:?}这种在变量为空时直接报错的写法。还有个小技巧删除大量小文件时rm -rf可能比较慢这时候可以换个思路把目录mv到一个临时位置再后台慢慢删业务侧立即恢复。这种移动代替删除的方式在高并发环境里非常实用。1.2 权限、属主与软链接隐藏但致命的细节文件权限是 Linux 文件系统最核心的安全模型也是新手最容易栽跟头的地方。ls -l输出的-rwxr-xr-x这类字符串每次看都像在读密码其实拆开就三组所有者owner、所属组group、其他人others每组三个字符分别表示读r4、写w2、执行x1。数字法chmod 755对应的就是所有者 7421、组 541、其他人 541。我建议把每个权限对应的数字直接背下来因为写脚本时你根本没时间去看符号法。chmod还有一个容易被忽略的-R参数递归修改目录下所有文件权限。但注意目录和文件的执行权限含义完全不同目录的 x 权限意味着能否进入该目录所以对目录来说 x 是刚需。如果哪天你发现一个目录 ls 能看到路径但 cd 不进去十有八九是目录少了 x 权限。chown改属主时很多人只改用户不改组。实际上一条chown user:group file可以一步到位中间的冒号别漏了。生产环境里我遇到过的问题是用 FTP 工具上传的文件属主是www但 Nginx 的 worker 进程跑在nginx用户下导致页面报 403。这种问题ls -l一眼就能看出来但新手往往权限设成 777 了事回来权限是够了安全又没了。再说软链接。ln -s /data/app /opt/app创建的软链接本质上是一个独立的 inode指向目标路径。它有两个特点是新手不知道的用cp -r复制软链接时会跟踪链接指向的真实文件除非加-d或-a。软链接的路径是原样记录的你把软链接移动到别处它依然指向原来的绝对路径不会因为移动而自动变成相对路径。所以在做应用部署时我一般这样设计真实代码放在/data/releases/v20240101再建一个软链接/data/www指向当前版本程序只读/data/www。回滚时只需要把软链接ln -sfn指回上一个版本即可不用复制任何文件零中断切换。这个模式在 PHP、Node 等项目的发布流程里非常管用。关于硬链接顺便说一句ln不加参数默认创建硬链接它和软链接最大的区别是硬链接共享同一个 inode只能在同一文件系统内创建而且不能指向目录。日常维护中硬链接适合用来给配置文件做免备份的多路径入口但用得不多的化很容易搞混建议新手上手先用软链接。2. 文本处理grep、sed、awk 三板斧系统管理里一半以上的时间其实不是在管理是在看日志、分析结果、统计数据。日志是文本配置文件是文本命令输出也是文本所以文本处理能力基本决定了你运维效率的下限。这三个命令没有哪个可以替代哪个它们是各自分工的grep负责过滤sed负责替换和编辑awk负责取列和统计。2.1 grep从简单过滤到上下文匹配grep是大家最早接触的命令之一但大多数人的用法停留在grep error app.log。实际用起来有几个参数是我每次排查问题必带的grep -r递归搜索目录替代老旧的grep -R作用一样但语义更现代。grep -E支持扩展正则比如grep -E ERROR|FATAL不需要再用一堆转义的管道符。grep -v反向过滤排除掉不想要的行比如日志里满是心跳包噪音用grep -v heartbeat瞬间清爽。grep -c统计匹配的行数注意-c统计的是行数不是匹配次数一行多次匹配也只算一行。grep -A/-B/-C-A 2显示匹配行的后两行-B 2显示前两行-C 2显示前后各两行。有一次线上告警说要排查某个接口的调用来源日志量巨大直接grep 接口名刷出几千行肉眼根本看不过来。后来我改成grep -C 2 接口名 access.log | tail -50先看报错前前后后的上下文定位到是哪个上游 IP 传了异常参数再针对性去查上游日志十分钟就解决了。-C这个参数在日志排查场景里几乎是必配技能。再补一个性能相关的点如果你在日志文件上反复grep大文件特别是几个 GB 的日志可以先想想到底要匹配多少次。如果只是偶尔一次直接grep没问题如果一天要查几十次可以考虑先把当天日志grep出关心的级别重定向到一个小文件再在这个小文件上反复查。另外grep原生就支持多文件grep error /var/log/nginx/*.log会显示文件名前缀配合-h可以去掉文件名只显示行内容写脚本提取信息时很常用。2.2 sed流式编辑的常用姿势sed的全名是 stream editor流式编辑器。它和vim这类交互式编辑器的核心区别是sed 按行读取、处理、输出整个过程是流水线式的非常适合批量替换和自动化处理。最经典的用法是替换格式为sed s/旧/新/标志 文件。比如你想把配置文件里所有的127.0.0.1替换成192.168.1.10写sed s/127.0.0.1/192.168.1.10/g config.conf注意g标志代表全局替换不加的话只替换每行第一次出现的匹配。另一个高频标志是i忽略大小写在匹配路径和报错信息时经常用。sed 的-i参数表示原地修改直接写入文件不再输出到终端。但用-i之前一定先备份。我的习惯是sed -i.bak s/old/new/g file这样修改前会自动生成一个file.bak备份文件出问题随时回滚。有一次我在线上批量修改 Nginx 配置时忘了加备份后缀结果替换完后发现有个正则写错了把 upstream 的地址改成了错误 IP恢复只能靠记忆重新手写冷汗都下来了。从那以后配置文件批量修改我永远用-i.bak。sed 除了替换还有两个常用功能删除和打印。sed /pattern/d file删除匹配 pattern 的行sed -n /pattern/p file只打印匹配行。-n加p的组合等价于一个简化版的 grep但它和 grep 合起来用能做到很多复杂的组合逻辑比如先sed筛选出某个区间再对区间内做替换。还有一个小技巧sed 可以按行号操作。sed -n 10,20p file打印第 10 到 20 行这个在查看大文件指定片段时比head/tail精确得多。比如日志是固定格式的每行都带时间戳你想查看 14:00 到 14:05 之间的日志可以先grep -n 14:00:0找到起始行号再用sed -n 123,456p精确截取。2.3 awk按列处理的万能工具awk 是这三个命令里最难学、也最值钱的。它把每一行按分隔符拆成多个字段默认按空白字符分列然后可以对这些字段做判断、计算和格式化输出。用生活化的比喻grep 像是在一摞文件里翻出需要的那些页sed 像在每页上做批注和修改awk 则像把每行当成一张表格记录能按列筛选、统计、求和。最基本的结构是awk {print $1}$1 是第一列$0 是整行NF 是当前行的字段数NR 是当前行号。用awk {print $NF}可以取每行的最后一列这在处理 ps 输出、路径信息时非常好用。我举一个真实的案例。某次线上磁盘告警需要找出/data/logs下最大的 10 个文件。用du -h /data/logs/*拿到的是文件大小和路径列表但 du 的输出格式是 1.2G /data/logs/app.log要排序就得先提取数字列。一条du -h /data/logs/* | sort -rh | head -10能直接按大小排序因为 sort 的-h参数天生支持人类可读的容量单位排序。但假如 du 的输出后面还跟着权限、属主等信息列你想单独拿出来统计awk 就派上用场了。awk 最实用的场景是日志统计分析。比如分析 Nginx access log 里每个 IP 的请求次数log 格式是IP 时间 请求行 状态码 大小用awk {count[$1]} END {for (ip in count) print count[ip], ip} access.log | sort -rn | head -10一条命令就能拿到请求量 TOP10 的 IP 列表。这种用法把 awk 的关联数组和 END 块都用上了是日常运维里最高频的统计模板。再比如按状态码统计awk {code[$9]} END {for (c in code) print c, code[c]} access.log配合sort -rn查看各状态码分布4xx 和 5xx 的数量一眼看清。写 awk 脚本时要注意字段索引从 1 开始别和数组下标搞混。刚开始不熟的可以先打印$0、$1、$NF找感觉等理解了字段模型awk 基本就能当轻量级报表工具用了。3. 高效搜索find 与 locate 的配合打法搜文件是 Linux 里另一类高频需求。最常见的痛点是知道部分文件名但忘了完整路径。find是对目录树实时遍历搜索locate依赖预建的数据库做快速定位两者各有适用场景。选错工具要么慢得让人着急要么搜出来的结果早就过期了。3.1 find按名字、类型、时间、大小过滤find的语法核心是起点 条件 动作。最基础的用法find /data -name *.log是在/data下按文件名匹配*.log。注意-name区分大小写-iname不区分实际使用中如果记得文件大概叫什么但记不住大小写-iname更省心。按类型过滤用-type f普通文件、-type d目录、-type l软链接。这个在清理文件时特别好用比如你想找出所有超过 500MB 的日志文件find /data/logs -type f -size 500M一把梭。-size的参数支持c字节、k、M、G500M表示大于 500M-5M表示小于 5M不加符号表示恰好。按时间过滤是运维场景里的高频需求-mtime按内容修改时间-atime按访问时间-ctime按状态变更时间。find /data/backup -type f -mtime 30 -delete可以删除 30 天前的备份文件这是写清理脚本时的经典模板。但用-delete之前务必先跑一遍不带动作的 find 确认匹配范围别一上来就删血泪教训太多了。find最大的威力在于查完即执行。find . -name *.tmp -exec rm {} \;会对每个匹配文件执行 rm。但是注意-exec每匹配一个文件就启动一次新进程文件数量多时效率极差。更高效的做法是配合管道交给xargsfind . -name *.tmp -print0 | xargs -0 rm。这里的-print0和xargs -0是为了处理文件名里的空格强烈建议总是成对使用否则遇到带空格或特殊字符的文件名xargs 会把一个文件名拆成两半。我自己的习惯是排查优先用find 路径 -type f -name 模糊名字*先确认能找到文件需要批量操作时再用xargs接收。特别是find结合-exec du -h {} \;能快速看出目录下哪些子目录占空间大比du -sh *更精细。3.2 locate 与 updatedb适合快速定位的轻量方案locate和find的底层逻辑完全不同。locate 查询的不是实时文件系统而是预建的数据库/var/lib/plocate/mlocate.db。这个数据库由updatedb定期更新通常是系统每天执行一次定时任务自动生成。所以locate快得离谱但它有一个天然缺陷刚创建的文件搜不到刚删除的文件还会显示。使用场景也由此区分如果你只是想知道系统里某个配置文件的完整路径比如locate nginx.conf秒出结果完全不用手动从/开始find可如果你刚编辑了一个文件马上就想 locate 到它大概率是找不到的。这时候要么手动运行sudo updatedb更新数据库要么干脆切回find。有一次我给客户排查一个问题对方说某个脚本在/opt下找不到我locate了半天也搜不到后来才发现那个脚本是最近一小时刚拷贝进去的updatedb还没跑。所以用locate时要多一个心眼搜不到不代表文件不存在也可能是数据库没跟上。遇到重要文件定位用find做二次确认永远比locate可靠。推荐组合打法日常快速定位用locate或which/whereis这两个查 PATH 里的可执行程序正式操作前用find验证。既享受了速度又规避了过期数据的问题。4. 压缩归档tar 是主角但别忽视压缩率压缩归档在 Linux 里几乎是打包搬家的代名词。tar是最基础的归档工具gzip、bzip2、xz 是不同的压缩算法。很多人只会tar -czvf和tar -xzvf这一对组合遇到.tar.bz2、.tar.xz就卡壳其实背后的逻辑非常简单。4.1 tar 打包与解包的实操套路先记住一个概念tar 本身只是打包archive不做压缩。tar -cf archive.tar /data只是把目录结构原样放入一个 tar 文件里体积没有明显变化。要压缩就得通过-zgzip、-jbzip2、-Jxz指定压缩算法。所以常见命令的拆解是tar -czvf app.tar.gz /data/app-c创建归档-z用 gzip 压缩-v显示过程-f指定文件名。tar -xzvf app.tar.gz -C /tmp-x解包-C指定解压到哪个目录。tar -tzf app.tar.gz-t列出档案内容不解包直接看里面有什么文件。解包时有个几乎人人踩过的坑不带-C就解包文件直接释放到当前目录。如果 tar 包里的目录结构带着绝对路径或散落的文件很可能把当前目录搞得一团糟。所以我在生产环境解包的铁律是先tar -tzf看一眼内容再决定-C到哪个目录。tar 还经常被用来做免打包的目录拷贝。tar -cf - /data/app | tar -xf - -C /tmp/app这条命令不落地任何 tar 文件直接在内存管道里完成复制比cp -a在某些情况下还快。特别是需要保留权限、属主、软链接等完整属性时这个方式很实用。我自己在同步大量配置文件时经常这么干避免 cp 对属性丢失的问题。遇到损坏的 tar 包可以试着gzip -t验证 gzip 压缩包完整性或者tar -tvzf列出内容判断损坏位置。曾经处理过一个大客户的备份包损坏事件开头十几个文件正常中间某个文件 CRC 错误后面全读不出来。这种损坏基本没救所以备份的多条链路异地多份原则永远不要省。4.2 压缩工具怎么选gzip、bzip2、xz、zip不同压缩算法的核心指标是压缩率、压缩速度、解压速度。粗暴的结论是gzip.gz速度最快压缩率一般适合对速度有要求的网络传输。bzip2.bz2压缩率明显优于 gzip速度慢一些适合磁盘上的长期归档。xz.xz压缩率最高速度最慢适合日志归档、软件发布包等极度看重空间的场景。zip和 Windows 生态交互的标准格式跨平台兼容最好。我曾经用一个约 2GB 的文本日志文件做过实测对比gzip 压缩耗时不到半分钟xz 压缩花了近十五分钟但 xz 出来的体积比 gzip 小了约 30%。如果不再打开日志只是留着归档待查一次慢压缩换长期省空间是值得的。可如果压缩包是用来在服务器之间来回传输、频繁解压的gzip 明显更划算快进快出。单独用zip命令需要注意一点zip -r archive.zip dir/才能递归打包目录。解压用unzip archive.zip -d /target。Windows 上传过来的 zip 包在 Linux 下中文文件名可能乱码这是编码问题和 zip 本身无关。给 Windows 团队发压缩包时我一般特意用 zip 格式而不是 tar.gz就是为了省掉对方解压工具不兼容的尴尬。tar还有一个少为人知但实用的参数--exclude。打包时可以排除指定目录比如tar -czf /tmp/app.tar.gz /data/app --exclude/data/app/logs --exclude/data/app/cache --exclude*.tmp。这样打出来的包体积小很多还原到新环境时也不会带进一堆缓存和日志垃圾。这个参数在迁移项目时太常用了。5. 系统管理里绕不开的几件事文件操作、文本处理、搜索和压缩基本把和文件打交道的场景覆盖了。但标题里还有系统管理四个字这意味着你还需要处理用户、时间、进程这些系统层面的日常。这里挑两个高频操作展开一是用户与权限的日常管理二是时间同步与后台任务。这两类问题几乎每个 Linux 管理员都躲不开而且出错的后果都很隐蔽。5.1 用户与权限的日常管理新建用户说简单也简单一条useradd就完事但实际生产中要做的远比这个多。useradd bob默认创建用户bob和同名用户组但不会建家目录、不会设置密码、也不会给你配置 shell。所以一条合格的新建可用用户命令一般是useradd -m -s /bin/bash bob passwd bob-m创建家目录-s指定登录 shell。不加-s的话系统默认可能是/bin/sh功能差不少用户和系统管理员配合排查问题时经常发现怎么 history 不生效就是 shell 不对。用户建好后用id bob查看 UID、GID 和所属组这是一个最基础的验证操作。给用户加附加组用usermod -aG groupname bob注意-aappend一定要带上不带的话会用新组列表覆盖掉用户原来的附加组我已经见人把管理员自己从sudo组里提出来后叫苦连天。生产环境里给应用创建专用账号是常规操作不要所有服务都拿 root 跑。跑 Nginx 用nginx用户跑 MySQL 用mysql用户运行权限最小化原则能挡住很多不该有的风险。删除用户时userdel -r bob可以连家目录和邮件池一起删但如果用户目录下还有重要数据千万别手快。更安全的做法是先锁账号usermod -L bob或passwd -l bob等确认数据备份完毕后再删。真实事故里删用户连数据一起删的情况屡见不鲜。sudo权限是另一个高频区。查看当前用户有哪些 sudo 权利用sudo -l给用户加 sudo 权限要把用户加入wheelRHEL/CentOS 系或sudoDebian/Ubuntu 系组。还有一种更精细的玩法是直接编辑/etc/sudoers但必须用visudo命令打开不要直接 vim因为 visudo 保存时会做语法检查能避免写坏 sudoers 导致整个 sudo 系统瘫痪。5.2 时间同步与后台任务两类容易焦虑的操作时间同步这事儿平时谁都不注意一出问题就是大事故。最典型的场景是服务器时间比真实时间慢了几分钟HTTPS 证书校验直接失败或者日志里的时间戳和告警平台对不上排查到怀疑人生。Linux 系统里现在主流的时间同步方案是chrony传统 NTP 协议已经被它逐渐取代。检查当前时间同步状态用timedatectl它会输出系统时间、时区、NTP 同步状态。如果NTP synchronized: no说明时间没在同步需要启动chronyd服务并确认timedatectl set-ntp true。临时校准一次可以直接chronyc makestep强制立即步进校正。在生产环境里我见过因为时间偏差导致数据库主从复制报错、消息队列延迟告警的案例所以机房里的服务器时间同步状态应该纳入日常巡检项。和文件操作一样很多时候你会遇到终端一关命令就断的问题用 SSH 登录服务器跑一个需要几分钟甚至几小时的命令结果网络闪断命令随之终止。这就是著名的前台进程挂到终端问题。解法是nohup加nohup sh long_task.sh task.log 21 这个组合里nohup让进程忽略 SIGHUP 信号终端关闭时系统给进程发的挂断信号把进程丢到后台 task.log 21把标准输出和错误输出都重定向到日志文件。这样即使你退出 SSH任务也会继续跑。如果任务已经在跑了才发现忘了加nohup可以按CtrlZ暂停进程再执行bg把它转为后台然后用disown把它从 shell 的任务表里摘除这样它就不会在终端退出时被清掉。有个更现代的工具叫screen或tmux它们相当于给终端开了多窗口 会话保持。tmux new -s work新建会话Ctrlb d脱离会话但任务继续下次tmux attach -t work重新接回。这个比nohup更舒服的一点是你能随时回到那个会话里看输出、敲命令而不是只能靠日志文件单向观测。长任务如数据库迁移、大数据导出我基本都放 tmux 里跑方便又安全。6. 常见问题与排查技巧实录讲到这前面已经把核心命令和用法过了一遍。但现实中的问题从来不是用哪个命令这么简单更多是命令用了但不生效、报错看不懂、结果和预期不符。这一部分整理我在实际运维里遇到的高频问题做成速查表再分享几条亲测有效的排错思路。6.1 典型故障速查表现象常见原因快速排查/解决命令rm提示 Permission denied 但自己是 root文件处于只读文件系统或chattr i锁定lsattr file查看属性chattr -i file解除锁定cp保留不了软链接用了cp -r而不是cp -a改用cp -atar解压报 Cannot open: No such file用错了压缩算法标志先file archive.tar.gz看实际类型再选解压参数grep搜不到明明存在的内容文件是二进制格式或编码异常先file看类型必要时用grep -a强制按文本处理find大量输出 Permission denied普通用户遍历无权限目录加2/dev/null忽略错误输出或换 root 执行locate找不到刚创建的文件数据库未更新sudo updatedb时间不对导致 HTTPS 报证书错误NTP 同步异常timedatectl检查chronyc makestep强制校准sudo报 command not found用户 PATH 不完整检查/etc/sudoers的secure_path后台任务在 SSH 断开后消失没加nohup或没用 tmux重新用nohup cmd log 21 启动磁盘明明满了但du统计不大已删除文件被进程占用lsof L1列出占用未释放空间的进程重启或 kill 该进程这是一张我工作中自用的速查表前三条和后几条都是我踩过的实坑。其中磁盘明明满了但 du 统计不大最值得展开Linux 里文件被删除后只要还有进程持有该文件的句柄空间就不会释放。df -h显示使用率 100%du -sh *却找不到大文件对策是lsof | grep deleted找到那些已经被删但还被进程占用的文件根据 PID 重启对应服务或用/proc/PID/fd/下的软链接找到占用文件名。这个问题在删日志、删大文件时非常常见。6.2 几条亲测有效的排错思路在实际工作里比背命令更重要的是有一个稳定的排错思路。我总结一下自己排查问题时的固定路线对新手应该很有参考价值。第一先确认路径对不对。很多命令失败都是因为路径写错、相对路径在当前目录下不成立。排查路径问题最快的方法是用ls走一遍ls -l一步步确认文件存在且类型正确别直接执行修改命令。我见过太多因为手滑把/data写成/data/导致 find 结果范围错误的坑路径首尾细节真的能害人。第二优先看错误信息不要急着改配置。/var/log/messages、journalctl -xe、应用自己的日志永远是第一手证据。报错信息里往往直接告诉你缺什么依赖、哪个文件权限不对、哪台主机连不上。用journalctl -u 服务名 --since 10 minutes ago看某个 systemd 服务最近的日志比打开整个系统日志大海捞针高效得多。第三复现问题要最小化。如果某个脚本在服务器上失败了先在本地或测试机用一个小样本复现。比如find命令批量操作报错就先挑一个文件跑一遍确认无误后再全量执行。脚本里如果想观察每一步执行情况在脚本顶部加set -x这样每条命令执行前都会打印出来直观地看到变量到底被展开成了什么很多奇怪报错瞬间就明白了。第四命令不生效先想想缓存。系统里有很多看起来不生效其实是缓存或延迟导致的情况locate数据库没更新、DNS 缓存、selinux 拦截、systemd unit 修改后没daemon-reload。改完服务配置后第一反应应该是systemctl daemon-reload再systemctl restart 服务名别纠结配置是不是写错了。最后所有对生产环境有影响的操作执行前先问自己一句能不能撤销能撤销的话怎么撤销备份文件、快照、软链接回滚至少留一条后路。日常养成这个习惯能少掉很多头发。我自己做运维这些年最深的体会是Linux 命令从来不是背得越多越好而是用得越准越好。与其死记几百条命令参数不如把文件操作、文本处理、搜索、压缩这四条主线上的核心命令吃透再把排错思路理顺。日常八九成的工作靠的就是这套基本功。真遇到没见过的问题man手册、--help输出和系统日志才是你最值得依赖的师傅。
阅读完成 · 觉得有帮助？
