企业官网建设流程全解析

1. 先搞懂系统管理的排查逻辑：命令是手段，定位问题是目的

干运维和系统管理这行，绕不开的就是一堆系统管理命令。不少刚入行的朋友来找我聊，第一句话往往是“Linux命令太多了，根本记不住怎么办”。我的回答一直很直接：别去背命令，去背思路。命令只是个工具，真正值钱的是你拿到一台机器时，知道从哪儿下手、每一步在验证什么。只要思路清晰，命令选项记不全说白了一眼man手册的事，但反过来，就算命令背得滚瓜烂熟，机器一有问题就乱敲一通，那跟拿着扳手不知道修哪儿没区别。

这篇东西不是照着手册把Linux系统管理命令念一遍，那没意义。我想聊的是实际干活的时候，那些你每天都会碰到的场景：CPU飙高了怎么办、磁盘满了但是删了文件空间没回来、机器莫名其妙卡顿、端口起不来、日志刷得飞快等等。每个场景我会把用到的核心命令、怎么看输出、判断逻辑是什么、常见的坑是什么，一次性说透。适合刚接触Linux服务器管理的同学，也适合那些用了一段时间但总觉得差点章法的人。看完之后你至少能拿到一个属于自己的排查套路，而不是再靠运气修机器。

我自己平时工作里有个习惯：无论什么问题，先用一个一分钟的快速体检脚本定位方向，再针对方向深挖。这个习惯帮我省了非常多的无效操作。日常的体检其实就四类指标：负载（load average）、CPU使用率、内存和Swap、磁盘和IO。后面所有命令的组合，本质上都是这四类的延伸。先把大方向拿准，再决定用哪个Linux系统管理命令去追细节，效率比上来就抓着一堆工具乱试高得多。

2. 进程管理：系统卡不卡，先看谁在吃资源

2.1 top和ps的正确用法：CPU高和IO高要分清

Linux系统管理命令里，用得多也容易误判的就是进程查看这组。很多同学一看到机器卡，第一反应就是用 top 敲一下，瞄一眼 %CPU 最高的那个进程，就觉得找到元凶了。这个习惯我建议改一下，因为CPU高和IO高在 top 里长得不一样，而且痛点完全不同。

先看 top 最顶上那几行统计信息。load average 有三个数字，分别代表1分钟、5分钟、15分钟的平均负载。这里有个极其常见的误区：负载高不等于CPU忙。负载衡量的是处于可运行状态和不可中断睡眠状态的进程数。不可中断睡眠状态通常就是等IO。所以当你看到 load average 飙到四五十甚至上百，但 %Cpu(s) 这行的 us 占比并不高，反倒 wa 也就是 iowait 很高，说明IO才是瓶颈。

这时候按 x 键加高亮，按 b 键加粗，能看到当前排序的列。P键按CPU排序，M键按内存排序。当你确定是CPU瓶颈时，重点看 %CPU 列。但注意了，top 里的 %CPU 默认是进程自启动以来总的CPU时间占用的平均值，不是瞬时的。所以一个进程如果之前吃得猛，现在早不忙了，它照样会排在最上面误导你。遇到这种情况我习惯按一下 shift + i 切换成 irix 模式关掉，或者干脆用 top -p 盯具体PID，再配合 top -H -p PID 看这个进程内部哪个线程在吃资源，这是排查多线程服务CPU飙升的标准操作。

ps 这命令在Shell脚本里比交互式的 top 用得多。平时排查我常用的组合是 ps -eo pid,ppid,user,%cpu,%mem,rss,vsz,stat,etime,cmd --sort=-%cpu。这里解释几个容易忽略的字段。RSS是物理内存占用，单位是KB，VSZ是虚拟内存，很多同学看VSZ大就觉得内存泄漏，其实虚拟内存大很正常，重点盯RSS。STAT这列的值建议背下来：R是运行，S是睡眠，D是不可中断睡眠，Z是僵尸。其中D状态的进程多见于IO等待，Z状态说明父进程没好好回收子进程，处理不好会累积成内存泄漏。

2.2 排查进程的实战细节：环境变量、启动目录和端口对应关系

进程管理的另一个高频需求是“这玩意到底是谁拉起来的”。很多线上事故查到最后，都是因为搞不清进程的真实归属和启动方式。遇到这种情况，我会按下面这个顺序往下查。

