Linux 体系与学习路径

Linux 体系与学习路径 技术参考图从发行版差异、目录结构、进程端口、权限、systemd、日志、磁盘、CPU 内存、网络排障到官方学习资料，建立部署运维场景下的 Linux 最小生存能力。高清原图

本文范围

这篇只讲部署运维场景下的 Linux 最小生存能力，不把 Linux 写成命令百科。读完以后，你应该能拿到一台服务器后先做只读判断，再按发行版差异、目录、进程、端口、权限、systemd、日志、磁盘、CPU、内存和网络排障这条主线往下查。

本文会覆盖：

1. 新服务器登录后的基础识别和发行版差异。
2. 部署服务时最常用的目录、文件、进程、端口和权限命令。
3. systemd、journalctl、日志文件、磁盘和资源排查的入口。
4. 中国大陆公网、企业内网、离线环境下的软件源和依赖闭环意识。
5. 后续学习 Shell、SSH、Docker、Nginx、K8S、数据库部署时需要先补齐的 Linux 能力地图。

本文不展开内核开发、驱动、网络协议栈源码、完整安全加固、性能调优专项，也不讲 Docker、K8S、Nginx、MySQL、Redis 的完整部署。那些主题应该在自己的文章里展开，这里只把通用地基打稳。

前置条件

建议准备一台可练习的 Linux 服务器或虚拟机，使用 Ubuntu 22.04/24.04、Debian、RHEL 9、Rocky Linux、AlmaLinux、CentOS Stream、openEuler、麒麟、统信等主流服务器系统均可。你需要有普通用户登录权限，最好也有受控的 sudo 权限；如果是生产机器，先只读巡检，不要直接改配置。

开始前先确认这些命令是否存在：

cat /etc/os-release
uname -a
command -v systemctl journalctl ss ip df du free top ps find grep awk sed

如果目标环境是企业内网或离线机房，还要提前确认软件源、DNS、NTP、代理、离线包和校验文件是否可用。本文里所有 IP、用户名、服务名和路径都是示例，落地时替换为自己的环境变量，不要把真实密码、token、客户公网 IP 或内网资产清单写进公开文档。

拿到服务器，先别急着装东西

很多人第一次进 Linux 服务器，第一反应是复制安装命令。这个习惯很危险。

同样是 Linux，Ubuntu、Debian、RHEL、Rocky、Alma、CentOS Stream、openEuler、麒麟、统信，包管理、防火墙、网络配置、日志路径都可能不一样。你在一台机器上能跑通的 yum install，换到 Ubuntu 上就不认识；你在 RHEL 上用 firewall-cmd 放行端口，换到 Ubuntu 上可能要看 ufw。

所以现场操作第一步不是安装软件，而是先问清楚三件事：

1. 这台机器是什么发行版。
2. 当前系统上有哪些工具。
3. 服务后面准备放在哪里、用哪个用户跑、日志写到哪里。

先执行这几条：

cat /etc/os-release
uname -a
uname -m
command -v apt dnf yum systemctl journalctl ss firewall-cmd ufw iptables nft

这里分别解决什么问题：

• cat /etc/os-release：看发行版和版本，比如 Ubuntu、Debian、Rocky、openEuler。
• uname -a：看内核版本，有些驱动、容器运行时、系统特性会受影响。
• uname -m：看 CPU 架构，常见是 x86_64 或 aarch64，离线包必须和它匹配。
• command -v：看命令是否存在，避免教程里有命令，服务器上没有。

正常情况下，cat /etc/os-release 会输出类似这样的信息：

NAME="Ubuntu"
VERSION="24.04 LTS (Noble Numbat)"
ID=ubuntu
VERSION_ID="24.04"

如果你看到的是 ID="rhel"、ID="rocky"、ID="almalinux"、ID="centos"，那基本走 RHEL 系命令思路。如果看到 ID=ubuntu、ID=debian，那基本走 Debian 系命令思路。

