企业官网建设流程全解析

1. 服务器命令大全：从零散记忆到体系化运维的实战拆解

刚接手一批新机器的时候，我习惯性地打开终端敲下uptime，看到负载那一栏的数字，心里大概就有底了。这个动作几乎成了肌肉记忆，就像老司机上车前绕车一圈看看轮胎。服务器命令这东西，说它是运维的基本功一点都不为过，但真正能把常用命令用出体系感的人其实不多。大多数人包括我自己早期，都是遇到问题现查，查完就忘，下次再遇到类似场景又得重新翻笔记。这种状态持续了挺长时间，直到有一次线上服务响应变慢，我在十几台机器之间来回切换排查，才意识到零散的命令记忆根本撑不起一次完整的故障定位。

所谓“服务器命令大全”，表面上看是一份命令清单，但它的核心价值在于把散落在各个角落的操作指令，按照实际运维场景重新组织起来。它解决的不是“这个命令怎么拼”的问题，而是“面对这个现象我该按什么顺序敲哪些命令”的问题。适合谁来参考？刚入行的运维新人可以把它当作操作手册，有一定经验的工程师可以拿它当速查表，开发同学如果想了解自己部署的服务在系统层面是什么状态，也能从中找到对应的排查路径。我自己在带新人的时候，最常说的就是：别急着背命令，先搞清楚你要回答什么问题，命令只是你向系统提问的方式。

这篇文章我会按照实际工作中最常见的几类场景来组织内容，把命令嵌入到具体的操作流程里，而不是简单地罗列。每个命令我会尽量说清楚它回答的是什么问题、输出里哪些字段值得关注、什么情况下该用它而不是别的。中间会穿插一些我踩过的坑和总结出来的小技巧，这些东西在官方文档里通常不会写，但实际干活的时候往往能省下不少时间。

2. 系统状态与资源监控：先搞清楚机器在干什么

2.1 负载与运行时间的快速判断

uptime这个命令我每天至少敲一次，输出很短但信息密度很高。它告诉你当前时间、系统运行了多久、登录用户数，以及过去1分钟、5分钟、15分钟的平均负载。很多人只看第一个数字，其实三个数字的对比更有意义。如果1分钟负载很高但15分钟负载很低，说明是突发流量，可能某个定时任务或者临时请求导致的；反过来如果三个数字都很高且接近，那说明系统已经持续处于高压状态一段时间了，需要认真对待。

负载数值本身要结合CPU核心数来看。单核机器负载到1就已经满载了，四核机器负载到4才算满载。我见过有同学看到负载是2就紧张得不行，结果一查机器是16核的，实际上系统还很空闲。所以判断负载是否正常，第一步永远是先确认核心数，nproc或者lscpu都能看到。

# 查看CPU核心数 nproc # 查看负载 uptime # 更直观的负载查看方式 cat /proc/loadavg

/proc/loadavg的输出比uptime多了一个信息：正在运行和等待运行的进程数。第四个字段的分子是当前正在运行的进程数，分母是总进程数。如果分子持续大于核心数，说明有大量进程在排队等CPU。

2.2 内存与交换分区的真实使用情况

free -h是最常用的内存查看命令，但它的输出有个容易让人误解的地方。free那一列显示的是完全未被使用的内存，而available那一列才是真正可用的内存估算值。Linux系统会把大量内存用作文件缓存，这部分内存在应用程序需要时可以被快速回收，所以看内存是否充足应该主要关注available这一列。

free -h # 输出示例 # total used free shared buff/cache available # Mem: 15Gi 3.2Gi 1.1Gi 256Mi 11Gi 12Gi # Swap: 2.0Gi 0.0Ki 2.0Gi

Swap的使用情况也值得关注。如果swap被大量使用，说明物理内存已经不够了，系统正在用磁盘模拟内存，性能会明显下降。但要注意，有些系统默认swappiness值比较高，即使内存充足也会把一些不常用的页换出去，所以看到swap有少量使用不必过于紧张，关键看是否持续增长。

我个人的经验是，如果available低于总内存的10%，同时swap使用量在持续上升，那就需要警惕了。这时候可以用ps aux --sort=-%mem | head -20看看是哪些进程占用了大量内存。