第一个用 pstree -ap 看进程树。它能直接展示父子关系，一眼看出哪个进程是哪个拉起来的，也能辅助判断是不是出现了进程的异常衍生。之前遇到过一台机器上莫名其妙多了一堆同名进程，pstree 一看全是某个服务的子进程没退干净，问题定位快得不是一点半点。

接下来是 /proc 文件系统，这是Linux排查的神器。查进程的启动命令，用 ps -p PID -o cmd 能看到完整命令行，但这个可能被人为改过。更可靠的是直接读 /proc/PID/cmdline 文件，这个文件里参数是用 \0 分隔的，用 xargs -0 处理一下就能还原出原汁原味的启动命令。想知道进程的启动目录，去看 /proc/PID/cwd 这个符号链接；想知道进程可执行文件的真实路径，看 /proc/PID/exe，它能穿透符号链接直接指向真实文件。这些都是日常排查里非常重要的Linux系统管理命令技巧。

还有一个容易被忽略的：端口和进程的对应关系。服务起不来，最常见的原因就是端口被占了。以前大家都用 netstat -tlnp，现在我一般直接推荐 ss -tlnp。ss 命令读取的是内核socket信息，比netstat快得多，在大并发连接下优势尤其明显。输出里最后一列能看到进程名和PID，如果是别的用户起的进程你可能看不到PID，那就要么切root，要么用 lsof -i:端口号 来看。lsof 的优势是能列出所有打开这个端口的文件描述符细节，但 lsof 在高负载下偶尔会卡，因为要遍历所有进程的fd目录。

3. 磁盘和文件系统：空间、Inode、IO三件事分开查

3.1 df和du的区别：为什么删了大文件空间还是满的

磁盘排查是Linux系统管理命令里最容易出现“灵异事件”的场景。最常见的现象是：du统计出来文件一共就占了几十GB，df一看磁盘用了90%多，或者明明删了一个大文件，df显示磁盘还是满的。这些现象背后其实是两个命令工作层次不同造成的。

df 查的是文件系统层面，它看的是整个分区的块使用情况，包括元数据、预留块，以及那些已经被删除但还被进程占用的文件。du 查的是目录树层面，它逐个统计目录下的文件大小。所以 du 算出来的是一个“逻辑”上的目录占用，df 看到的才是“物理”上文件系统块的真实分配情况。