这里要注意：CentOS 7 已经是存量系统，不适合做新项目默认基线。现场遇到 CentOS 7 可以排障、迁移、维护，但新部署建议选仍在支持期内的 LTS 或企业版系统。

P1 图解：Linux 运维能力地图

部署运维学 Linux，不是把命令从 A 背到 Z，而是遇到问题时知道对象在哪里、证据在哪里、下一步验证什么。下面这张能力地图可以当作学习顺序：先识别机器，再看文件、服务、端口、权限、资源和日志，最后把软件源、离线依赖和后续专题串起来。

这张图的读法是：不要看到报错就先改配置。比如“服务访问不了”，先看 systemctl status、ss -lntup、curl -Iv、journalctl，确认是服务没启动、端口没监听、网络不通，还是权限或配置错误。对象定位清楚以后，命令才有意义。

可以用下面这组命令给自己做一次最小能力自检：

cat /etc/os-release
uname -a
hostnamectl
systemctl status sshd --no-pager || systemctl status ssh --no-pager
journalctl -xe --no-pager | tail -80
ss -lntup
ip addr
df -hT
free -h
id
command -v apt dnf yum systemctl journalctl ss curl nc

常见坑是把 Linux 学成命令百科：知道很多参数，但不知道它们验证的对象是什么；或者只会在一类发行版上操作，换到 RHEL 系、Debian 系、国产发行版、离线机房就失效。还有一个高频问题是用 chmod 777 解决权限报错，短期看似能跑，长期会破坏审计和安全边界。

生产约束是：所有操作手册都要先声明适用发行版和版本；涉及软件安装时要说明公网、内网、离线三种路径；涉及服务启动时要同时给出 systemd 状态、日志和端口验证；涉及权限时要查用户、组、目录每一级权限和 SELinux/AppArmor，而不是只改最终文件。

不同 Linux 系统，差异主要在这几块

Linux 不同发行版不是所有命令都不同。ls、cd、cat、ps、top、df、du、systemctl、journalctl 这些在主流服务器上基本都能用。

真正容易出差异的是这些：

要做的事	Ubuntu / Debian 常见命令	RHEL / Rocky / Alma / CentOS Stream 常见命令	现场注意
安装软件	apt install	dnf install，老系统用 yum install	先看 /etc/os-release
更新软件源缓存	apt update	dnf makecache / yum makecache	内网环境常失败
查软件包	apt-cache policy 包名	dnf info 包名 / rpm -qa	看版本和来源
防火墙	ufw status	firewall-cmd --list-all	不要混用多套规则
底层防火墙	iptables / nft	iptables / nft	多用于存量排查
系统日志	/var/log/syslog	/var/log/messages	journalctl 更通用
网络配置	netplan、NetworkManager	NetworkManager、nmcli	老系统还有 ifcfg-*
安全模块	AppArmor	SELinux	权限正常但仍拒绝时要查

一般现场可以这么判断：

command -v apt
command -v dnf
command -v yum
command -v ufw
command -v firewall-cmd
getenforce 2>/dev/null
aa-status 2>/dev/null

如果 command -v apt 有输出，说明能用 apt。如果 command -v dnf 有输出，优先用 dnf。如果只有 yum，多半是老 RHEL 系或兼容系统。

如果 getenforce 输出 Enforcing，说明 SELinux 正在强制执行。遇到权限问题时，不能只看 chmod 和 chown。

生产建议是：操作手册里不要只写一套命令。至少要写清楚“Ubuntu / Debian 用什么，RHEL 系用什么，存量 CentOS 7 怎么兼容”。

目录先认几个够用的

Linux 目录不用一开始全背。部署服务时，先记这些就够用。