2.3 磁盘空间与inode的排查思路

磁盘满了是运维最常见的故障之一，但“磁盘满”其实有两种情况：空间满了和inode满了。df -h看的是空间使用情况，df -i看的是inode使用情况。inode是文件系统用来记录文件元信息的数据结构，每个文件至少占用一个inode。如果系统里小文件特别多，可能出现空间还有富余但inode已经耗尽的情况，这时候新建文件会失败，但df -h看起来一切正常，很容易让人摸不着头脑。

# 查看磁盘空间 df -h # 查看inode使用情况 df -i # 查看当前目录下各子目录的大小 du -sh * | sort -rh | head -20

du -sh *这个命令在排查磁盘占用时非常实用，但它有个缺点：如果目录下文件数量巨大，执行会很慢。我一般会先cd到占用最高的分区根目录，然后用du -sh *逐层往下找。另一个技巧是用find命令直接找大文件：

# 查找当前目录下大于100M的文件 find . -type f -size +100M -exec ls -lh {} \;

注意：du和df的结果有时会对不上，这通常是因为有进程持有已经被删除的文件句柄。用lsof | grep deleted可以找到这类文件，重启对应进程就能释放空间。

2.4 进程与端口：定位具体服务的状态

知道系统整体状态之后，下一步往往是确认某个具体服务是否在正常运行。ps aux | grep 服务名是最直接的方式，但grep本身也会出现在结果里，所以更精确的写法是ps aux | grep [服]务名，用方括号把服务名的第一个字符包起来，这样grep进程就不会匹配到自己。

# 查看进程详情 ps aux | grep [n]ginx # 查看进程树 pstree -p # 查看端口监听情况 ss -tlnp # 查看某个端口被哪个进程占用 ss -tlnp | grep :80

ss命令已经基本取代了老旧的netstat，速度更快，输出也更清晰。-t表示TCP，-l表示监听状态，-n表示不解析服务名，-p表示显示进程信息。这几个参数组合起来，基本能满足日常排查需求。

如果要看某个进程打开的文件和网络连接，lsof -p PID是利器。比如怀疑某个进程有异常的网络连接，可以用lsof -p PID | grep TCP来过滤。不过lsof在连接数很多的时候输出会非常长，建议配合grep或者head使用。

3. 文件与目录操作：日常最高频的动作

3.1 查找文件的几种姿势

find是文件查找的瑞士军刀，但参数多容易记混。我常用的组合有这么几个：按名称查找用-name，按类型查找用-type，按时间查找用-mtime，按大小查找用-size。这几个参数可以组合使用，比如找三天前修改过的日志文件：

# 查找三天前修改过的.log文件 find /var/log -name "*.log" -mtime +3 -type f # 查找并删除七天前的日志 find /var/log -name "*.log" -mtime +7 -type f -delete # 查找并压缩 find /data -name "*.csv" -mtime +1 -exec gzip {} \;

-exec后面的{}代表找到的文件名，\;是结束符。如果找到的文件很多，用+代替\;可以让find把所有文件名一次性传给命令，效率更高：

find /data -name "*.tmp" -exec rm {} +

另一个查找工具是locate，它基于预建的数据库，速度极快，但数据库不是实时更新的，新创建的文件可能找不到。可以用updatedb手动更新数据库，不过在繁忙的生产环境上要谨慎，因为更新过程会消耗一定的IO资源。

3.2 文本查看与实时监控

查看日志文件是运维的日常，tail -f是最常用的实时监控命令。但很多人不知道tail -F和tail -f的区别：-f是根据文件描述符追踪，如果文件被轮转（比如logrotate切走了），追踪会失效；-F是根据文件名追踪，文件轮转后会自动重新打开新文件。生产环境看日志，我强烈建议用-F。

# 实时追踪日志，文件轮转后自动切换 tail -F /var/log/app/application.log # 同时追踪多个文件 tail -F /var/log/app/*.log # 显示最后100行并持续追踪 tail -n 100 -F /var/log/app/application.log

