企业官网建设流程全解析

拿一份Linux操作指南来背，是很多刚接触服务器的人最先做的事。我常被问到：Linux到底怎么学？有没有一份命令大全？我一般会反问：你现在最想干的事是什么？架个网站，还是处理一台跑得很慢的机器？答案不一样，要用的命令就完全不一样。Linux最唬人的地方是命令数量多，但真正撑起日常使用和排查的，无非就是文件、权限、进程、日志、服务、脚本这几根主线。把这几个点打通，比背下几百条命令有用得多。这篇文章就按这条路线走，讲我实际维护服务器时反复在用的一套操作逻辑，也把中间踩过的坑一并写出来。适合刚接触Linux、准备拿它干点实事的读者；如果你已经用了一段时间，但对排查还一头雾水，同样值得翻一翻。

1. 文件与目录：先有空间感，再谈命令技巧

1.1 用pwd、ls、cd把“当前位置”变成直觉

很多人把Linux当Windows用，双击文件夹，找不到文件就懵。其实Linux命令行的核心能力之一，就是让你随时知道自己在哪、周围有什么。我自己的习惯是：敲任何删除、移动、覆盖类命令之前，先pwd确认一遍路径。看着多此一举，但它能把rm -rf /data和rm -rf /data/这种低级事故的损失降到最低。ls -l可以看权限、属主、大小、修改时间；ls -a能看到以.开头的隐藏文件；ls -lh在文件大小上更友好，会自动显示成K、M、G这样的单位。cd -可以在最近两次目录之间来回切换，这条很多新手不知道，实际上比反复敲完整路径快得多。

目录结构不用死记，但得有个大致方向感。/etc装的是配置，/var装的是日志和缓存这类变化数据，/tmp专门放临时文件，很多发行版重启时会自动清理。/home存普通用户数据，/root是管理员的家目录。真到排障的时候，先去/var/log翻日志，再去/etc里grep配置，基本能覆盖一大半问题。你说非要背下每个目录干什么吗？真的不需要，但是得知道该去哪里找答案，这才叫会用。

1.2 管道、重定向与通配符：把命令拼成流水线

单条命令只是砖头，管道和重定向才是把砖头砌成墙的水泥。管道符|会把左边命令的输出交给右边命令当输入。举个例子，我想知道/var/log下面到底有多少个文件，直接ls -l /var/log | wc -l就行，wc -l统计行数。看进程在不在，ps aux | grep nginx也是这个套路。这种组合方式几乎每天都在用，比翻命令手册再一条条拼要高效得多。

重定向更常用。>是把输出覆盖写进文件，>>是追加写。命令跑起来一堆输出不想看屏幕，可以在结尾加>/dev/null 2>&1，意思是把标准输出扔进黑洞、标准错误也扔进黑洞。对新手来说，这条记下来就能让很多脚本安静下来，但我必须提醒一句：排障的时候别乱加，把输出丢了就没线索了。

通配符同样高频。*.log代表当前目录下所有以.log结尾的文件，?代表单个字符。配合$()可以把一条命令的执行结果塞进另一条命令。比如做备份，想按日期生成文件名：tar czf backup_$(date +%F).tar.gz /data。命令里的$(date +%F)会先执行，把日期替换进去，生成backup_2025-01-15.tar.gz这种带时间的文件。用双引号把变量包起来，是为了防止文件名里有空格时被拆成两段——这个细节后面讲脚本时还会再强调。

还有一个能保命的习惯：给rm设置确认。很多发行版默认不带，你可以自己加alias rm='rm -i'，写到~/.bashrc里再source ~/.bashrc。这样删除时系统会先问你确认。虽然偶尔会嫌麻烦，但比起误删之后的抢救成本，这点麻烦太值了。

2. 权限与用户：大多数“奇怪故障”都藏在这些位里

2.1 一行ll输出到底在说什么

权限这块，很多人是囫囵吞枣过的，只知道chmod 777是“全部放开”。我先把这10个字符彻底拆开。举例：

-rw-r--r-- 1 root root 1234 Feb 20 10:00 app.conf

第一个字符表示文件类型，-是普通文件，d是目录，l是软链接。后面9个字符分成三组：rw-、r--、r--，分别对应文件属主、属组、其他人的权限。每组三个字符依次是r（读）、w（写）、x（执行）。所以-rw-r--r--的意思就是：属主可读可写，属组和其他人只能读。

数字权限就是给这三组赋值：r=4，w=2，x=1。644就是属主6（读+写），属组4（读），其他人4（读）。755是属主7，属组5，其他人5，这是可执行文件或目录的常见配置。这个换算属于运维的乘法口诀，必须烂熟，因为它直接决定了一个服务能不能被正确访问。