目录	一般放什么	现场怎么看
/etc	配置文件	看服务配置、软件源、防火墙、安全策略
/opt	自建或第三方应用	很多业务包会放这里
/var/log	日志	服务异常先来这里找
/var/lib	服务数据和状态	数据库、包管理、服务状态常在这里
/data	独立数据盘常用目录	不是标准强制目录，但项目里很常见
/tmp	临时文件	安装包解压失败常和这里空间有关
/home	普通用户目录	查用户脚本、上传文件
/root	root 用户目录	不建议放正式服务
/proc	进程和内核虚拟信息	查进程、内存、系统参数
/run	本次启动后的运行状态	PID、socket、锁文件常见

比如你要部署一个普通应用，一般可以这样规划：

mkdir -p /opt/demo-app
mkdir -p /etc/demo-app
mkdir -p /var/log/demo-app
mkdir -p /var/lib/demo-app

这些目录分别解决什么问题：

• /opt/demo-app：放程序包、启动脚本。
• /etc/demo-app：放配置，后面变更配置更好找。
• /var/log/demo-app：放日志，便于日志轮转和排查。
• /var/lib/demo-app：放运行状态或持久化数据。

如果没有就新建。新建后别忘了给服务用户授权：

useradd -r -s /sbin/nologin demo 2>/dev/null || true
chown -R demo:demo /opt/demo-app /var/log/demo-app /var/lib/demo-app
chmod 750 /opt/demo-app /var/log/demo-app /var/lib/demo-app
chmod 750 /etc/demo-app

这里要注意，chmod 750 的意思是：所属用户有读写执行，所属组有读和执行，其他用户没有权限。目录必须有 x 权限才能进入，不是只有文件才需要执行权限。

常见坑是把程序、日志、数据、备份都放到一个目录。短期看省事，后面磁盘满、备份恢复、权限排查都会变麻烦。

看文件和找文件，先会这几条

现场最常见的问题是：配置在哪里、日志在哪里、哪个文件占空间、刚改的东西到底有没有生效。

先进入目录看一眼：

cd /opt/demo-app
pwd
ls -lah

pwd 是确认当前位置。ls -lah 会显示隐藏文件、大小、权限、属主。正常情况下你应该能看到文件大小、所属用户和修改时间。

看配置：

cat /etc/demo-app/application.yml
less /etc/demo-app/application.yml
grep -n "server.port" /etc/demo-app/application.yml

cat 适合短文件，less 适合长文件，grep -n 会带行号，方便你定位配置项。

看日志：

tail -n 200 /var/log/demo-app/app.log
tail -n 200 -f /var/log/demo-app/app.log
grep -n "ERROR" /var/log/demo-app/app.log
grep -n "Exception" /var/log/demo-app/app.log

tail -f 适合边重启服务边看日志。访问接口后，日志里应该能看到新的请求、启动信息或错误堆栈。如果什么都没有，说明请求可能没到应用，或者应用还没启动到写日志阶段。

查文件：

find /opt -name "*.jar" -type f
find /var/log -name "*.log" -type f
find / -xdev -type f -size +1G -print 2>/dev/null

这里要注意 -xdev。它表示只在当前文件系统查，避免跨到挂载盘或网络盘把输出打爆。2>/dev/null 是把无权限目录的错误先屏蔽掉，排查大文件时比较实用。

生产建议：命令能少扫全盘就少扫全盘。先看明确目录，比如 /opt、/var/log、/data，不要一上来就 find /。

systemd：服务起不来先看它

生产服务一般不要靠手工执行 java -jar 或 ./start.sh 长期跑。更稳妥的方式是交给 systemd，让它负责启动、停止、重启、开机自启和失败状态。

先看服务状态：

systemctl status demo-app --no-pager

正常情况下你应该看到 active (running)。如果是 failed，说明服务启动失败。如果是 inactive，说明服务没启动。

常用操作：

systemctl start demo-app
systemctl stop demo-app
systemctl restart demo-app
systemctl enable demo-app
systemctl is-enabled demo-app
systemctl list-units --type=service --state=failed

