一、SRE 故障排查方法论（先背这个🔥）

👉 标准流程：

现象 → 定位范围 → 收集数据 → 分析 → 验证 → 修复 → 复盘

👉 三板斧（必须熟）：

• ss / tcpdump
  （网络）
• top / pidstat
  （CPU）
• iostat
  （IO）

二、案例1：CPU 飙高（容器导致）

🎯 现象

• CPU 100%
• 系统响应慢
• K8s Pod 卡顿

🔍 定位

toppidstat -u1

发现：

• 某个容器进程 CPU 占用 300%+

👉 深入分析（RHEL10重点）

dnf install -y bpftracebpftrace -e 'profile:hz:99 { @[comm] = count(); }'

🧠 根因

• 应用死循环（代码问题）
• 或线程未释放

🛠️ 解决

podman stop <container>

🔒 预防

• 限制 CPU：

podman run --cpus=1

• 接入监控

🎤 面试表达

我通过 eBPF 定位 CPU 热点进程，比传统 top 更精准

三、案例2：磁盘 IO 100%（数据库卡死）

🎯 现象

• MySQL 卡顿
• 系统 load 很高

🔍 定位

iostat -x1

发现：

• %util = 100%

iotop

发现某进程 IO 很高

🧠 根因

• 日志写入过多
• 或磁盘性能瓶颈

🛠️ 解决

• 限制日志
• 临时重启服务

🔒 预防

• 使用 SSD / NVMe
• 日志分盘

四、案例3：端口通但访问超时（最常见🔥）

🎯 现象

telnet80 OKcurl 超时

🔍 定位

ss -lntp

确认服务在监听

tcpdump -i eth0 port 80

发现：

• 请求到了
• 没有响应

🧠 根因

• 应用线程池耗尽
• 或后端服务挂了

🛠️ 解决

• 重启服务
• 扩容线程池

🔒 预防

• 接入限流
• 健康检查

🎤 面试亮点

网络没问题，问题在应用层

五、案例4：SSH 无法登录

🎯 现象

• SSH 超时 / 拒绝

🔍 定位

ss -lntp | grep22

journalctl -u sshd

🧠 根因

• sshd 挂了
• 或防火墙问题
• 或 SELinux 拦截

🛠️ 解决

systemctl restart sshdsetenforce 0（临时）

🔒 预防

• 监控 sshd
• 保留控制台入口

六、案例5：DNS 解析失败（经典）

🎯 现象

ping 域名失败ping IP 正常

🔍 定位

cat /etc/resolv.conf

dig www.baidu.com

🧠 根因

• DNS 配置错误
• 或 DNS 服务不可用

🛠️ 解决

echo "nameserver 8.8.8.8"  > /etc/resolv.conf

🔒 预防

• 配置多个 DNS
• 本地缓存 DNS

七、案例6：内存不高但系统卡死（高级🔥）

🎯 现象

• free 内存正常
• 系统卡

🔍 定位

vmstat 1

关注：

• wa
  （IO等待）

🧠 根因

• IO 等待导致假死

🛠️ 解决

• 优化磁盘
• 限制 IO

🎤 面试亮点

CPU 不高不代表系统健康，关键看 IO wait

八、案例7：服务频繁自动重启（systemd问题）

🎯 现象

• 服务反复重启

🔍 定位

systemctl status nginxjournalctl -u nginx

🧠 根因

• 配置错误
• systemd restart策略

🛠️ 解决

Restart=on-failure

九、RHEL10 高级排障（加分项🔥）

1️⃣ eBPF 排障（核心能力）

bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s\n", comm); }'

👉 用途：

• 性能分析
• 安全分析

2️⃣ 容器排障（重点）

podman logs <container>podman inspect <container>

3️⃣ 网络深度排查

ss -snetstat -s

十、总结（面试收尾🔥）

👉 你可以这样说：

在 RHEL10 环境下，我建立了一套标准化故障排查体系：

• 基于 CPU / IO / 网络三维定位问题
• 引入 eBPF 提升内核级观测能力
• 针对常见故障形成自动化修复策略

最终将故障处理从“人工经验”升级为“体系化SRE能力”