less是查看大文件的利器，它不会一次性把整个文件加载到内存。在less里按G跳到文件末尾，按g回到开头，按/搜索，按F进入类似tail -f的实时追踪模式。这些快捷键用熟了之后，查看日志的效率会高很多。

grep配合tail可以快速过滤关键信息：

# 追踪日志并过滤ERROR tail -F /var/log/app/application.log | grep --line-buffered ERROR # 统计某个错误出现的次数 grep -c "OutOfMemory" /var/log/app/application.log # 显示匹配行的前后各3行 grep -B 3 -A 3 "Exception" /var/log/app/application.log

提示：grep --line-buffered在管道中很重要，不加这个参数的话，grep会等缓冲区满了才输出，导致看起来像是卡住了。

3.3 文件权限与属主调整

权限问题也是高频操作。chmod和chown大家都会用，但有几个细节值得注意。chmod -R递归修改权限时要特别小心，如果目录下文件很多，可能会卡住很久，而且一旦改错很难恢复。我一般会先用find确认范围，再执行修改。

# 只修改目录权限为755 find /data -type d -exec chmod 755 {} \; # 只修改文件权限为644 find /data -type f -exec chmod 644 {} \; # 修改属主 chown -R appuser:appgroup /data/app

umask决定了新建文件和目录的默认权限。默认的umask通常是022，意味着新建文件权限是644，新建目录是755。如果希望同组用户也能写入，可以把umask设为002，这样新建文件是664，目录是775。修改umask可以在/etc/profile或者用户的.bashrc里设置。

特殊权限位也值得了解：setuid让执行者临时获得文件属主的权限，setgid让执行者获得文件属组的权限，sticky bit在目录上设置后，只有文件属主才能删除自己的文件。这些在实际配置中偶尔会用到，比如共享目录通常会设置sticky bit。

4. 网络排查与连通性测试：从本机到远端

4.1 基础连通性测试

ping是最基础的网络测试命令，但很多服务器默认禁ping，所以ping不通不代表网络有问题。ping -c 4指定发送4个包就停止，避免一直刷屏。如果ping通但延迟很高，可以用ping -i 0.2加快发送频率来观察延迟波动。

# 发送4个包测试连通性 ping -c 4 目标地址 # 快速ping观察延迟稳定性 ping -i 0.2 -c 20 目标地址 # 指定包大小测试MTU ping -s 1472 -M do 目标地址

traceroute可以显示数据包经过的每一跳，用来判断网络在哪个节点出现了问题。不过很多中间节点不响应ICMP，所以看到* * *不一定代表有问题。mtr结合了ping和traceroute的功能，能持续统计每一跳的丢包率，判断网络质量更准确。

# 安装mtr yum install mtr -y # CentOS/RHEL apt install mtr -y # Debian/Ubuntu # 使用mtr mtr -r -c 100 目标地址

4.2 端口与DNS排查

telnet虽然老，但测试端口连通性依然好用。telnet 目标地址 端口如果显示Connected就说明端口通，如果一直卡着或者显示Connection refused就说明有问题。不过telnet在有些系统上默认没装，可以用nc -zv 目标地址 端口代替。

# 测试端口连通性 nc -zv 目标地址 80 # 测试UDP端口 nc -zuv 目标地址 53 # 扫描多个端口 nc -zv 目标地址 20-30

DNS解析问题也很常见。nslookup和dig都可以用来查询域名解析，dig的输出更详细。如果怀疑DNS解析慢，可以用dig +trace追踪整个解析过程，看看是哪一级的DNS服务器响应慢。

# 查询域名解析 dig 域名 # 指定DNS服务器查询 dig @8.8.8.8 域名 # 追踪解析过程 dig +trace 域名 # 查看本机DNS配置 cat /etc/resolv.conf

注意：/etc/resolv.conf在某些系统上会被网络管理服务自动覆盖，手动修改后重启网络可能就失效了。如果需要持久化DNS配置，应该修改对应的网络配置文件。

4.3 抓包与流量分析

tcpdump是命令行抓包的标配工具。最基本的用法是tcpdump -i eth0，但这会抓取所有流量，输出量巨大。实际使用中一定要加过滤条件：

