1. 课程导入与故障诊断工程化思维
RHEL 生产环境的故障诊断，本质上不是“凭经验猜问题”，而是一项可重复、可验证、可交付的工程活动。很多工程师在遇到服务不可用、系统卡顿、磁盘写满或网络中断时，第一反应是登录机器敲几条命令，看到什么异常就改什么。这种做法在单机测试环境里可能侥幸奏效，但在承载业务的生产环境中，随意变更会放大故障范围，甚至把一次局部故障演变成全局事故。本课程要建立的，正是把“救火”转化为“诊断—定位—恢复—验证”的工程化思维。
一、RHEL 生产故障的分类
要工程化地处理故障，先要能对故障分层归类。RHEL 生产故障通常可以按资源域和表现形态划分为几大类，每一类对应的排查入口和工具链差异很大。
- 计算与进程类：CPU 饱和、负载异常升高、进程僵死、OOM Killer 触发、systemd 服务反复重启。典型入口是
top、ps、systemctl status、dmesg。 - 内存类：物理内存耗尽、swap 频繁换入换出、内存泄漏、大页配置不当。入口是
free、vmstat、/proc/meminfo。 - 存储与文件系统类：磁盘写满、inode 耗尽、文件系统只读、LVM 扩容失败、多路径链路抖动。入口是
df -h、df -i、lsblk、dmesg。 - 网络类：链路不通、丢包、DNS 解析失败、防火墙规则误拦截、bond/team 切换异常。入口是
ip、ss、ping、traceroute、firewall-cmd。 - 服务与应用类：服务启动失败、端口未监听、依赖服务不可达、配置语法错误、SELinux 拒绝。入口是
journalctl、systemctl、ausearch。 - 内核与硬件类：内核 panic、驱动异常、磁盘坏道、网卡故障。入口是
dmesg、kdump、smartctl、ipmitool。
分类的意义在于：它决定了你第一时间应该看什么、不该动什么。例如磁盘写满时，盲目重启服务往往无效，因为根因在存储层；而服务反复重启时，如果只盯着磁盘，就会错过 systemd 的启动依赖问题。
二、故障诊断的四条核心原则
原则一：先止损，后定位。 生产环境的首要目标是恢复业务，而不是当场把根因查个水落石出。如果可以通过切换、限流、回滚快速恢复，应优先执行，再在可控窗口内做根因分析。止损与定位并不矛盾，但顺序不能颠倒。
原则二：先观察，后变更。 在动手修改任何配置之前，先采集现场证据：当前时间、负载、进程、日志、网络连接、挂载状态。很多故障的“现场”一旦被重启或清理就永久丢失。建议在变更前执行一次快照式采集，例如记录 uptime、free -m、df -h、ss -s 的输出。
原则三：从底层向上排查。 遵循“硬件—内核—系统—服务—应用”的顺序。网络不通时，先确认网卡链路和 IP 配置，再看路由和防火墙，最后才怀疑应用。自底向上可以避免在错误的层级浪费时间。
原则四：单一变量验证。 每次只改一个因素，改完立即验证。同时修改多个参数，即使问题解决了，也无法知道是哪一个改动起了作用，更无法沉淀为可复用的经验。
三、恢复目标：RTO 与 RPO
恢复不是“让机器能登录”就算完成，而是要让业务恢复到可接受的状态。这里有两个关键指标：RTO（恢复时间目标） 和 RPO（恢复点目标）。RTO 描述业务能容忍多长的中断时间，RPO 描述能容忍丢失多少数据。例如某订单系统要求 RTO 为 30 分钟、RPO 为 5 分钟，那么故障恢复方案必须保证半小时内业务可用，且数据丢失不超过最近 5 分钟。
这两个指标直接决定了恢复策略的选择：RTO 很短时，可能需要主备切换或集群自动故障转移；RPO 很小时，必须依赖持续的数据复制或频繁的增量备份。诊断工程师必须清楚当前系统的 RTO/RPO 约束，否则“恢复”可能只是表面可用，实际已造成不可接受的数据损失。
四、课程整体路线图
本课程共 30 章，整体遵循“思维—工具—分层诊断—恢复—复盘”的工程路径。前几章建立故障分类、诊断原则与恢复目标；随后进入日志、性能、存储、网络、服务等分层诊断方法；再深入到具体故障场景的恢复操作与验证；最后落到故障复盘与预防机制建设。每一章都会围绕真实生产对象展开，强调可观察、可操作、可验证。
五、从“救火”到“工程化”的关键转变
工程化思维的核心，是把每一次故障处理都当作一次可复用的工程实践。具体体现在三个方面：第一，有预案。对高频故障场景提前准备检查清单和恢复步骤，而不是临场发挥。第二，有记录。故障时间、现象、采集数据、变更动作、恢复结果都要留痕，形成可追溯的时间线。第三，有验证。恢复后必须验证业务指标，而不仅是服务进程存在。例如 Web 服务恢复后，应实际发起一次请求并检查返回码与响应时间，而不是只看 systemctl status 显示 active。
下面给出一份可直接使用的故障现场采集清单，用于在变更前快速固定证据。字段可根据实际环境增删，但建议保留时间戳与命令输出对应关系。
| 采集项 | 命令示例 | 观察重点 |
|---|---|---|
| 系统时间与运行时长 | date; uptime | 负载值、是否刚重启 |
| 内存与 swap | free -m; vmstat 1 5 | 可用内存、si/so 是否非零 |
| 磁盘与 inode | df -h; df -i | 使用率是否接近 100% |
| 进程与资源占用 | ps aux --sort=-%cpu | head | 异常高占用进程 |
| 网络连接 | ss -s; ss -tlnp | 监听端口、连接数异常 |
| 内核与硬件日志 | dmesg -T | tail -50 | OOM、I/O 错误、链路抖动 |
| 服务状态 | systemctl --failed | 失败单元及最近日志 |
reboot、systemctl restart 或清理日志文件，除非已确认这是止损方案的一部分。本课程后续所有章节，都会围绕上述分类、原则与恢复目标展开。你需要在学习过程中逐步建立自己的诊断决策路径：看到现象，能快速判断属于哪一类故障；动手之前，能明确当前 RTO/RPO 约束；处理之后，能用业务指标验证恢复是否真正达成。这才是 RHEL 生产故障诊断与恢复工程化的起点。