目录的x权限特别容易被忽略。你光有读权限，没有执行权限，是进不了这个目录、也访问不了里面文件的。很多Web服务报403，查来查去就是目录权限少了x。所以判断目录问题时，别只看r，一定要看x。对目录来说，x权限本质上是“允许你穿过当前目录去访问子目录和文件”的通行证。

2.2 一次权限事故的复盘：能别用777就别用

说个我在维护内部测试环境时实际碰到的例子。有一次部署完一个Web应用，上传目录一直无法写入。当时图省事，直接chmod -R 777整个项目目录，页面马上能用了。看起来问题解决了，但这就是埋雷。因为777意味着任何用户都能读写这里面的文件，一旦这台机器上还有别的服务，权限边界就等于没有。后来有个配置文件也被误改了，服务启动时直接报权限过大，我才意识到当时那个777埋下的雷爆了。

正确的排查思路是这样一条链：先用ls -ld看目录的属主属组；然后ps aux | grep服务进程确认到底以哪个用户运行；最后把目录属主改成运行用户，权限设成755或更紧的750。命令大概是：

sudo chown -R appuser:appgroup /data/www find /data/www -type d -exec chmod 755 {} \; find /data/www -type f -exec chmod 644 {} \;

目录和文件分开处理，是因为目录需要x权限才能进入，文件不需要。文件644、目录755，这是我在生产环境里最常用的一套基线。遇到需要进程写入的目录，再单独给那个用户开写权限，而不是一刀切777。

2.3 root、sudo与su：提权的红线

能不用root就别用root，这句话值得重复一百遍。日常操作在普通用户下做，需要提权时用sudo，sudo只对当前这条命令生效，环境不会整个切到root。su -则是切换用户，连环境变量一起切，适合长时间需要以另一个身份工作的场景，但用的时候要谨慎，因为整个会话都带过去了，容易忘记自己当前是谁。

配置sudo时，我强烈不建议直接给ALL=(ALL) ALL，这等于把所有命令都交给一个用户。更稳妥的写法是精确到命令。比如允许某用户只重启web服务：

devuser ALL=(ALL) /usr/bin/systemctl restart nginx

这样即使账号被滥用，能造成的破坏也可控。另一条红线是：不要拿到一段来历不明的脚本，想都不想就sudo bash它。我之前在群里看过有人跑了一串sudo命令，结果把系统关键配置改了。脚本先打开看清楚，再决定跑不跑，这个习惯能挡掉很多麻烦。

3. 系统变慢的排查链路：从负载到进程再到IO

3.1 先看uptime和top，别急着重启

机器变慢的时候，很多人第一反应是重启一遍服务再说。我的习惯是先看三个数字：执行uptime，它会输出load average后面三个值，分别代表1、5、15分钟的平均负载。这组值如果接近或者超过CPU核数，说明有任务在排队；如果远小于核数，那系统整体并不繁忙，慢可能是单点问题。

接下来看top。进入交互界面后，按P是按CPU使用率排序，按M是按内存排序，按1可以展开每个CPU核心的占用。这里有个新手容易误判的点：load average高不等于CPU打满，还可能是IO等待。在top里看wa这个指标，wa高说明大量时间耗在磁盘读写上了，瓶颈在IO；再看st高，说明运行环境的宿主机存在资源争抢，你自己机器再优化也有限。别一看到load高就慌着kill进程，先搞清楚是哪一类。

3.2 用ps定位进程，用ss查看端口

top确认了某个进程占资源之后，还要拿到PID。ps aux --sort=-%cpu | head可以按CPU降序列出进程，想按内存就ps aux --sort=-%mem | head。拿到PID后，有两个命令很能说明问题：lsof -p PID列出这个进程打开的所有文件，strace -p PID跟踪它正在执行的系统调用。不过strace在生产环境要慎用，它会放大IO，小压力没问题，高峰期可能让本来就慢的服务雪上加霜。

排查网络连接时，先看端口是否在监听。ss -tunlp比netstat信息更全、输出更快，tunlp分别对应TCP、UDP、不解析主机名、监听状态、显示进程。想看当前有多少到443端口的外部连接，用ss -tn state established '( dport = :443 or sport = :443 )'，这会直接告诉你连接数和来源IP，是排查异常请求的开胃菜。

3.3 磁盘满和inode耗尽：两个完全不同的问题

