2. RHEL生产环境基线认知
在生产环境中排查故障，最忌讳的是“上来就敲命令”。真正高效的诊断，建立在对系统正常基线（Baseline）的清晰认知之上——知道正常长什么样，才能一眼看出异常在哪里。本节围绕 RHEL 的启动流程、关键子系统、日志体系、性能指标和故障域划分五个维度，建立一套可复用的诊断坐标系。
一、启动流程：故障定位的第一条时间轴
RHEL 7 及以后版本采用 systemd 作为初始化系统，启动流程可拆解为一条清晰的时间轴：
- 固件阶段（BIOS/UEFI）：POST 自检，选择启动设备，加载引导程序。
- GRUB2 阶段：读取
/boot/grub2/grub.cfg，加载内核（vmlinuz）与 initramfs 到内存。 - 内核初始化：解压内核，探测硬件，挂载 initramfs 作为临时根文件系统，加载存储驱动。
- initramfs 切换根：找到真实根文件系统，执行 switch_root，移交控制权给 systemd。
- systemd 用户空间：按 default.target 拉起各单元，并行启动服务，最终到达多用户或图形目标。
这条时间轴的价值在于：故障发生在哪个阶段，决定了你能看到什么现象、能用什么工具。例如卡在 GRUB 阶段，系统根本进不了 shell，只能靠救援模式；而卡在 systemd 阶段，则可以用 systemctl 和 journalctl 精细定位。判断当前启动阶段，可用 systemd-analyze 查看各阶段耗时：
systemd-analyze
# Startup finished in 2.1s (firmware) + 3.4s (loader) + 5.2s (kernel) + 18.7s (userspace) = 29.4s
systemd-analyze blame | head -5
# 12.3s NetworkManager-wait-online.service
# 4.1s kdump.service
# 2.8s tuned.service若 userspace 阶段异常漫长，blame 子命令会直接列出耗时最长的单元，这是定位“开机慢”最直接的入口。
二、关键子系统：故障域的天然边界
RHEL 生产系统的运行依赖若干关键子系统，它们既是功能载体，也是故障域的天然边界。理解每个子系统的职责与依赖，才能在故障发生时快速缩小范围：
- 存储子系统：LVM、文件系统（XFS/ext4）、多路径（multipath）、iSCSI。故障表现为 I/O 错误、挂载失败、空间耗尽。
- 网络子系统：NetworkManager、firewalld、路由、DNS。故障表现为连通性中断、端口不通、解析失败。
- 服务管理子系统：systemd 单元、依赖关系、资源限制（cgroup）。故障表现为服务起不来、反复重启、资源被限。
- 认证与权限子系统：PAM、SSSD、SELinux。故障表现为登录失败、权限拒绝、上下文错误。
- 内核与资源子系统：CPU 调度、内存管理、OOM Killer、内核参数。故障表现为系统卡顿、进程被杀、负载异常。
这五个子系统之间存在依赖链：网络依赖内核驱动，服务依赖网络和存储，认证依赖网络（若用 LDAP/AD）。因此排障时要顺着依赖链判断“根因在上游还是下游”。
三、日志体系：证据的采集与关联
RHEL 的日志体系以 journald + rsyslog 双轨制为核心。journald 负责收集内核与用户空间的结构化日志，rsyslog 负责将日志持久化到 /var/log/ 下的文本文件。两者关系是：journald 是“实时总线”，rsyslog 是“归档仓库”。
| 日志位置 | 内容 | 典型用途 |
|---|---|---|
journalctl -b | 本次启动的全部日志 | 启动故障、服务崩溃 |
/var/log/messages | 系统级常规消息 | 综合排查 |
/var/log/secure | 认证、sudo、SSH | 登录失败、权限问题 |
/var/log/dmesg | 内核环形缓冲 | 硬件、驱动、OOM |
/var/log/boot.log | 启动过程输出 | 服务启动顺序问题 |
排障时的关键动作是时间对齐：把 journalctl 的时间戳与 dmesg、应用日志对齐，才能还原事件发生的先后顺序。例如 journalctl --since "10 min ago" -p err 可快速筛出近十分钟的错误级别日志。
四、性能指标：用数据说话
性能诊断的核心是“四象限”：CPU、内存、磁盘 I/O、网络。每个象限都有对应的观测工具和关键指标：
- CPU：
top/mpstat看 %us、%sy、%wa、%id。%wa 高说明 I/O 瓶颈，%sy 高说明内核态开销大。 - 内存：
free -m看 available 而非 free；vmstat看 si/so（换页），持续非零说明内存压力大。 - 磁盘：
iostat -x 1看 %util、await、r/s、w/s。%util 接近 100% 说明设备饱和。 - 网络：
ss -s看连接状态，sar -n DEV 1看吞吐与丢包。
需要强调的是：单点指标高不等于故障。例如 %util 100% 在顺序写场景下可能是正常的。判断异常必须结合业务负载、历史基线和多指标交叉验证。
五、故障域划分：从现象到根因的映射
把上述四个维度整合起来，就形成了故障域划分的思维框架。下图展示了从“用户可见现象”到“可能故障域”的映射关系，以及每个故障域对应的首要排查工具：
这张映射图的使用方法是从右往左反查：当你观察到某个现象时，先锁定它可能属于哪个故障域，再直接调用对应的工具集，而不是盲目地逐个命令试。例如“服务不可用”，先看 systemctl status 判断是启动失败还是运行中崩溃，再顺着依赖链检查网络和存储是否正常。
sar -o /var/log/sa/baseline 1 60 采集一小时性能数据，并保存 systemctl list-units --state=running 的输出。故障时与基线对比，异常会立刻显现。
getenforce 看模式，再 ausearch -m avc -ts recent 看拒绝记录，最后 firewall-cmd --list-all 确认端口。
总结来说，RHEL 生产环境基线认知的本质是建立一张“正常状态地图”：启动流程告诉你系统怎么走到今天，关键子系统告诉你功能由谁承载，日志体系告诉你证据在哪里，性能指标告诉你资源是否健康，故障域划分告诉你从哪里下手。这五者合在一起，就是后续所有诊断动作的坐标系。