# 抓取指定网卡上目标端口为80的包 tcpdump -i eth0 port 80 # 抓取指定主机的包 tcpdump -i eth0 host 192.168.1.100 # 抓取并保存到文件 tcpdump -i eth0 -w capture.pcap port 443 # 读取保存的抓包文件 tcpdump -r capture.pcap

抓包文件可以用tcpdump -r直接读取，也可以下载到本地用Wireshark分析。生产环境抓包要注意磁盘空间，长时间抓包可能把磁盘写满，建议加上-c限制包数量或者-w配合-C限制文件大小。

iftop和nethogs可以实时查看网络流量。iftop按连接显示带宽占用，nethogs按进程显示带宽占用。这两个工具在排查“谁在占用带宽”时特别有用。

# 安装iftop yum install iftop -y # 查看指定网卡的流量 iftop -i eth0 # 安装nethogs yum install nethogs -y # 按进程查看带宽 nethogs eth0

5. 服务管理与日志排查：让服务跑得稳

5.1 systemd服务管理核心操作

现在主流的Linux发行版都用systemd管理服务，systemctl是核心命令。启动、停止、重启、查看状态这几个操作大家都会，但有几个细节值得注意。systemctl status显示的是服务最近一次的状态，如果服务已经停止，显示的是停止时的状态。systemctl is-active只返回active或inactive，适合在脚本里判断。

# 启动服务 systemctl start 服务名 # 停止服务 systemctl stop 服务名 # 重启服务 systemctl restart 服务名 # 重新加载配置（不中断服务） systemctl reload 服务名 # 查看服务状态 systemctl status 服务名 # 设置开机自启 systemctl enable 服务名 # 查看服务是否开机自启 systemctl is-enabled 服务名 # 列出所有失败的服务 systemctl --failed

systemctl reload和restart的区别很重要。reload是让服务重新读取配置文件，不中断现有连接；restart是完全停止再启动，会中断服务。如果服务支持reload，优先用reload，对用户影响最小。但要注意，不是所有服务都支持reload，如果不支持，执行reload会报错。

查看服务日志用journalctl：

# 查看指定服务的日志 journalctl -u 服务名 # 实时追踪 journalctl -u 服务名 -f # 查看最近100行 journalctl -u 服务名 -n 100 # 查看指定时间段的日志 journalctl -u 服务名 --since "2024-01-01 00:00:00" --until "2024-01-01 12:00:00" # 按优先级过滤 journalctl -u 服务名 -p err

journalctl的日志默认是存在内存里的，重启就没了。如果要持久化，需要修改/etc/systemd/journald.conf里的Storage=persistent，然后重启journald服务。不过持久化会占用磁盘空间，需要根据实际情况配置轮转策略。

5.2 日志轮转与清理策略

日志文件如果不加管理，迟早会把磁盘撑满。logrotate是标准的日志轮转工具，配置文件在/etc/logrotate.d/目录下。一个典型的配置长这样：