磁盘问题最常见的是df -h一看，容量100%。但df -i是用来查inode的，很多人不知道。inode是文件系统存文件元数据的索引，如果小文件特别多，inode被耗尽，磁盘明明还有剩余空间，却报设备上没有空间。这种坑很隐蔽，我踩过一次之后，现在查磁盘问题都是df -h和df -i一起看。

找出大文件的组合拳是du和sort：

du -sh /data/* 2>/dev/null | sort -hr | head -10

du -sh能汇总目录大小，sort -hr按人类可读数字从大到小排。一个个钻进去往下查，通常很快就能定位到是日志还是备份文件把盘吃满了。清理时有个细节：如果日志文件正被进程占用，rm删了也不会释放空间，得先重启进程或者用> /var/log/xxx.log清空文件。这也是为什么后面要专门讲日志轮转。

4. 服务与日志：遇到故障先读日志，不要盲猜

4.1 systemctl：管理服务的基本动作

现代Linux发行版管理服务基本都走systemd，systemctl是它的操作入口。最常用的动作就那几个，我整理成了一张表，方便对照：

这里必须分清restart和reload：restart是重新启动整个进程，reload是重新加载配置，改动配置希望不中断服务时用reload。如果改了配置文件之后没reload，经常会造成“我明明改了啊怎么没生效”的事故。

再补一个容易漏的：如果你自己写了一个unit文件放在/etc/systemd/system/下，改完必须systemctl daemon-reload，否则systemd不会感知。我有一次改完unit忘了reload，反复restart都没用，最后daemon-reload一下才生效，印象很深。

4.2 journalctl与dmesg：日志应该在动手之前看

故障排查第一步是看日志，而不是马上重启。systemd管理服务的日志通常用journalctl查看。最常用的几条：

journalctl -u nginx -n 100 # 看服务最近100行日志 journalctl -u nginx --since "10 minutes ago" # 看最近10分钟 journalctl -u nginx -f # 跟踪实时输出

-u后面跟的是服务名，-n控制条数，-f类似tail -f。应用日志找不到原因后，再看系统日志和内核日志。dmesg负责内核层，比如内存溢出、硬件错误、OOM Kill这类，普通应用日志是看不到的。

举个例子。某次我在测试环境遇到一个后台任务反复消失，应用日志里只有一句被终止，没有更多信息。这时候直接执行dmesg | grep -i oom，立刻看到是可用内存不足，系统把进程杀了。如果不看dmesg，可能还在程序里找半天逻辑错误。按“应用日志→系统日志→内核日志”这个顺序排查，能少走很多弯路。

4.3 logrotate：让日志文件永远不把磁盘写满

日志不轮转，磁盘总有一天会被写满。Linux自带的logrotate就是干这个的。配置通常放在/etc/logrotate.d/下面，每个服务一个文件。一个常见Web服务的日志轮转配置大概长这样：

/var/log/nginx/*.log { daily rotate 14 compress delaycompress missingok notifempty sharedscripts postrotate /usr/bin/kill -USR1 `cat /run/nginx.pid` 2>/dev/null || true endscript }

daily表示每天轮转一次，rotate 14表示保留最近14份，compress表示压缩旧日志。关键点是postrotate后面的动作，轮转完之后通知服务重新打开日志文件，不然服务还会往已经被换走的文件里写。

测试配置用logrotate -d /etc/logrotate.d/nginx，-d是调试模式，只打印执行过程不真正动文件。实际配置会和系统计划任务配合，每天自动跑。注意不要手动去rm日志文件，如果服务还在写，文件句柄会一直占着，磁盘空间也不会真正释放。要临时清理就清空它：> /var/log/nginx/access.log。

5. Shell脚本与定时任务：把重复劳动固化成自动操作

5.1 从零写一个备份和清理脚本

运维里最值得脚本化的就是备份和清理。写一个最简单的版本，目标：把/data目录打包，按日期命名，保留最近7天的备份。脚本如下：

#!/bin/bash set -euo pipefail BACKUP_DIR=/backup SOURCE_DIR=/data KEEP_DAYS=7 DATE=$(date +%F) mkdir -p "$BACKUP_DIR" tar czf "$BACKUP_DIR/app_$DATE.tar.gz" "$SOURCE_DIR" find "$BACKUP_DIR" -name "app_*.tar.gz" -mtime +$KEEP_DAYS -exec rm {} \;

set -euo pipefail这一行现在几乎是我写脚本的默认开头。set -e让脚本在遇到第一个错误时直接退出，set -u不允许使用未定义变量，set -o pipefail让管道中任何一个命令失败都能让整体失败。这些细节能防止脚本半路出错还继续往下跑，最后留下一堆垃圾状态。

用变量把所有路径抽出来，是因为后面维护时只需要改开头几行就行。变量和参数都加双引号，是为了防止路径里出现空格而把命令拆坏。find ... -exec rm {} \;是查找7天前的备份并删除，比写一个for循环更简洁。

5.2 crontab：时间字段没那么难，但坑很常见

定时执行脚本靠crontab -e，每个用户一套配置。一行cron包含5个时间字段加命令，依次是：分、时、日、月、周。几个常用例子：

易错点第一个：环境变量。手动在终端执行脚本没问题，但cron执行时环境是精简的，PATH往往不是你以为的那个。最稳妥的做法，脚本里开头写全绝对路径，需要时再export PATH=/usr/local/bin:/usr/bin:/bin。第二个易错点：脚本没有执行权限或者没有写解释器。cron执行前先chmod +x脚本，文件开头必须写#!/bin/bash。第三，cron产生的输出默认会以邮件发给用户，时间一长邮箱就被占满。我一般会在脚本里把输出重定向到日志：

30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

这样既没邮件垃圾，排障的时候有日志可查。

5.3 脚本安全与调试：别让自动任务变成事故源头

脚本写得越多，越要注重安全。第一，脚本目录和脚本文件权限收紧，比如chmod 700 backup.sh，只有属主能读写执行。用root跑定时任务时，尤其要注意脚本里别出现任何从外部直接拼接的命令。第二，变量一定加引号，我之前遇到过一个目录名带空格，没加引号，结果tar拆成了两个参数，备份根本没打全。第三，调试时用bash -x script.sh，这个命令会把每一步执行过程打印出来，一眼就能看出变量有没有展开成预期的值。

还有一个容易被忽略的点：脚本里要用绝对路径。cron的工作目录和终端不一样，如果脚本里写相对路径，定时执行时很可能找不到文件。这个坑折磨了我一晚，最后发现就是路径问题。脚本开头cd到固定目录也是常见做法，比如cd /usr/local/scripts。

写脚本的习惯：先做小范围验证，直接跑一条命令和把脚本整体跑通是完全两回事。脚本上线到cron之前，至少手动执行三次，确保重复执行也不会产生副作用。如果脚本在执行中途失败，set -e能帮你及时退出，日志里的退出码也能告诉你是哪一步挂了。

6. 网络排查三板斧：连通性、DNS、响应验证

6.1 ping与traceroute：先判断链路通不通

两台机器说不上话，先ping一下目标IP。能通，说明三层没问题；不能通，再ping网关缩小范围。ping -c 4指定发包数量，不要傻等它一直ping下去。看结果的时候注意丢包率，100%丢包说明链路不通，部分丢包说明网络质量有问题。

traceroute -n可以看路径上每一跳，能判断网络是断在机房内部，还是经过某一跳之后丢包。但要注意很多节点会主动丢弃ICMP探测包，所以路线上出现*号不一定就是断，要看整体丢包率。这个命令对“两边都说自己没问题”的网络纠纷特别有用，能一下子把责任边界画出来。

6.2 DNS：域名解析失败的表现很迷惑

应用报连接超时，但你用IP访问却发现是好的，这时候基本就是DNS的问题。用dig 域名或nslookup 域名看解析结果，再用cat /etc/resolv.conf看系统配置的DNS服务器。还有一个常见情况：改了DNS不生效，因为系统有缓存。很多发行版用systemd-resolved做解析，可以用resolvectl flush-caches清空缓存。内网环境里自定义域名解析出错尤其常见，排查时先把DNS排除掉，再去看应用层。

6.3 curl：验证服务真的在响应

最后一步是验证应用本身。curl -I https://example.com看HTTP响应头，-v看详细过程，包括TLS握手、请求头、响应头。返回200说明服务正常，返回502说明后端挂了，返回403要去看权限和防火墙策略。还可以用curl -o /dev/null -w '%{http_code} %{time_total}'测响应状态和总耗时，判断是不是性能问题。配nginx这类Web服务排障时，curl是我最常用的探针，能直接区分问题出在网络层、服务层还是后端应用层。

7. 一些真正的实操心得

最后说点个人的体会吧。Linux命令背不完，也不需要背完。真正让我从“百度一条命令用一下”到“上手就能排查”的转折点，不是记了多少参数，而是养成了“现象→假设→验证”的思维：先看日志确定现象，再根据权限、进程、磁盘这些维度提出假设，最后用命令去验证。权限和属主、进程身份、日志位置，这三件事几乎覆盖了日常故障的一大半。如果你刚接触Linux，与其复制一长串命令，不如先把这篇文章里的几条排查链路走一遍。跑通一次，比背十遍都管用。