这些命令分别解决：

• start：启动服务。
• stop：停止服务。
• restart：重启服务。
• enable：设置开机自启。
• is-enabled：验证是否设置了开机自启。
• list-units --state=failed：查看当前失败的服务。

如果你改了 service 文件，一般需要执行：

systemctl daemon-reload
systemctl restart demo-app

如果忘了 daemon-reload，你会发现明明改了配置，重启后还是旧效果。

一个最小 service 可以这样写：

[Unit]
Description=Demo Application
After=network-online.target
Wants=network-online.target

[Service]
User=demo
Group=demo
WorkingDirectory=/opt/demo-app
ExecStart=/usr/bin/java -jar /opt/demo-app/app.jar
Restart=on-failure
RestartSec=5
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target

这里重点看几行：

• User / Group：服务用哪个用户跑，不建议默认 root。
• WorkingDirectory：工作目录，很多相对路径依赖它。
• ExecStart：启动命令，尽量写绝对路径。
• Restart=on-failure：异常退出后自动拉起。
• SuccessExitStatus=143：把常见优雅退出状态当成正常退出。

如果服务起不来，马上看 journal：

journalctl -u demo-app -n 200 --no-pager
journalctl -u demo-app -f

如果应用日志里没东西，但 journalctl 里有错误，通常说明还没进入应用代码。常见原因是路径写错、用户没权限、环境变量缺失、工作目录不存在、依赖服务没起来。

生产建议：每个正式服务都要能回答四个问题：怎么启动、怎么停止、怎么开机自启、启动失败看哪里。

日志：不要只盯应用自己的 log

很多人排障只看应用日志。这个不够。

服务启动失败分两种情况：

1. 已经进入应用，应用自己打印了错误。
2. 还没进入应用，systemd 或系统层就失败了。

第二种情况应用日志可能没有任何内容，所以要看 systemd 日志。

systemd 日志：

journalctl -u demo-app -n 200 --no-pager
journalctl -u demo-app -f
journalctl -b -p warning --no-pager
journalctl -k --no-pager

这里：

• -u demo-app：只看某个服务。
• -n 200：看最近 200 行。
• -f：实时跟踪。
• -b：只看本次启动后的日志。
• -k：看内核日志，比如 OOM、磁盘、驱动异常。

系统日志路径和发行版有关：

# Ubuntu / Debian 常见
tail -n 200 /var/log/syslog

# RHEL / Rocky / Alma / CentOS Stream 常见
tail -n 200 /var/log/messages

# 登录、sudo、认证相关
tail -n 200 /var/log/auth.log   # Ubuntu / Debian
tail -n 200 /var/log/secure     # RHEL 系

应用日志一般看这里：

tail -n 300 -f /var/log/demo-app/app.log

访问服务后，日志里一般应该出现请求记录、业务日志或错误堆栈。如果没有任何变化，就要回头查端口、代理、防火墙，看请求是不是根本没到应用。

这里要注意日志轮转。日志不轮转，系统迟早被打满。可以用 logrotate 做基础轮转：