/var/log/app/*.log { daily rotate 7 compress delaycompress missingok notifempty create 644 appuser appgroup postrotate systemctl reload appservice > /dev/null 2>&1 || true endscript }

这个配置的意思是：每天轮转一次，保留7份历史日志，压缩旧日志，延迟一天再压缩（因为当天写入的日志可能还在被进程持有），如果日志文件不存在也不报错，如果日志为空就不轮转，新建的日志文件权限是644，属主是appuser。postrotate脚本在轮转后执行，通知服务重新打开日志文件。

提示：delaycompress配合postrotate里的reload操作很重要。如果服务在轮转后没有重新打开日志文件，它会继续往已经被重命名的旧文件里写，新文件一直是空的。

手动清理日志时，千万不要直接rm正在被进程写入的日志文件。直接删除会导致磁盘空间不释放，因为进程还持有文件句柄。正确的做法是> 日志文件或者用truncate -s 0 日志文件清空内容。

5.3 定时任务与开机自启

crontab是定时任务的标准工具。crontab -l查看当前用户的定时任务，crontab -e编辑。时间格式是“分 时 日 月 周”，比如0 3 * * *表示每天凌晨3点执行。

# 查看当前用户的定时任务 crontab -l # 编辑定时任务 crontab -e # 查看其他用户的定时任务 crontab -u 用户名 -l

crontab有几个容易踩的坑。第一，crontab执行时的环境变量和登录shell不一样，PATH可能不包含你需要的命令路径，所以脚本里最好用绝对路径。第二，crontab的输出默认会发邮件，如果没配置邮件服务，输出会堆积在/var/spool/mail/里，时间长了可能占满磁盘。建议在crontab里把输出重定向到文件或者/dev/null。

# 每天凌晨3点执行备份脚本，输出追加到日志 0 3 * * * /bin/bash /opt/scripts/backup.sh >> /var/log/backup.log 2>&1

除了crontab，systemd的timer也可以做定时任务，而且日志管理更方便。不过crontab更简单直接，日常用足够了。

6. 性能分析与故障定位：从现象到根因

6.1 CPU性能分析

top是最常用的性能查看工具，但它的交互模式很多人没充分利用。按1可以展开显示每个CPU核心的使用率，按P按CPU使用率排序，按M按内存使用率排序，按c显示完整命令行。这些快捷键在排查问题时能快速定位到可疑进程。

# 启动top并只显示指定用户的进程 top -u 用户名 # 批处理模式输出一次 top -b -n 1 # 查看CPU使用率最高的前10个进程 ps aux --sort=-%cpu | head -11

vmstat可以查看系统的整体运行状态，包括进程、内存、交换分区、IO、CPU等。vmstat 1表示每秒输出一次。重点看r列（等待运行的进程数）和b列（不可中断睡眠的进程数），如果r持续大于CPU核心数，说明CPU是瓶颈。

vmstat 1 10 # 输出示例 # procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- # r b swpd free buff cache si so bi bo in cs us sy id wa st # 2 0 0 1234567 89012 345678 0 0 10 20 100 200 5 2 93 0 0

pidstat可以按进程查看CPU、内存、IO使用情况，比top更灵活：

# 每秒输出一次，共输出5次，显示CPU使用情况 pidstat 1 5 # 查看指定进程的IO情况 pidstat -d -p PID 1 5

6.2 内存与IO瓶颈判断

内存不足的典型表现是swap使用量上升、系统响应变慢。vmstat的si和so列分别表示从swap换入和换出的数据量，如果这两个值持续大于0，说明物理内存不够了。

IO瓶颈的判断可以用iostat：

# 每秒输出一次，共输出5次 iostat -x 1 5 # 输出中重点看 %util 和 await # %util 接近100%说明磁盘IO饱和 # await 是平均等待时间，单位毫秒，越大说明IO越慢

iotop可以按进程查看IO使用情况，类似top但针对IO：

# 安装iotop yum install iotop -y # 查看IO使用情况 iotop -o # 只显示有IO的进程 iotop -o -P

注意：iostat的第一次输出是自系统启动以来的平均值，参考价值不大，应该看后续的增量输出。

6.3 综合性能分析工具

sar是sysstat包里的工具，可以查看历史性能数据。如果系统开启了sysstat服务，sar会定期采集性能数据并保存，事后排查问题时可以回看当时的数据。

# 查看当天的CPU使用历史 sar -u # 查看指定日期的CPU使用历史 sar -u -f /var/log/sa/sa15 # 查看内存使用历史 sar -r # 查看IO历史 sar -b

dstat是一个综合性能查看工具，可以同时显示CPU、内存、磁盘、网络等信息，输出比vmstat更直观：

# 安装dstat yum install dstat -y # 每秒输出一次 dstat 1 # 显示CPU、内存、磁盘、网络 dstat -c -m -d -n 1

perf是更底层的性能分析工具，可以分析CPU缓存命中率、函数调用热点等。不过perf的使用门槛较高，日常运维排查用前面几个工具基本就够了。

7. 常见问题速查与避坑经验

7.1 命令执行异常排查表

7.2 几个容易踩的坑

第一个坑是rm -rf后面跟变量。如果变量为空，命令就变成了rm -rf /，后果不堪设想。我现在的习惯是，在脚本里删除文件之前，先echo一下要删除的路径，确认无误再执行。或者用rm -rf ${DIR:?}这种写法，如果DIR为空或未设置，命令会报错而不是执行。

第二个坑是chmod -R 777。这个命令看起来能解决所有权限问题，但实际上会带来严重的安全隐患。任何用户都可以修改这些文件，如果被恶意利用，后果很严重。正确的做法是精确设置权限，目录755，文件644，需要写入的目录单独处理。

第三个坑是kill -9滥用。kill -9是强制杀死进程，进程没有机会保存状态或清理资源。如果进程正在写文件，可能导致文件损坏。应该先尝试kill（默认是SIGTERM），给进程一个优雅退出的机会，等几秒如果还没退出再用kill -9。

第四个坑是tar解压覆盖。tar -xzf默认会覆盖同名文件，如果不小心解压到了错误的目录，可能覆盖重要文件。解压前先用tar -tzf查看压缩包内容，确认没问题再解压。或者解压到临时目录，确认后再移动。

7.3 效率提升小技巧

history命令可以查看历史命令，!编号可以快速执行历史命令，!!执行上一条命令，!$引用上一条命令的最后一个参数。这些快捷方式在重复执行类似命令时能省不少时间。

# 查看历史命令 history # 执行第123条历史命令 !123 # 执行上一条命令 !! # 上一条命令的最后一个参数 !$ # 搜索历史命令 Ctrl + R

alias可以给常用命令设置别名，比如alias ll='ls -alh'、alias grep='grep --color=auto'。把常用的别名写到.bashrc里，每次登录自动生效。

screen或tmux可以在断开SSH连接后保持会话，避免长时间运行的任务因为网络中断而失败。tmux功能更强大，支持分屏和会话共享，我现在基本都用tmux。

# 创建新会话 tmux new -s 会话名 # 列出所有会话 tmux ls # 连接到指定会话 tmux attach -t 会话名 # 分离会话（快捷键） Ctrl + B, D

提示：在tmux里执行长时间任务时，建议把输出重定向到文件，这样即使tmux会话意外终止，也能从文件里查看执行结果。

8. 命令组合与自动化思路

单个命令的力量有限，真正高效的是把命令组合起来。管道|把前一个命令的输出作为后一个命令的输入，&&和||根据前一个命令的退出状态决定是否执行后一个命令。这些组合方式在写脚本和日常操作中非常实用。

# 查找并统计 find /var/log -name "*.log" | wc -l # 查找并排序 ps aux | sort -k3 -rn | head -10 # 条件执行 systemctl is-active nginx && echo "running" || echo "stopped" # 批量操作 for host in host1 host2 host3; do ssh $host "uptime"; done

写脚本时，set -e让脚本在遇到错误时立即退出，set -u让脚本在使用未定义变量时报错，set -o pipefail让管道中任何一个命令失败都导致整个管道失败。这三个选项能避免很多隐蔽的错误。

#!/bin/bash set -euo pipefail # 脚本内容

xargs可以把标准输入转换成命令行参数，配合find使用非常高效：

# 查找并删除 find /tmp -name "*.tmp" -print0 | xargs -0 rm -f # 查找并统计行数 find /data -name "*.csv" -print0 | xargs -0 wc -l # 并行执行 find /data -name "*.jpg" -print0 | xargs -0 -P 4 -I {} convert {} -resize 50% {}

-print0和-0配合使用是为了处理文件名中包含空格的情况。如果文件名有空格，不加这两个参数会导致xargs把文件名拆成多个参数，操作出错。

我个人在实际操作中的体会是，命令大全这种东西，看一遍是记不住的，关键是要在实际场景中反复使用。我建议你挑几个最常用的场景，比如查看负载、排查磁盘、追踪日志，把这几个场景涉及的命令练熟，形成肌肉记忆。其他的命令知道有这么个东西，需要的时候能想起来去查就够了。真正重要的是理解每个命令回答的是什么问题，这样即使遇到没见过的情况，也能快速组合出排查路径。