上篇我们聊了一个问题：为什么背了很多 Linux 命令，遇到真实故障还是会懵？
原因很简单。命令是工具，系统思维才是用工具的方式。
你知道 grep，不等于你知道日志在哪；你知道 ps，不等于你知道服务为什么没起来；你知道 chmod 755，不等于你真的理解权限为什么会挡住访问。
这篇继续往下讲。Linux 的系统思维，不是玄学，也不是一句“底层逻辑”就能带过的口号。对新手来说，先抓住四件事就够了。
第一条：一切皆文件，但别把它背成口号
“一切皆文件”是很多人学 Linux 时听到的第一句名言。
问题是，很多人只背下了这句话，却没理解它能帮你做什么。
更准确地说，Unix/Linux 把大量资源抽象成文件或文件描述符来操作。普通文件、目录、设备、管道、socket、/proc 里的内核状态，都可以通过类似“打开、读取、写入、关闭”的方式暴露给用户空间。当然，这不是说所有东西都真的是普通文本文件，也不是说任何资源都能随便 cat 一下解决。
它真正有用的地方在于：你遇到问题时，会先想到“这个信息在系统里以什么形式暴露出来”。
想看 CPU 信息，可以读：
cat /proc/cpuinfo
想看内存信息，可以读：
cat /proc/meminfo
/proc 是伪文件系统，里面很多内容不是磁盘上的真实文件，而是内核运行状态的一个窗口。你读它，就能拿到系统正在发生什么。
配置也是类似的思路。很多服务的配置是文本文件，比如 Nginx 常见配置在 /etc/nginx 下。但这里要加一句发行版差异：Apache 在 Debian/Ubuntu 上常见目录是 /etc/apache2，在 RHEL 系上常见目录是 /etc/httpd。网络配置差异更大，老的 RHEL/CentOS 会见到 /etc/sysconfig/network-scripts，新系统更多由 NetworkManager、netplan 或 systemd-networkd 管理。
所以，“一切皆文件”不是让你死记某个路径，而是提醒你：先找资源在哪里被描述，再决定用什么命令操作它。
第二条：目录结构是按功能分层的
新手第一次进根目录，看到 /bin、/etc、/usr、/var、/tmp，很容易觉得乱。
其实它不乱。Linux 目录结构大体遵循 FHS，也就是文件系统层次结构标准。不同发行版会有细节差异，但大方向比较稳定：不同类型的文件放在不同位置。
常见目录可以这样理解：
/var 放运行过程中会变化的数据，比如日志、缓存、数据库状态文件。/tmp 放临时文件，很多系统会在重启或定期清理时处理它，不要把重要数据放在这里。/usr 主要放只读的系统程序和共享数据；手工编译安装的软件常见于 /usr/local。
现代发行版里，/bin、/sbin 可能只是指向 /usr/bin、/usr/sbin 的符号链接。你不需要一开始就背这些演进细节，但要知道：目录不是随便起名的，它背后有分工。
这个分工在排查问题时很有用。
找日志，先想到 /var/log，但也要知道现在很多服务日志可能进了 journald，要用 journalctl 查；容器里的服务，日志可能在容器输出里，不一定落到宿主机的 /var/log。
找配置，先想到 /etc，但也要看服务是怎么安装的、是不是跑在容器里、有没有通过启动参数指定配置路径。
有了目录分层的概念，你找东西就不是乱翻，而是按文件类型缩小范围。
第三条：服务问题，先看进程和资源关系
你启动一个服务，这个服务在 Linux 里通常表现为一个或多个进程。
进程不是孤立的。它会占用 CPU、内存、文件描述符，会读取配置，写日志，监听端口，连接数据库。理解了这些关系，排查服务问题就会顺很多。
比如服务访问不了，可以这样看：
pgrep -af 服务名
或者：
ps aux | grep 服务名
先确认进程是否存在。进程都没起来，就别急着查网络，先看启动日志。
进程在，再看端口：
sudo ss -lntp
ss 是现代 Linux 更推荐的网络查看工具。netstat 还会在很多老系统或教程里出现，但它属于 net-tools，很多新系统默认不装。为了兼容老环境，你可以知道 netstat -lntp，但写教程时优先讲 ss 更稳。
端口在本机监听，再从本机测试访问。如果本机通、远程不通，再看防火墙、安全组、网关、反向代理。防火墙工具也要按发行版看：Ubuntu 常见 ufw，RHEL 系常见 firewalld，更底层可能是 nftables 或 iptables 兼容层。
这条链路的重点不是命令，而是顺序：
进程是否存在，端口是否监听，本机是否可访问，远程链路是否放通。
你顺着资源关系查，就不容易乱。
第四条：日志会告诉你很多事，但路径要看环境
我刚入行时，服务出问题喜欢猜。
是不是配置错了？是不是依赖没装？是不是端口被占了？猜来猜去，时间都浪费了。后来才发现，很多问题日志已经写得很清楚，只是我没去看。
以 Nginx 为例，启动失败时，常见错误日志可能在：
/var/log/nginx/error.log
但这不是绝对路径。配置可以改，容器环境可以把日志打到标准输出，systemd 管理的服务还可以用：
journalctl -u nginx
系统日志也一样。RHEL 系常见 /var/log/messages，Debian/Ubuntu 常见 /var/log/syslog，如果启用了 systemd-journald，很多信息可以用 journalctl 查。
再比如进程被 OOM Killer 杀掉。你可以查内核日志：
journalctl -k -g "Out of memory|Killed process"
有些系统也能用：
dmesg -T | grep -Ei "out of memory|killed process"
不过 dmesg 在不少系统上需要权限，内核环形缓冲区也可能被新日志覆盖。生产排查时，journalctl 往往更稳。
日志不是万能的，但它通常比猜更可靠。遇到问题先看日志，是 Linux 排查里最值得养成的习惯之一。
怎么从背命令转到系统思维
第一，先学概念，再学命令。
不要一上来就背 100 个命令。先把文件系统、目录结构、进程、权限、用户组、服务管理这几个概念搞清楚。你知道命令操作的对象是什么，命令才记得住，也用得准。
第二，学命令时多问一句“我想验证什么”。
比如 ss -lntp 不是一个要硬背的字符串。-l 看监听，-n 不解析名称，-t 看 TCP，-p 显示进程信息。你用它，是为了验证“服务是否真的在监听端口”。这个目标比参数本身更重要。
再比如 chmod 755 file。不要只记 755，要知道 7、5、5 分别对应属主、属组、其他用户的权限组合；目录的 x 权限代表能进入或穿过目录，所以目录没有执行权限时，光有读权限也不够用。
第三，多做小型真实练习。
找一台虚拟机，或者用 WSL，部署一个简单服务。不要只照教程敲完就算了，要故意制造几个问题：端口被占用、配置写错、权限不对、磁盘空间不足。然后按“进程、端口、日志、权限、网络”的顺序自己查一遍。
你真正走过一次排查流程，比看十篇“命令大全”都管用。
写在最后
我不是劝你别学命令。命令肯定要学。
但学 Linux 的目标不是记住多少参数，而是能用 Linux 解决问题。你可以忘记某个命令的具体写法，因为它能查；但你不能不知道问题该从哪一层开始拆。
当你理解了“一切皆文件”、目录分层、进程资源关系、日志追踪这四件事，很多命令会自然长到正确的位置上。
最后留个问题：如果一个服务启动失败，你会按什么顺序排查？欢迎把你的步骤写在留言区，我们一起拆。