/var/log/demo-app/*.log {
    daily
    rotate 14
    missingok
    notifempty
    compress
    copytruncate
}

copytruncate 适合不支持主动重新打开日志文件的程序，但有极小概率丢失切割瞬间的日志。能让应用自己按日期滚动更好。

端口不通，按这条链路查

端口不通不要先改防火墙。先确认服务是否真的在监听。

第一步，看服务：

systemctl status demo-app --no-pager

如果服务没起来，先解决服务启动问题。

第二步，看端口监听：

ss -tulnp | grep ':8080'

正常情况下你应该看到类似：

tcp LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:(("java",pid=1234,fd=88))

这里重点看两个地方：

• 0.0.0.0:8080：表示所有网卡都监听。
• 127.0.0.1:8080：只允许本机访问，远程肯定不通。

如果老系统没有 ss，再用：

netstat -tulnp | grep ':8080'

第三步，本机访问：

curl -v http://127.0.0.1:8080/health
curl -v http://localhost:8080/health
curl -v http://<server-ip>:8080/health

访问后一般应该看到 HTTP 状态码，比如 200、401、404。这些都说明端口至少通了。真正麻烦的是 Connection refused 或 Connection timed out。

• Connection refused：通常是端口没有监听，或监听地址不对。
• Connection timed out：通常是网络、防火墙、安全组、路由问题。

第四步，看防火墙。

RHEL 系常见：

firewall-cmd --state
firewall-cmd --list-all
firewall-cmd --add-port=8080/tcp --permanent
firewall-cmd --reload
firewall-cmd --list-ports

Ubuntu 常见：

ufw status verbose
ufw allow 8080/tcp
ufw reload

存量系统可能还要看：

iptables -L -n --line-number
nft list ruleset

这里要注意，不要一边用 firewall-cmd，一边手工改 iptables，又不记录规则来源。多人维护时最容易互相覆盖。

第五步，从调用方机器验证：

nc -vz <server-ip> 8080
curl -v http://<server-ip>:8080/health

如果服务器本机通，调用方不通，就继续查云安全组、机房 ACL、网络策略、DNS、代理。

生产建议：端口放行要记录在部署文档里，包括端口号、协议、来源网段、用途和负责人。

进程：服务到底是不是那个进程

有时候 systemctl 显示服务正常，但实际访问不是预期版本。也可能一台机器上跑了多个同名服务。这个时候要看进程。

查进程：

ps -ef | grep demo-app | grep -v grep
pgrep -af demo-app

看资源占用：

top
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head

如果是 Java 进程，机器上有 JDK 工具时可以看：

jps -l

但不要假设所有服务器都有 jps。很多生产环境只装 JRE 或裁剪运行时。

停止进程时，优先用服务命令：

systemctl stop demo-app

如果服务命令无效，再看 PID：

kill -15 <PID>

kill -15 是请求优雅退出。实在退不掉才用：

kill -9 <PID>

这里要注意，kill -9 是强杀，应用来不及释放资源、刷日志、关闭连接。生产上不要把它当成第一选择。

权限问题，不要一上来 chmod 777

权限问题现场非常常见。表现可能是：

• 服务启动失败。
• 日志写不进去。
• 配置读不到。
• 上传文件失败。
• 脚本提示 Permission denied。

先看当前用户：

whoami
id
groups

再看文件和目录：

ls -ld /opt/demo-app
ls -ld /var/log/demo-app
ls -l /etc/demo-app/application.yml
namei -l /etc/demo-app/application.yml

namei -l 很好用，它会把路径上每一级目录的权限都列出来。很多问题不是文件没权限，而是上级目录没有 x 权限，导致进不去。

常见修复方式：

chown -R demo:demo /opt/demo-app /var/log/demo-app /var/lib/demo-app
chmod 750 /opt/demo-app /var/log/demo-app /var/lib/demo-app
chmod 640 /etc/demo-app/application.yml
chmod +x /opt/demo-app/bin/start.sh

这里每条命令的目的：

• chown -R demo:demo：让服务用户拥有应用目录和日志目录。
• chmod 750：允许服务用户读写进目录，限制其他用户。
• chmod 640：配置文件服务用户能读，其他人不能随便读。
• chmod +x：脚本需要执行权限。

如果权限都对，还是拒绝，RHEL 系要看 SELinux：

getenforce
journalctl -t setroubleshoot --no-pager 2>/dev/null

临时验证可以用：

setenforce 0

如果关掉后问题消失，说明很可能是 SELinux 策略或上下文问题。但生产修复不应该直接把 SELinux 永久关掉，而是按发行版规范处理上下文或策略。

生产建议：业务服务尽量用专用用户跑，少用 root。目录权限按“需要什么给什么”来，不要靠 777 解决所有问题。

磁盘满，先找分区，再找目录

磁盘满不要上来就删文件。先看哪个分区满。

df -hT
df -ih
lsblk

这里：

• df -hT：看磁盘空间和文件系统类型。
• df -ih：看 inode 是否耗尽。
• lsblk：看磁盘和挂载关系。

如果 / 满了，先看一级目录：

du -xhd1 / | sort -h

如果 /var 大：

du -xhd1 /var | sort -h
du -sh /var/log/* 2>/dev/null | sort -h

如果 /data 大：

du -xhd1 /data | sort -h

找大文件：

find /var/log -type f -size +500M -print
find / -xdev -type f -size +1G -print 2>/dev/null

删除文件后空间没释放，通常是进程还占着已删除文件：

lsof +L1

如果看到某个进程还打开着 deleted 文件，需要重启对应进程或让它重新打开日志文件。

这里要注意：日志可以按规则清理，临时文件可以确认后删除，数据库数据文件、制品仓库、备份目录不能随便删。删之前先确认归属和恢复方式。

生产建议：

1. 日志要轮转。
2. 备份要有保留策略。
3. 数据目录最好单独挂盘。
4. 安装包解压前先看 /tmp 或 TMPDIR 空间。

CPU 和内存异常，先看整体，再看进程

服务器变慢时，先看整体负载：

uptime
nproc
top

uptime 里有三个 load average，分别代表 1 分钟、5 分钟、15 分钟平均负载。这个值要和 CPU 核数一起看。比如 4 核机器长期 load 20，说明队列压力很大。

看 CPU 高的进程：

ps aux --sort=-%cpu | head

看内存高的进程：

ps aux --sort=-%mem | head
free -h

free -h 里不要只看 free，更要看 available。Linux 会拿空闲内存做缓存，这不一定是问题。真正要紧的是 available 很低、Swap 持续使用、应用开始变慢。

看是否发生 OOM：

journalctl -k --no-pager | grep -i "out of memory\|killed process"
dmesg -T | grep -i "out of memory\|killed process"

如果看到 Killed process，说明进程被内核 OOM Killer 杀了。这个时候不要只重启服务，要继续查内存配置、服务数量、并发量、JVM 参数或组件自身内存限制。

如果有 vmstat，可以看几秒趋势：

vmstat 1 5

重点看：

• r：运行队列。
• wa：IO 等待。
• si / so：Swap 换入换出。

这里要注意，CPU 高不一定就是 CPU 问题。磁盘 IO 慢、网络重试、锁竞争、频繁 GC 都可能让系统看起来很慢。Linux 这里先教你找到入口，JVM、数据库和中间件会在各自文章里展开。

安装软件，先看网络和软件源

公网环境里，安装工具可能很简单：

# Ubuntu / Debian
apt update
apt install -y curl vim lsof

# RHEL / Rocky / Alma / CentOS Stream
dnf makecache
dnf install -y curl vim lsof

# 老系统
yum makecache
yum install -y curl vim lsof

但是在中国大陆公网、企业内网、离线环境里，最容易出问题的就是这里。

如果 apt update 或 dnf makecache 失败，先看：

ping -c 3 <gateway-or-known-internal-host>
getent hosts mirrors.example.com
curl -I https://mirrors.example.com
cat /etc/resolv.conf
ip route

这些命令分别看：

• 到网关、内部 DNS 或已知可达地址是否连通。
• DNS 能不能解析。
• HTTP/HTTPS 能不能访问。
• DNS 配置是谁。
• 默认路由有没有。

企业代理环境一般需要配置代理：

export http_proxy=http://proxy.example.com:8080
export https_proxy=http://proxy.example.com:8080
export no_proxy=localhost,127.0.0.1,.internal.example.com

这里要注意，临时 export 只对当前 shell 生效。正式交付要把代理配置写进对应工具的配置里，并记录清楚。

离线环境不要只准备一个主包。要准备完整依赖闭环：

1. 系统版本：cat /etc/os-release。
2. CPU 架构：uname -m。
3. 包清单：需要哪些包，版本是多少。
4. 依赖包：主包依赖什么。
5. 校验文件：sha256sum 或内部制品校验。
6. 回退包：升级失败后怎么回去。

校验文件：

sha256sum package.tar.gz
sha256sum -c package.sha256

如果校验不通过，不要继续安装。现场很多“装不上”的问题，最后都是包下载不完整、架构不匹配、系统版本不一致。

生产建议：企业内网最好建设内部软件源或制品仓库，不要靠每个人手工拷包。手工拷包短期能救急，长期一定会出版本不一致的问题。

一台服务器上线前，至少检查这些

这里给一组最小检查命令。不是让你机械背，而是每次上线前照着跑一遍。

看系统：

cat /etc/os-release
uname -a
uname -m
hostnamectl
timedatectl

看用户和目录：

id demo
ls -ld /opt/demo-app /etc/demo-app /var/log/demo-app /var/lib/demo-app

看服务：

systemctl status demo-app --no-pager
systemctl is-enabled demo-app
journalctl -u demo-app -n 100 --no-pager

看端口：

ss -tulnp | grep ':8080'
curl -v http://127.0.0.1:8080/health
curl -v http://<server-ip>:8080/health

看资源：

df -hT
df -ih
free -h
uptime

看防火墙：

firewall-cmd --list-all 2>/dev/null
ufw status verbose 2>/dev/null
iptables -L -n --line-number 2>/dev/null

上线前要能回答这些问题：

1. 服务怎么启动、停止、重启。
2. 服务是否开机自启。
3. 日志在哪里，保留多久。
4. 数据在哪里，怎么备份和恢复。
5. 端口有哪些，谁可以访问。
6. 软件包从哪里来，内网和离线是否能安装。
7. 出问题怎么回滚。
8. 谁有权限操作服务器。

这些问题回答不出来，就不要说服务器已经准备好了。

学习路径：不要从命令大全开始背

Linux 学习最容易走偏：上来背一堆命令，真正到现场还是不知道先查什么。

建议按这个顺序学。

第一步，能认机器：

cat /etc/os-release
uname -a
uname -m
hostnamectl
timedatectl

你要知道这是什么系统、什么架构、什么时间、什么主机名。

第二步，能找东西：

pwd
ls -lah
find /opt -name "*.log" -type f
grep -R "关键字" /etc /opt 2>/dev/null
tail -n 200 -f /var/log/demo-app/app.log

你要能找到配置、日志、程序包和大文件。

第三步，能看服务：

systemctl status demo-app --no-pager
journalctl -u demo-app -n 200 --no-pager
ss -tulnp
ps -ef

你要能判断服务有没有跑、进程是谁、端口有没有监听。

第四步，能处理常见故障：

df -hT
du -xhd1 /var | sort -h
free -h
top
namei -l /path/to/file

你要能处理磁盘满、内存高、CPU 高、权限拒绝。

第五步，再补原理：

1. /proc 为什么能看到进程和内核信息。
2. systemd 为什么能托管服务。
3. 文件权限为什么目录需要 x。
4. TCP 端口监听和远程访问为什么不是一回事。
5. 文件系统、inode、挂载点为什么会影响磁盘排查。
6. cgroup、namespace、OverlayFS 这些再往后学，为 Docker 和 K8S 打基础。

原理不是单独背概念。比如后面讲 Docker 的 Overlay2 和 CoW，不是为了让你背 “lowerdir、upperdir、merged”，而是为了解释镜像层、容器可写层、磁盘占用、日志增长和数据为什么不能随便写在容器里。Linux 基础学到这里，后面的 Docker、K8S、Nginx、数据库运维才接得住。

落地工程深水区

Linux 基础真正拖垮生产交付的，通常不是某条命令不会用，而是团队没有统一“先看什么、谁能改什么、改完怎么验”的规则。下面这些问题要在项目早期定下来。

第一是发行版和版本基线。新项目不要默认沿用存量 CentOS 7，也不要同一套服务在 Ubuntu、Rocky、国产发行版之间随意混跑。至少要在发布文档里写清楚：支持哪些发行版、包管理器用什么、systemd 服务名是什么、日志在哪里。每次上线前执行：

cat /etc/os-release
uname -r
systemctl --version

第二是权限边界。生产排障需要读日志、看进程、查端口、重启服务，但不等于所有人都应该拿 root。建议把“部署用户”“运行用户”“应急 sudo 权限”拆开。权限问题先用 id、namei -l、sudo -l 查清楚，再决定是改属主、改目录权限、改 sudoers，还是查 SELinux/AppArmor，不要一上来 chmod 777。

第三是磁盘和日志。Linux 排障里最常见的事故之一就是根分区满、日志无限增长、删除大文件后空间不释放。上线前至少看：

df -hT
df -ih
du -xhd1 /var | sort -h
journalctl --disk-usage
lsof +L1

第四是网络链路。端口不通不要只盯防火墙。要按“进程监听 -> 本机访问 -> 防火墙 -> 路由/DNS -> 安全组/ACL -> 上游代理”排查。ss -lntp 证明进程是否监听，curl 127.0.0.1:端口 证明本机链路，远端再用 nc -vz 或 curl 证明外部链路。每一步只回答一个问题，别混在一起猜。

第五是监控和交接。Linux 基线至少要有 CPU、内存、磁盘、inode、端口、进程、日志错误、时间同步、文件句柄这些指标。没有监控时，排障只能靠人肉登录；没有交接模板时，下一次换人上线又会从零猜起。真正可维护的 Linux 能力不是记住多少命令，而是把命令沉淀成巡检脚本、发布前清单和故障记录。

常见问题命令速查

现象	先执行	看什么	常见原因
服务启动失败	systemctl status demo-app	是否 failed，错误原因	service 配置、路径、权限、依赖
应用日志没输出	journalctl -u demo-app -n 200	systemd 层错误	还没进入应用代码
端口不通	`ss -tulnp	grep ':8080'`	是否监听、监听地址
本机通远程不通	firewall-cmd --list-all / ufw status	端口是否放行	防火墙、安全组、ACL
权限拒绝	namei -l 路径	每级目录权限	属主错误、目录无 x、SELinux
磁盘满	df -hT	哪个分区满	日志、备份、临时文件
删除后空间没释放	lsof +L1	deleted 文件是否仍被占用	进程未重新打开文件
CPU 高	top	哪个进程占用高	死循环、GC、IO 等待
内存高	free -h、ps --sort=-%mem	available、进程内存	泄漏、配置过大、缓存
软件装不上	apt update / dnf makecache	源是否可达	DNS、代理、内网源、依赖

这张表可以直接当现场排障入口。先确认对象，再决定命令，不要靠感觉改配置。

官方文档入口

Linux 资料很多，正式落地时优先看官方和本机手册。

1. Linux Kernel Documentation：https://docs.kernel.org/
2. Linux man-pages：https://man7.org/linux/man-pages/
3. Filesystem Hierarchy Standard：https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
4. systemd：https://systemd.io/
5. systemctl manual：https://www.freedesktop.org/software/systemd/man/systemctl.html
6. Ubuntu Server Documentation：https://ubuntu.com/server/docs/
7. Red Hat Enterprise Linux Documentation：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/
8. Arch Wiki：https://wiki.archlinux.org/

本机上也可以直接查：

man systemctl
man journalctl
man ss
man chmod
man df
man du

这里要注意，本机 man page 通常和当前系统版本更匹配。网上文章可以参考，但生产操作前要以当前系统、当前版本、当前网络环境为准。