du 统计慢的问题就没必要吐槽了哈。当你发现文件系统空间满了，别着急删文件，先按下面这个顺序排查。第一步，df -h 看哪个分区满了。第二步，用 du -sh /目录/* 或者 du -h --max-depth=1 找大目录，这个命令我基本每天都要敲几次，写脚本时也常用 du -s 拿总值。第三步是个关键点：如果你发现删除了文件但空间没释放，用 lsof +L1 查看所有被删除但还在被进程占用的文件。这条命令会把所有 link count 为0但还被进程持有fd的文件列出来，绝大多数“删了空间没回来”的问题都出在这。确认之后，重启对应的服务进程，或者直接 kill 掉持有者，空间立刻就回来了。

3.2 Inode和IO瓶颈：df不报警不代表磁盘没问题

还有一类问题是空间明明有富余，但系统报“No space left on device”，这个时候基本就是Inode用完了。Inode可以理解成文件系统给每个文件分配的一个索引节点，它记录文件元数据。df -i 查看Inode使用率，当已用100%时，即使有剩余空间也创建不了新文件。清理方法很简单：找小文件特别多的目录，比如邮件队列、临时目录、Docker的overlay目录，用 find /目录 -xdev -type f | wc -l 统计数量，再用 find /目录 -xdev -type f -size 0 -delete 批量删除空文件。生产环境尤其是消息队列、定时任务日志那种一天产生几十万个小文件的场景，Inode耗尽比空间耗尽更常见，监控的时候一定不要漏掉 df -i。

磁盘性能这块，iostat 是我首选的工具。安装 sysstat 包之后就能用。iostat -x 1 每秒刷新一次，重点看 %util 和 await。但这里有个坑要提醒，%util 高不代表磁盘坏了，它只表示设备有IO请求在排队的时间占比。像高并发随机读写的时候，%util 100%其实是正常的，关键要看 await（平均IO响应时间）和 svctm 对比。当 await 远大于 svctm，说明有大量请求在队列里等着，磁盘确实忙不过来；如果两者差不多，说明磁盘本身处理能力没问题，可能是请求太密集了。更细一点可以用 iostat -d -x 看每块磁盘的读写吞吐量 rMB/s 和 wMB/s，配合 iostat -k 1 缩短时间粒度观察趋势。

3.3 大文件搜索和清理策略：别把时间浪费在一通乱找上

在实际工作中，定位大文件我有一套自己的方法。先用 df -h 确认哪个分区满了，这步不用多说。然后用 du -h -x --max-depth=1 /分区挂载点 2>/dev/null | sort -rh | head -20 来快速圈定大目录。这里的 -x 参数很重要，它让 du 不跨文件系统，避免把其他挂载点也算进来，这种细节在实际干活的时候很关键。

圈定大目录之后再往下走一层，用 find /路径 -xdev -type f -size +500M -exec ls -lh {} ; 来列出具体的大文件。这里也用了 -xdev，好处一样，不遍历其他挂载点。找到大文件之后，先确认这个文件是否还被进程占用，用 lsof /路径/文件名 来确认。如果文件被占用且可以直接重启服务，那就重启；如果不方便重启，可以用 : > /路径/文件名 这个技巧，把文件内容清空而不是删除。这样既释放了空间，又不影响继续写文件的进程。

我处理临时文件还有个习惯：定期用 find /tmp /var/tmp -type f -atime +7 -delete 这类命令清掉超过一周没访问的临时文件。但在生产环境要格外小心，最好先加上 -mtime 或 -atime 的条件，并且先跑一遍 find 不带 -delete 看看结果，确认没有误删风险再执行。

4. 内存和Swap：free看的是门道，vmstat看的是趋势

4.1 free输出逐行解读：available才是有意义的数字

内存管理是Linux系统管理命令的另一大阵营。free -h 这条命令的输出，网上讲烂了，但我发现大部分人其实就被 buff/cache 给唬住了。机器可用内存显示只剩几百MB，立刻开始慌了，觉得内存不够了。真不是这样。

Linux内核的页面缓存策略是“空闲内存拿来用，别闲着”。你把文件读一遍，这些数据就会进入 page cache，free 命令里显示为 buff/cache，它们看着占用了内存，但只要应用程序真正需要更多内存，内核会立刻回收这些缓存分配给程序。所以真正的可用内存看的是 available 这一列，不是 free 那一列。available 是内核估算出的，在不触发Swap的情况下还能分配多少内存给进程。我平时判断一台机器内存够不够，优先看 available，而不是被那个很小的 free 吓着。

如果 available 一直在缩水，同时 free 列无限接近0，这时就要结合 Swap 来看。free -h 里 Swap 的 si 和 so 解释一下：Swap里的 used 不为0是正常的，说明之前有一波内存高峰被换出去了，不代表现在有问题。但如果你发现交换分区被大量使用，并且系统的可用内存也持续偏低，那就要警惕了。一个判断依据是看Swap的占用趋势，如果持续增长而不是回落，基本可以断定有进程在大量吃内存，或者更糟，出现了内存泄漏。

4.2 vmstat和内存排查实操：从趋势里读出问题

vmstat 是快速定位系统整体健康状态的利器。用法是 vmstat 1 5，每隔1秒采样一次，共采5次。重点看 procs 区域的 r 和 b。r 代表正在运行和等待CPU的进程数，长期大于CPU核数说明CPU饱和；b 代表处于不可中断睡眠的进程数，长期很大说明IO阻塞严重。内存这块看 si 和 so，它们的含义是 swap in 和 swap out 每秒的数据量，持续非0说明系统在频繁换页，内存基本告急，性能已经大打折扣了。

用 vmstat 观察趋势比揪着一个瞬间看更有意义。我最常干的事就是 vmstat 1 连续刷几十秒，观察 si/so 是不是间歇性飙升，观察 r 列是不是随着负载在涨。结合 free -h 的 available，能拼出一个比较完整的内存压力变化图。

追到进程级别之后，第一梯队还是 top 按 M 排序，看哪个进程的 %MEM 和 RES 列高。到了这一步还没法区分是内存分配过多还是泄漏，那就得用 pidstat -r -p PID 1 持续监控进程的内存变化。这条命令会周期性输出 minflt/s 和 majflt/s，也就是进程的缺页中断次数。持续观察 RSS 只涨不降的话，内存泄漏基本就坐实了。更专业的可以用 valgrind 做内存检测，但那东西跑起来太慢，生产环境一般用不上，最多在测试环境复现问题用一下。

4.3 cache回收和OOM机制：什么时候要出手，什么时候别乱动

有时候确实需要手动释放缓存。比如刚做完一个大文件的归档操作，page cache 被塞满，导致其他应用申请不到足够内存。用 echo 1 > /proc/sys/vm/drop_caches 可以只释放page cache，echo 3 是释放page cache和dentries、inodes。但这东西我劝你谨慎用。平时生产环境别没事就去释放缓存，你释放了缓存，应用后面又要重新读磁盘，反而更慢。只有当你有充分的理由，比如批处理任务刚跑完，需要给马上要来的高峰腾内存，才值得操作。操作前最好先 sync 一下，把脏页写回磁盘，然后再清，虽然echo本身就会触发sync，但手动sync多一道保险。

内存严重不足时，Linux会启动OOM Killer。这个机制本身很粗糙，它按坏分度选进程杀，结果往往是杀了最不该杀的那个。所以关键进程的OOM保护务必要做。给关键服务设置 -1000 的oom_score_adj，写在systemd服务配置的 OOMScoreAdjust 字段里，这样内核算出来的OOM分数就会很低，不到万不得已都不会动它。查看当前进程的OOM分数可以读 /proc/PID/oom_score。生产环境死得最多的其实就是数据库被OOM杀了，所以这一块我每次讲内存排查都会专门强调。

5. 网络排查：从连接状态到端口连通性一次理清

5.1 ss命令实战：连接状态统计和TCP状态详解

网络问题在Linux系统管理命令里占比不低。以前排查端口和连接信息，大家习惯了 netstat，但 netstat 慢而且很多发行版新版本默认不装了。我现在的习惯是无脑用 ss。ss -s 可以看整体的连接统计，包括TCP的各种状态数量、端口使用情况。这可以作为网络排查的第一步，快速判断当前网络连接量级和状态分布。

特别要关注的是 TCP 连接状态里的几个异常项。SYN_SENT 一直很多，说明你往外连的对方机器没响应，可能是对方挂了或者防火墙拦了。SYN_RECV 异常走高，基本都是半连接队列满了，往往是SYN Flood攻击或者连接负载太大。TIME_WAIT 多不是问题，TCP主动关闭方本来就要等2MSL保证旧报文消失，状态多说明短连接多，这是正常现象。真正需要担心的是 CLOSE_WAIT 大量堆积，这个状态是被动关闭方的问题，你发出FIN对方没回FIN，代码里没关闭连接，基本就是应用层连接泄漏了。用 ss -tan state close-wait 可以直接把处于CLOSE_WAIT的连接全部拉出来，再对端口的IP做个统计，看看是不是集中在哪个连接上。

5.2 端口排查和连通性测试：链路问题要按层拆

端口起不来的场景，前文说过用 ss -tlnp，lsof -i:端口 也能帮助确认端口被哪个进程占用。但有时候你会遇到这样的情况：ss 显示服务在监听端口，但外部就是连不上。这个时候不能只盯本机了，要从链路一层层排查。

先在本机测回环，curl 127.0.0.1:端口，通说明服务本身没问题，不通就是服务没监听或者防火墙拦截。再用 ss -tlnp 确认监听地址是不是 0.0.0.0 或 ::，如果写着 127.0.0.1，那外部当然连不上，改服务配置里的监听地址就行。接下来看防火墙，iptables -L -n 或 firewall-cmd --list-all 检查端口有没有被放行。很多人用 systemctl stop firewalld 然后发现连上了，排查就结束了。但生产环境这么干不是长久之计，正确做法是放行对应端口而不是关闭防火墙。

本机防火墙放行了还是连不上，就要看云平台或者物理网络设备的安全组和ACL有没有放行。这个环节常常让人抓狂，因为服务、防火墙、安全组三层都要检查一遍才排得下去。我的建议是按照“本机监听 → 本机防火墙 → 外部防火墙/安全组 → 目标主机回包路由”的顺序，一层层排除，不要跳步。

5.3 ping、traceroute、curl的配合使用：网络延迟和丢包怎么定位

说到连通性，ping 是最常用的工具。但 ping 通了不代表业务正常，ping 不通也不代表服务挂了。很多网络设备对ICMP有限速或者直接丢弃，我遇到过不少ICMP被禁但TCP正常的网络环境。所以判断链路通不通，我更习惯直接用实际端口的 TCP 连接测试。nc -zv 目标IP 端口 可以做一次 TCP 端口测试，或者用 curl -v telnet://目标IP:端口 也行，实在没有趁手工具用 /dev/tcp 也可以：timeout 3 bash -c "echo > /dev/tcp/目标IP/端口" 这种方式虽然粗糙，但很多精简环境里很管用。

网络延迟和丢包定位，traceroute 配合 ping -f 能看出大概的瓶颈段。但这个工具在运营商骨干网里经常被限制，走到后半段全是星号是常态。别慌，星号只代表那一跳不回应UDP探测，不代表断连，只要最后的终点能通就没事。如果用 traceroute -T -p 端口 来指定用TCP SYN探测，命中率会高不少。

丢包和延迟的问题，推荐继续用 mtr 来定位。mtr 相当于 traceroute 和 ping 的结合体，持续探测每一跳的丢包率。看 mtr 输出的经验是：只要最后一跳丢包率是0%，中间跳丢包哪怕高也不用太紧张，因为很多路由器对探测报文有单独的QoS策略，丢的是探测包，不丢数据包。如果最后一跳的丢包率跟着上去了，那才是真的链路有问题。这套判断逻辑我用过太多次了，第一次带新人的时候，他们看着全程30%丢包慌得不行，我让他们看最后一跳，一眼就明白怎么回事了。

6. 日志和综合实战：把命令串起来解决一个完整问题

6.1 journalctl和日志分析：系统日志是排障的第一现场

应急响应的时候，别光顾着看资源占用，日志才是判断问题根因的第一现场。现在主流的系统发行版都用 systemd，日志体系也统一到了 journald。journalctl 这个命令的重要性怎么强调都不为过。日常排查我常用的几个参数：journalctl -u 服务名 查看单个服务的日志，-f 实时跟踪，--since "1 hour ago" 按时间过滤，-p err 只看错误级别以上的日志。这几个组合用能覆盖大多数场景。

systemd 日志有个特点：它默认把日志写到内存里，也就是 /run/log/journal，重启之后之前的日志就丢了。所以重要机器的持久化日志配置要提前做。在 /etc/systemd/journald.conf 里把 Storage 改成 persistent，日志就会写到 /var/log/journal。日志疯长的问题也要防，同文件里 RateLimitIntervalSec 和 RateLimitBurst 是限流参数，SystemMaxUse 控制日志最大占用磁盘空间。超过阈值会触发日志轮转，但轮转本身也是IO操作，会被系统限流，如果日志量实在太大，系统会直接丢日志以保护主流程，这个机制叫journald的背压保护。知道这个机制之后你就不会奇怪为什么某些关键时刻日志反而断了，那是系统在做自我保护，不是bug。

传统的 /var/log/messages 或 /var/log/syslog 仍然有参考价值。不管用哪种，排查日志的基本功是 grep 过滤和上下文查看：先 grep "关键字" 找到时间点，再用 grep -A 10 -B 5 看匹配行前后的上下文。排查程序崩溃、串扰、权限问题这些场景，日志都提供了直接证据。很多线上事故最后复盘，都把“日志没看全”列为第一教训，真不夸张。

6.2 一个完整案例：degraded状态下的系统救援实战

把前面这些Linux系统管理命令串起来用，机会来的时候别慌。我之前处理过一台状况很糟的机器，表现是系统异常缓慢，服务频繁超时，连SSH都偶尔卡顿。当时我用的排查顺序正好能串起这篇文章讲的大半内容。

第一步看负载。uptime 显示 load average 在30以上，但CPU核心只有8个，负载和核心数严重不成比例。第二步用 top 和 vmstat 定位，发现 us 占比不高，context switch 也没异常，倒是 vmstat 的 wa 列长期在50%以上，b 列还有不少进程在睡眠状态。到这里基本能判断是IO瓶颈了。第三步用 iostat -x 1 看磁盘，发现某块数据盘的 %util 接近100%，await 到了几百毫秒，svctm 只有十几毫秒。这个对比说明设备本身响应不行，大量的请求在排队。

接下来就涉及到一个问题：这台机器的存储层用的是RAID阵列，系统提示阵列状态degraded，也就是降级运行。我马上用 cat /proc/mdstat 检查，发现确实有一块盘被踢出了阵列。这种状态下整个磁盘阵列以冗余模式全量重建数据，IO当然被拖垮。确认了根因之后再处理：先找维护窗口，把备用盘做替换，触发阵列重建，重建期间把系统负载降到最低，把非核心服务全部停掉，保证重建IO能跑满优先恢复冗余。整个过程我按着“看负载→分方向→查IO→确认根因→定向处置”这个逻辑推进，没有花太多无效操作。如果是新同学遇到同样的情况，很容易在CPU占用率和内存占用上打转，磁盘层面反而被忽略了，那问题就不好定位了。

6.3 快速检查脚本思路：把日常体检固化下来

排查手法和命令掌握得再熟练，每次出问题都在现场手敲一遍也效率太低。我自己维护了一套快速体检脚本的思路，分享给你们参考。核心就是在一百多秒内把系统四大块的状态打印出来，作为第一手证据留存，之后再展开排查也更有底。

脚本内容其实不复杂：先用 uptime 确认Load；free -h 和 df -h 看内存和空间；vmstat 1 3 看CPU、IO、中断趋势；ss -s 看连接状态分布。再加一个最近几条系统错误日志的查询，journalctl -p err --since "10 minutes ago" -n 20。这些命令组合起来就是个标准体检包。脚本跑完，输出的结果直接沉淀成现场记录，之后复盘也有据可依。

这个脚本不需要很复杂，关键是形成肌肉记忆。针对每种异常类型，可以再准备一份更细的命令手册：比如性能问题看 pidstat、mpstat，IO问题看 iostat、iotop，网络问题看 ss、sar -n DEV，文件系统问题看 df -i、find 大文件。把这些组合梳理清楚，配合日常脚本，处理问题的速度能上一个台阶。

7. 实操心得和踩坑记录

7.1 高负载现场最忌讳的操作：别急着重启

最后聊一些很难从文档里学到的实战心得。第一件事，高负载现场别急着重启。我见过太多次了——机器卡了，反应不过来，第一反应就是重启。但重启意味着去现场的所有现场数据都没有了：内存里的状态没了、进程的痕迹没了、日志可能也没及时落盘。除非机器已经完全失去响应且业务影响在扩大，否则第一时间应该是做现场快照，把能采集的信息都采集下来，比如 top -b -n 1 的输出存到文件、ss -s 快照、/proc/meminfo 的备份，这些都是事后分析的宝贵证据。

第二件事，IO延迟高的机器上少跑 du 这类遍历命令。这是个绕不开的自我矛盾：机器IO已经堵死了，你还跑个 du 去全盘遍历，等于火上浇油。最好的做法是用之前提到的 find 配合 -xdev 限制范围，或者直接用 df 先看个大概，实在需要精确定位再小范围扫。

7.2 无效命令组合和时间浪费：把操作顺序理顺

第三个心得是操作顺序。举例说明，你拿到一个系统缓慢的问题，正确顺序是先看 uptime 的负载和对应的核心数，判断负载是否异常；再看 vmstat 的 r、b、wa 几列快速确认CPU还是IO；然后才用 top 和 ps 去定位具体进程。很多人一上来就 ps aux --sort=-%cpu，看到个高CPU进程就当根因，结果白白绕了一圈，甚至误判方向。操作顺序理顺，排障效率会肉眼可见地提升。

还有一个平时不注意的坑：top 显示的不是真实瞬时占用。这个问题前文提过，但值得再强调一次。排查CPU飙升时，一定要用 top -H -p PID 看线程级别，或用 pidstat -p PID 1 精确到实时采样。否则你把之前的耗时进程指认为元凶，清半天发现没效果，时间全浪费了。

7.3 命令超时和权限陷阱：非交互环境下的保命技巧

非交互环境下的运行策略也是必修课。写定时任务、告警脚本的时候，所有命令都要考虑超时问题。比如 du、find、tar 在大型目录上可能跑很久，我们在脚本里统一用 timeout 300 命令 这样的形式包一层，超过5分钟就强制结束，避免脚本挂死导致连锁反应。还有一个容易踩的坑：cron 环境下 PATH 环境变量不一样，有的在交互Shell里能用的命令到cron里就“command not found”。解决方法是脚本开头 export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin，或者直接用命令的绝对路径。这些细节平时不起眼，真出事了才知道有多重要。

权限陷阱也要单独提一嘴。很多系统信息在root下才能看到全貌，比如其他用户进程的环境变量 /proc/PID/environ，非root只能看到一部分。但sudo 也不能无脑用，sudo cat /proc/sys/vm/drop_caches 直接执行会报错，因为重定向是shell做的，shell没有root权限。正确写法是 echo 3 | sudo tee /proc/sys/vm/drop_caches。这类小坑遇到了就知道，但在现场临时查很耽误工夫，提前记住能省很多事。