但只懂目录还不够。真实服务器出问题时，你通常面对的是另一类问题：服务起不来、端口不通、进程卡住、CPU 不高但系统很慢、内存突然被吃满。
这些问题不能靠乱敲命令解决。你需要把 Linux 从启动到运行的链路串起来。
1 排障先看链路，不要先背命令
新手排障常见的问题是：一上来就搜命令。
服务访问不了，就先 ping；不行就 ps；再不行就 top；看不懂又去改配置。命令敲了不少，但每一步之间没有逻辑关系。
更稳的方式是先问：请求经过了哪些环节？
以 Web 服务访问失败为例，至少有这几层：
你看，命令还是那些命令，但顺序变了。排障不是背命令，而是沿着系统链路逐层缩小范围。
2 启动流程：从固件到 PID 1
很多教程会把 Linux 启动流程背成：
BIOS -> MBR -> GRUB -> 内核 -> init
这条链路对传统机器有帮助，但现在已经不够完整。新机器更多使用 UEFI、GPT 和 EFI System Partition。你不需要一开始就记住所有细节，但要抓住核心逻辑：
固件先运行，引导器再加载内核，内核启动后创建第一个用户空间进程。
在很多现代发行版里，这个 PID 1 进程就是 systemd。它负责启动和管理系统服务，比如网络、SSH、Nginx、MySQL 等。
所以服务起不来时，你要知道自己在查哪一层。
如果机器根本进不了系统，可能要看引导器、内核、磁盘挂载。如果能登录但服务没起，就应该看 systemd 的服务状态和日志。如果服务起了但访问不了，再去看端口、配置、防火墙、上游依赖。
这就是系统逻辑带来的好处：你不会把所有问题都混成一团。
3 一个服务起不来的排查路径
假设重启服务器后，Nginx 访问不了。
不要先猜配置，也不要直接重装。可以按这个路径走。
先确认机器是否在线：
ping <server-ip>
能通，只能说明网络基本可达，不能说明服务正常。
再确认能否登录：
ssh user@<server-ip>
能登录，说明系统已经启动，SSH 服务也在工作。接下来查 Nginx。
看服务状态：
systemctl status nginx
如果状态显示 failed，再看系统日志：
journalctl -u nginx -n 100
检查 Nginx 配置语法：
nginx -t
看端口是否被占用：
ss -ltnp | grep ':80'
再看 Nginx 自己的错误日志：
tail -n 100 /var/log/nginx/error.log
这一套下来，常见问题基本会露出来：配置语法错、证书路径错、端口被占用、权限不对、上游服务连接不上。
你会发现，命令不多。关键是每条命令都对应一个问题：服务有没有起？日志说了什么？配置能不能通过？端口有没有监听？
4 进程不是黑盒：PID、信号和资源
Linux 里，服务最终都会落到进程上。每个进程有自己的 PID，内核负责给它分配 CPU 时间、内存和其他资源。
你用：
ps -ef | grep nginxtop
看到的不是“命令输出”，而是进程状态的一个视图。
进程异常时，很多人第一反应是：
kill -9 <pid>
但前面说过，kill 的本质是发送信号。更稳的习惯是先尝试正常退出：
kill -TERM <pid>
如果进程确实无法退出，再考虑：
kill -KILL <pid>
KILL 不能被捕获，也不能被忽略，所以它能强制结束进程。但强制不代表优雅。数据库、队列、写文件的服务，都不应该一上来就用 -9。
你理解了 PID 和信号，就不会把进程管理简化成“看到卡住就强杀”。
5 性能问题要分清 CPU、内存和 I/O
很多人看到系统慢，第一反应是看 CPU。
CPU 当然要看，但不能只看 CPU。Linux 性能问题常常要拆成三类：CPU、内存、I/O。
CPU：忙还是在等
top 里 CPU 使用率高，说明进程确实在消耗计算资源。可如果 load average 很高，CPU 使用率却不高，就要警惕：系统可能不是在算，而是在等。
大量进程等待磁盘或网络 I/O，也会把负载拉高。这个时候继续优化 CPU 没意义，应该转向磁盘、网络、数据库查询、日志写入等方向。
关于调度器，很多资料会提 CFS。较新的 Linux 内核已经引入 EEVDF 相关调度机制。新手不必一开始陷进实现细节，先记住一点：内核会围绕公平性、优先级和延迟来分配 CPU 时间。你要做的是判断瓶颈是不是 CPU。
内存：满了不等于马上崩
Linux 会尽量利用空闲内存做缓存，所以看到内存占用高，不一定是坏事。
真正要注意的是：应用是否持续吃内存、Swap 是否频繁使用、是否发生 OOM。
如果系统开始大量使用 Swap，响应会明显变慢。此时不能只想着杀进程，要先判断是应用内存泄漏、配置太小，还是业务量超过了机器规格。
I/O：CPU 不高也可能很慢
有些问题最容易误判。
比如每天晚上服务器都会慢一阵，CPU 不高，负载却很高。最后发现是定时任务在备份数据库，大量写磁盘，其他进程都在等 I/O。
这类问题只看 CPU 看不出来。你要结合 iostat、日志时间点、定时任务、数据库备份策略一起看。没有 I/O 这层意识，就容易在错误方向上浪费时间。
6 学 Linux 的几个建议
第一，从问题链路学，不要从命令清单学。
服务访问不了，就按“机器、网络、登录、服务、端口、配置、日志、资源”这条线查。磁盘满了，就按“文件系统、挂载点、目录占用、日志增长、清理策略”这条线查。
第二，命令要和系统对象绑定。
systemctl 对应服务管理，journalctl 对应 systemd 日志，ps 和 top 对应进程，ss 对应 socket 和端口，df 对应文件系统空间，du 对应目录占用。这样记命令，忘了也容易找回来。
第三，别迷信“万能命令”。
find /、kill -9、rm -rf、chmod 777 都很常见，也都很容易被滥用。真正熟悉 Linux 的人，不是命令敲得最狠，而是知道什么时候不该敲。
第四，多看官方文档和手册页。
网上教程可以入门，但事实细节最好回到 man page、发行版文档、FHS、内核文档。技术文章最怕“听起来很顺，但细节是错的”。
结尾
Linux 学到后面，拼的不是谁背的命令多，而是谁能把系统链路想清楚。
文件系统告诉你东西放在哪里。启动流程告诉你服务从哪来。进程模型告诉你程序怎么运行。资源管理告诉你系统为什么变慢。
这些逻辑串起来，你再学命令，就不会乱。
