第 28/30 天（重访）
引言
首发版中我们学习了故障排查的基础四步法、GRUB 引导修复、journalctl 日志分析、OOM Killer 排查等入门到中级技能。今天这篇重访版将带你深入生产环境实战——当服务器出现更棘手的故障时，如何用专业工具进行深度诊断。
在真实运维场景中，常见的故障复杂度远超入门教程：内核崩溃需要分析 vmcore 来定位内存损坏点，文件系统损坏需要在不停机的情况下最小化恢复，生产环境突发性能问题需要用 perf 生成火焰图快速定位热点。本文将手把手带你走完这些高级故障排查场景，每个案例都来自真实生产事故。
一、高级内核调试：当 dmesg 不够用时
1.1 kdump + crash 工具：分析内核崩溃转储
当内核发生 panic 时，dmesg 和 journalctl 只能看到最后的消息，但无法深入分析崩溃时的内存状态。kdump 是 Ubuntu 内置的机制，能在内核崩溃时自动捕获内存快照（vmcore）。
配置 kdump：
# 安装 kdump 工具
sudo apt install linux-crashdump kdump-tools -y
# 查看配置状态
cat /etc/default/kdump-tools
# USE_KDUMP=1 # 启用
# KDUMP_CORESIZE=128 # 保留给 crash kernel 的内存（MB）
# KDUMP_KERNEL=/boot/vmlinuz-$(uname -r)
# 配置 GRUB 为 crash kernel 保留内存
sudo sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT=".*"/GRUB_CMDLINE_LINUX_DEFAULT="crashkernel=256M"/' /etc/default/grub
sudo update-grub
# 重启使配置生效
sudo reboot
使用 crash 分析 vmcore：
vmcore 文件通常保存在 /var/crash/ 目录下，格式为 YYYYMMDD/vmcore：
# 查看已捕获的 vmcore
ls -lah /var/crash/
# 安装 crash 工具
sudo apt install crash -y
# 获取当前内核调试符号
sudo apt install linux-image-$(uname -r)-dbgsym -y
# 在 /etc/apt/sources.list.d/ddebs.list 中添加：
# deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse
# deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse
# deb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted universe multiverse
# 然后 sudo apt update && sudo apt install linux-image-$(uname -r)-dbgsym
# 分析 vmcore（需要 vmlinux 调试符号文件）
sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/20260816/vmcore
# crash 内部命令：
crash> bt # 查看崩溃时的调用栈（backtrace）
crash> log # 查看内核日志缓冲区
crash> ps # 查看所有进程状态
crash> vm <PID> # 查看某个进程的内存映射
crash> files <PID> # 查看某个进程打开的文件
crash> kmem -i # 查看内核内存使用统计
crash> mod -S # 列出已加载的内核模块
crash> rd -p <addr> # 读取指定物理地址的内存内容
crash> sym <addr> # 将地址转换为符号名
crash> foreach bt # 对所有进程打印 backtrace
实战案例： 某次生产服务器每天凌晨 3:15 准时崩溃，通过分析 vmcore 发现是 ext4_mark_inode_dirty 在特定条件下触发了空指针解引用，最后定位到是内核 5.4 版本的已知 bug，升级到 5.15 后修复。
1.2 kgdb + 串口调试：实时内核调试
当 kdump 无法捕获（比如系统完全死锁）时，kgdb 可以通过串口远程调试正在运行的内核：
# 内核编译时需启用 kgdb 支持（Ubuntu 默认内核已包含）
# 使能串口控制台
sudo grubby --args="kgdboc=ttyS0,115200 kgdbwait" --update-kernel=$(grubby --default-kernel)
# 或编辑 /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="kgdboc=ttyS0,115200"
# 在另一台机器上使用 gdb 连接
gdb vmlinux
(gdb) target remote /dev/ttyUSB0
(gdb) bt
(gdb) lx-dmesg
(gdb) lx-ps
1.3 内核实时跟踪：ftrace 与 trace-cmd
ftrace 是 Linux 内核内置的跟踪框架，无需安装额外工具即可使用：
# 挂载 tracefs
sudo mount -t tracefs nodev /sys/kernel/tracing
# 查看可用的跟踪器
cat /sys/kernel/tracing/available_tracers
# function, function_graph, wakeup, irqsoff, preemptoff, etc.
# 跟踪特定函数
echo function > /sys/kernel/tracing/current_tracer
echo ext4_sync_file > /sys/kernel/tracing/set_ftrace_filter
echo 1 > /sys/kernel/tracing/tracing_on
# 运行触发操作
sync
echo 0 > /sys/kernel/tracing/tracing_on
cat /sys/kernel/tracing/trace | head -50
更便捷的方式是使用 trace-cmd：
sudo apt install trace-cmd -y
# 跟踪特定系统调用
sudo trace-cmd record -e syscalls:sys_enter_openat -e syscalls:sys_enter_read
# 跟踪某个进程的所有系统调用
sudo trace-cmd record -p function -P $(pgrep nginx)
# 查看结果
sudo trace-cmd report
二、文件系统深度救援：从 ext4 到 XFS 的生产级修复
2.1 ext4 文件系统损坏诊断
首发版中我们介绍了基础的 fsck 修复，但生产环境中的文件系统损坏往往更复杂：
# 查看 ext4 文件系统超级块信息
sudo dumpe2fs -h /dev/sda1 | grep -E "Block count|Block size|Filesystem state|Errors"
# Filesystem state: clean ← 正常
# Filesystem state: not clean ← 需要 fsck
# Filesystem state: errors ← 有错误
# 查看文件系统日志（磁盘操作已被记录但未提交）
sudo debugfs -R "logdump -a" /dev/sda1 | tail -50
# 查看超级块备份（ext4 默认在 block 32768, 98304, 163840, 229376...）
sudo mke2fs -n /dev/sda1 2>&1 | grep "superblock"
# 输出示例：Superblock backups stored on blocks: 32768, 98304, ...
# 使用备用超级块修复
sudo fsck.ext4 -b 32768 -y /dev/sda1
2.2 ext4 日志重放与修复的高级技巧
场景： 系统突然断电，文件系统标志为 needs_recovery，但 fsck -y 卡住或报错：
# 强制日志重放（不执行完整 fsck）
sudo mount -t ext4 -o ro,noload /dev/sda1 /mnt/rescue
# noload = 不加载日志，跳过重放 -> 挂载为只读，数据可能不完整
# 更安全的做法：强制重放日志并检查
sudo e2fsck -f -p /dev/sda1 # -p = 自动修复安全的问题
# 如果不行，使用更激进的模式
sudo e2fsck -f -y /dev/sda1 # -y = 自动回答 yes
# 检查具体 inode 的损坏情况
sudo debugfs -R "stat <12>" /dev/sda1 # 查看 inode 12 的状态
sudo debugfs -R "ls -l /lost+found" /dev/sda1 # 查看恢复的文件
# 从损坏的 ext4 分区导出关键数据
sudo debugfs -R "rdump / /tmp/recovered_data/" /dev/sda1
2.3 XFS 文件系统修复
Ubuntu 服务器版广泛使用 XFS（尤其是大容量存储场景）：
# 安装 XFS 工具
sudo apt install xfsprogs -y
# 检查 XFS 文件系统（必须在卸载状态下执行）
sudo xfs_repair -n /dev/sdb1 # -n = dry run（只检查不修复）
# 执行修复
sudo xfs_repair /dev/sdb1
# 查看 XFS 元数据信息
sudo xfs_info /dev/sdb1
# meta-data=/dev/sdb1 isize=512 agcount=4, agsize=65536 blks
# data = bsize=4096 blocks=262144, imaxpct=25
# naming =version 2 bsize=4096 ascii-ci=0, ftype=1
# log =internal bsize=4096 blocks=2560, version=2
# realtime =none extsz=4096 blocks=0, rtextents=0
# XFS 日志修复（当日志损坏时）
sudo xfs_repair -L /dev/sdb1 # -L = 清零日志（可能丢失最后的元数据操作）
# ⚠️ 注意：-L 会丢弃未提交的日志，可能导致数据不一致，但能让文件系统挂载
# 冻结 XFS 文件系统（创建快照前挂起 I/O）
sudo xfs_freeze -f /mount/point
# 创建 LVM 快照或备份
sudo xfs_freeze -u /mount/point # 解冻
2.4 Btrfs 故障排查
Ubuntu 默认使用 ext4，但 Btrfs 作为高级文件系统也越来越常见：
# 检查 Btrfs 文件系统
sudo btrfs check /dev/sdc1
# 查看 Btrfs 使用情况
sudo btrfs filesystem usage /mount/point
# Btrfs scrub（在线数据一致性检查，类似 RAID 的 patrol read）
sudo btrfs scrub start /mount/point
sudo btrfs scrub status /mount/point
# 从 Btrfs 快照恢复
sudo btrfs subvolume list /mount/point
sudo btrfs subvolume snapshot /mount/point/@snapshots/20260815 /mount/point/restored
三、网络层面深度排障：tcpdump 与包分析
3.1 tcpdump 生产级抓包技巧
首发版涵盖了 ss 和 netstat 等基础网络诊断，但当问题涉及应用层协议异常时，必须抓包分析：
# 安装 tcpdump
sudo apt install tcpdump -y
# 基础抓包：监听特定端口
sudo tcpdump -i eth0 port 80 -n -c 1000
# 进阶：抓取特定 TCP 状态（如 SYN 重传）
sudo tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn) != 0 and tcp[tcpflags] & (tcp-ack) == 0' -n
# 抓取 HTTP 请求内容（前 100 字节）
sudo tcpdump -i eth0 port 80 -X -s 100 -c 500
# 抓取 DNS 查询和响应
sudo tcpdump -i eth0 port 53 -n -v
# 抓取 TCP 重传和丢包
sudo tcpdump -i eth0 'tcp[13] & 4 != 0' -n # RST 标记
sudo tcpdump -i eth0 'tcp[13] & 8 != 0' -n # RST+ACK 标记
# 使用环形缓冲区（避免抓包文件撑爆磁盘）
sudo tcpdump -i eth0 -C 100 -W 10 -w /tmp/capture.pcap
# -C 100 = 每个文件 100MB，-W 10 = 最多 10 个文件（循环覆盖）
# 过滤特定 IP 对
sudo tcpdump -i eth0 host 10.0.0.5 and host 10.0.0.8 -n
3.2 使用 tshark 进行协议分析
tshark（Wireshark 的命令行版）比 tcpdump 更擅长协议解码：
# 安装
sudo apt install tshark -y
# 读取 pcap 文件并分析 HTTP 请求
tshark -r /tmp/capture.pcap -Y "http.request" -T fields
-e http.host -e http.request.uri -e http.request.method
# 分析 TCP 流延迟
tshark -r /tmp/capture.pcap -Y "tcp.analysis.ack_rtt" -T fields
-e tcp.analysis.ack_rtt
# 找出所有重传包
tshark -r /tmp/capture.pcap -Y "tcp.analysis.retransmission" -T fields
-e frame.time -e ip.src -e ip.dst -e tcp.port
# 分析 TLS 握手详情
tshark -r /tmp/capture.pcap -Y "tls.handshake.type == 1" -T fields
-e tls.handshake.ciphersuite
# 实时抓包并过滤 HTTP 请求
sudo tshark -i eth0 -Y "http.request" -T fields -e http.host -e http.request.uri
3.3 实战案例：诡异的 TCP 半连接问题
现象： 生产环境 Nginx 偶尔出现 Connection timed out，ss -s 显示大量 TIME_WAIT 连接，但应用一切正常。
排查过程：
# 1. 查看 TCP 连接状态统计
ss -s
# Total: 12345 (kernel 23456)
# TCP: 9876 (estab 1234, closed 8642, orphaned 0, synrecv 0, timewait 4321, ...)
# 2. 查看 TIME_WAIT 连接详情
ss -tan state time-wait | head -20
# 3. 抓包分析连接关闭过程
sudo tcpdump -i eth0 'tcp port 443' -n -c 5000 -w /tmp/https_timewait.pcap
# 4. 用 tshark 分析 FIN/ACK 序列
tshark -r /tmp/https_timewait.pcap -Y "tcp.flags.fin == 1" -T fields
-e frame.time -e ip.src -e ip.dst -e tcp.stream
# 5. 发现客户端大量发送 FIN 后未等待 2MSL 就重建连接
# 解决：调整 net.ipv4.tcp_fin_timeout 和 net.ipv4.tcp_tw_reuse
sudo sysctl -w net.ipv4.tcp_fin_timeout=15
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
四、性能火焰图：热点定位的终极武器
4.1 perf 性能分析
当系统负载高但排查不出瓶颈时，perf 是 Linux 性能分析的王牌工具：
# 安装 perf
sudo apt install linux-tools-common linux-tools-$(uname -r) -y
# 记录 CPU 事件采样（默认 1 秒采样 99 次）
sudo perf record -F 99 -a -g -- sleep 30
# -F 99 = 每秒 99 次采样
# -a = 所有 CPU
# -g = 记录调用栈
# sleep 30 = 采样 30 秒
# 生成火焰图（需要 FlameGraph 工具）
git clone https://github.com/brendangregg/FlameGraph.git /opt/FlameGraph
# 生成 folded stack 格式
sudo perf script | /opt/FlameGraph/stackcollapse-perf.pl > /tmp/out.perf-folded
# 生成 SVG 火焰图
/opt/FlameGraph/flamegraph.pl /tmp/out.perf-folded > /tmp/cpu_flame.svg
# 查看 top 热点函数
sudo perf report -n --stdio --sort comm,dso,symbol
# 记录特定进程
sudo perf record -F 99 -p $(pgrep -d',' mysqld) -g -- sleep 30
# 记录系统调用
sudo perf record -e syscalls:sys_enter_openat -a -- sleep 10
sudo perf script | head -20
4.2 内存泄漏排查
场景： 进程 RSS 持续增长，怀疑内存泄漏：
# 1. 确认内存增长趋势
watch -n 10 'ps -p $(pgrep -d"," mysqld) -o rss,vsz'
# 2. 使用 /proc 查看内存映射
cat /proc/$(pgrep mysqld)/smaps | grep -E "Pss|Size" | head -20
# 3. 使用 valgrind 检测（测试环境，效果显著但性能开销大）
sudo apt install valgrind -y
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all
--log-file=/tmp/valgrind.log ./your_app
# 4. 生产环境轻量级泄漏检测：/proc/$(pgrep mysqld)/status
grep VmRSS /proc/$(pgrep mysqld)/status
grep VmSize /proc/$(pgrep mysqld)/status
# 5. 使用 pmap 查看内存段
pmap -x $(pgrep mysqld) | sort -k3 -rn | head -10
# 6. 堆内存分析（使用 jemalloc 或 tcmalloc 的 profiler）
# 如果应用使用 jemalloc：
export MALLOC_CONF="prof:true,prof_prefix:/tmp/jeprof,lg_prof_interval:30"
# 然后用 jeprof 生成分析报告
4.3 磁盘 I/O 深度排查
当 iostat -x 1 显示 %util 达到 100% 时，需要进一步定位 I/O 的来源：
# 1. 安装 blktrace（块层 I/O 跟踪）
sudo apt install blktrace -y
# 2. 跟踪块设备 I/O
sudo blktrace -d /dev/sda -o /tmp/blk
# 3. 查看 I/O 延迟分布
sudo blkparse -i /tmp/blk -o /tmp/blkparse.txt
# 关注 D（磁盘请求）和 C（完成）的时间戳差
# 4. 使用 ioping 测量磁盘延迟
sudo apt install ioping -y
sudo ioping -c 100 /dev/sda
# 输出示例：min/avg/max/mdev = 48.2us / 89.3us / 1.2ms / 45.7us
# 5. I/O 级联分析：找出哪个进程在写
sudo iotop -oP -d 1
# -o = 只显示活跃的 I/O 进程
# -P = 只显示进程，不显示线程
# -d 1 = 每 1 秒刷新
# 6. 查看文件系统级别的 I/O 分布
sudo filetop -C # 需要 bcc 工具集
安装 bcc 工具集（强大的 BPF 性能分析套件）：
# Ubuntu 20.04+
sudo apt install bpfcc-tools linux-headers-$(uname -r) -y
# 常用 bcc 工具
sudo opensnoop-bpfcc # 跟踪文件打开操作
sudo execsnoop-bpfcc # 跟踪新进程创建
sudo ext4slower-bpfcc 1 # 显示 ext4 中慢于 1ms 的操作
sudo biolatency-bpfcc # 显示 I/O 延迟直方图
sudo tcplife-bpfcc # 跟踪 TCP 连接生命周期
五、容器环境故障排查：Docker 与 systemd-nspawn
5.1 Docker 容器故障排查
# 查看容器日志（受限于日志驱动配置）
docker logs --tail 100 --timestamps <container>
# 进入容器内部排查
docker exec -it <container> /bin/bash
# 查看容器资源使用
docker stats <container>
# 查看容器进程树（主机视角）
ps aux | grep <container-name>
# 容器网络排障
docker network inspect bridge
docker exec <container> ip addr
docker exec <container> ping -c 3 google.com
# 查看容器挂载卷
docker inspect <container> | jq '.[].Mounts'
# 容器 OOM 排查
dmesg | grep -i "docker|oom"
journalctl -u docker.service -p err
5.2 容器内部 core dump 分析
# 在主机上启用容器 core dump
echo '/tmp/core.%p.%u.%s' | sudo tee /proc/sys/kernel/core_pattern
# 或对特定容器配置
docker run --ulimit core=-1 --security-opt seccomp=unconfined
-v /tmp/cores:/cores <image>
# 分析容器内 core dump
# 需要容器内相同版本的二进制文件
gdb /path/to/binary /tmp/core.1234
(gdb) bt full
(gdb) info registers
(gdb) thread apply all bt
5.3 systemd-nspawn 容器排障
# 查看容器状态
machinectl status <container>
# 进入容器
machinectl shell <container> /bin/bash
# 查看容器日志（journald 自动隔离）
journalctl -M <container> -p err -b
# 容器网络调试
# 主机侧：
ip netns exec <container-ns> ip addr
# 或通过 machinectl：
machinectl login <container>
六、生产事故复盘：WAR Stories 与核心教训
案例一：ext4 日志损坏导致 4 小时恢复
背景： 某云服务器因 Hypervisor 异常导致磁盘 I/O 写入错误，ext4 日志损坏。
症状： mount 报错 EXT4-fs: failed to mount because of unsupported optional features，fsck 跑一半卡死。
恢复过程：
# 1. 尝试 noload 挂载（跳过日志）
sudo mount -t ext4 -o ro,noload /dev/vda1 /mnt/rescue
# 2. 成功挂载后立即备份关键数据
sudo rsync -av /mnt/rescue/var/lib/mysql /root/backup/
sudo rsync -av /mnt/rescue/etc /root/backup/
# 3. 卸载后强制修复
sudo umount /mnt/rescue
sudo e2fsck -f -y /dev/vda1
# 修复过程：重建日志、清理孤儿 inode
# 4. 重新挂载并验证
sudo mount /dev/vda1 /mnt/rescue
sudo fsck -n /dev/vda1 # 确认 clean
教训： 先挂载 noload 备份数据再修复！不要直接 fsck -y，因为修复过程可能造成更多数据丢失。
案例二：Nginx 性能抖动与 perf 火焰图
背景： 某电商平台在大促期间 Nginx 响应时间间歇性从 50ms 飙升到 5s。
排查：
# 1. 用 perf 采样 30 秒
sudo perf record -F 99 -p $(pgrep -d',' nginx) -g -- sleep 30
# 2. 生成火焰图
sudo perf script | /opt/FlameGraph/stackcollapse-perf.pl > /tmp/nginx.folded
/opt/FlameGraph/flamegraph.pl /tmp/nginx.folded > /tmp/nginx_flame.svg
# 3. 火焰图显示 Nginx 在 ngx_ssl_handshake 中消耗 62% 的 CPU
# 根因：SSL 证书链过长（4 级中间证书），每次握手都做完整链验证
# 4. 优化方案
# - 启用 SSL session cache
# - 使用 OCSP stapling
# - 缩短证书链
# - 启用 Nginx 的 ssl_early_data
教训： 火焰图让性能瓶颈可视化，几十秒就能定位到问题热点。
案例三：Btrfs 快照写满磁盘
背景： 自动备份脚本每天创建 Btrfs 快照，但未清理旧快照，6 个月后磁盘空间耗尽。
排查：
# 1. df 显示磁盘已满，但 du 找不到大文件
df -h /data
# 显示 Used=100%，但 du -sh /data/* 只有 30%
# 2. Btrfs 专属分析
sudo btrfs filesystem df /data
# 显示 Data, Metadata, System 使用情况
sudo btrfs filesystem usage /data
# 发现 Data 占用异常高
# 3. 列出所有子卷和快照
sudo btrfs subvolume list -s /data
# 输出 180+ 个快照！
# 4. 删除过期快照
sudo btrfs subvolume delete /data/.snapshots/old-*
教训： 文件系统级的快照（LVM、Btrfs、ZFS）不会体现在 du 中，必须用文件系统本身的工具查看。
七、建立生产事故应急响应体系
7.1 Incident Response Playbook 模板
# 标准事故响应流程（SIRP）
## 第一阶段：Triage（5 分钟内）
- [ ] 确认影响范围（哪些用户/服务受影响？）
- [ ] 收集当前状态快照（top、dmesg、journalctl -b）
- [ ] 通知团队（通过 IM 或电话）
## 第二阶段：Mitigation（15 分钟内）
- [ ] 执行标准恢复方案
- [ ] 如需回滚，确认回滚版本
- [ ] 记录所有操作时间戳
## 第三阶段：Root Cause（1 小时内）
- [ ] 收集日志和 vmcore
- [ ] 分析根因
- [ ] 编写 RCA 文档
## 第四阶段：Prevention
- [ ] 实施修复方案
- [ ] 更新监控告警
- [ ] 更新 Playbook
7.2 自动故障检测脚本
#!/bin/bash
# /usr/local/bin/health-check.sh — 每 5 分钟运行
set -e
ALERT_THRESHOLD=5 # 连续失败 5 次触发告警
FAIL_COUNT_FILE="/tmp/health_fail_count"
# 检查函数
check_service() {
if ! systemctl is-active --quiet "$1"; then
echo "CRITICAL: $1 is not running"
systemctl restart "$1" 2>/dev/null
return 1
fi
return 0
}
check_disk() {
local usage=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')
if [ "$usage" -gt 90 ]; then
echo "WARNING: Disk usage at ${usage}%"
return 1
fi
return 0
}
check_memory() {
local free=$(free -m | awk '/^Mem:/{print $7}')
if [ "$free" -lt 500 ]; then
echo "WARNING: Only ${free}MB free memory"
return 1
fi
return 0
}
# 执行检查
FAILURES=0
check_service nginx || ((FAILURES++))
check_service mysql || ((FAILURES++))
check_disk || ((FAILURES++))
check_memory || ((FAILURES++))
# 累计失败计数
if [ "$FAILURES" -gt 0 ]; then
echo "$(( $(cat "$FAIL_COUNT_FILE" 2>/dev/null || echo 0) + 1 ))" > "$FAIL_COUNT_FILE"
else
echo 0 > "$FAIL_COUNT_FILE"
fi
# 触发告警
if [ "$(cat "$FAIL_COUNT_FILE" 2>/dev/null || echo 0)" -ge "$ALERT_THRESHOLD" ]; then
curl -s -X POST "https://api.alerting.team/v1/alert"
-H "Content-Type: application/json"
-d "{"text": "Production health check failed ${FAILURES} times"}"
echo 0 > "$FAIL_COUNT_FILE"
fi
总结
今天重访版的故障排查实战，我们从首发版的基础四步法进阶到了生产级深度排障工具链：
- 内核级调试：kdump + crash 分析 vmcore、ftrace 内核跟踪
- 文件系统深度救援：ext4 超级块恢复、XFS 日志修复、Btrfs 快照管理
- 网络包级排障：tcpdump 高级过滤、tshark 协议分析、TCP 半连接排查
- 性能火焰图：perf 采样 + FlameGraph 生成可视化热点分析
- 容器排障：Docker 内部调试、core dump 分析、systemd-nspawn
- 生产事故复盘：三个真实 WAR Stories 及核心教训
- 应急响应体系：Playbook 模板、自动健康检测脚本
核心原则： 故障排查的本质是数据驱动——vmcore、perf 采样、tcpdump 包捕获、ftrace 跟踪，这些原始数据不会说谎。学会用专业工具采集和分析这些数据，你就能在复杂故障面前保持冷静。
下期预告
明天（第 29 天重访）我们将进入Ubuntu 社区与文档的进阶话题——从提交流程到参与社区治理，从 Bug 报告的艺术到成为 Ubuntu 贡献者的路径。
系列目录
| 天数 | 主题 | 状态 |
|---|---|---|
| 第 1 天 | Ubuntu 简介与版本选择 | ✅ |
| 第 2 天 | 手把手安装 Ubuntu | ✅ |
| 第 3 天 | GNOME 桌面与软件中心 | ✅ |
| 第 4 天 | 终端基础与文件系统 | ✅ |
| 第 5 天 | 用户与权限管理 | ✅ |
| 第 6 天 | 软件包管理全面对比 | ✅ |
| 第 7 天 | 文件与文本操作实战 | ✅ |
| 第 8 天 | systemd 与 systemctl 完全指南 | ✅ |
| 第 9 天 | 磁盘与文件系统管理 | ✅ |
| 第 10 天 | 网络配置与防火墙 | ✅ |
| 第 11 天 | 进程管理与监控 | ✅ |
| 第 12 天 | 计划任务与自动化 | ✅ |
| 第 13 天 | 备份与恢复策略 | ✅ |
| 第 14 天 | 系统更新与升级管理 | ✅ |
| 第 15 天 | SSH 远程管理与安全加固 | ✅ |
| 第 16 天 | Web 服务器搭建 | ✅ |
| 第 17 天 | 数据库服务器部署 | ✅ |
| 第 18 天 | Docker 容器化管理 | ✅ |
| 第 19 天 | 文件共享服务 | ✅ |
| 第 20 天 | 监控与告警系统 | ✅ |
| 第 21 天 | 邮件服务器基础 | ✅ |
| 第 22 天 | 系统安全加固 | ✅ |
| 第 23 天 | 性能调优与内核参数 | ✅ |
| 第 24 天 | 虚拟化技术 | ✅ |
| 第 25 天 | 容器编排入门 | ✅ |
| 第 26 天 | 高可用与负载均衡 | ✅ |
| 第 27 天 | Ubuntu 自动部署 | ✅ |
| 第 28 天 | 故障排查实战 | ✅ |
| 第 29 天 | Ubuntu 社区与文档 | ✅ |
| 第 30 天 | 30 天回顾总结 | ✅ |
| 第 28 天（重访） | 故障排查实战——深度内核调试、文件系统救援与生产级排障 | 🟢 今日 |
| 第 29 天（重访） | Ubuntu 社区与文档 | ⏳ |
| 第 30 天（重访） | 30 天回顾总结 | ⏳ |
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
暂无评论内容