深入掌握Linux SRE手册：生产环境故障排查实战指南

场景

您的组织在生产环境中运行基于Linux节点的Kubernetes集群。值班SRE收到警报，应用程序响应延迟增加，并偶尔出现HTTP 503错误。集群使用多个工作节点，但其中一台节点持续显示高负载平均值。业务影响在高峰时段尤为明显。

症状

• 应用程序响应时间p95从300毫秒飙升至2秒以上。
• kubectl top nodes 显示某个节点CPU/内存使用率过高。
• 用户报告间歇性超时。
• 节点负载平均值（1分钟）超过CPU核心数。
• dmesg 显示OOM（内存耗尽）事件或磁盘I/O警告。

诊断

从高层面开始，逐步缩小范围。使用以下Linux命令收集证据。

1. 检查整体系统负载

uptime 给出1分钟、5分钟和15分钟的负载平均值。1分钟负载显著高于15分钟负载表明最近出现峰值。

top -b -n 1 按CPU使用率排序显示进程。注意 wa（I/O等待）和 st（窃取时间）。

2. 分析CPU和内存

vmstat 1 5 报告进程、内存、分页、块I/O、陷阱和CPU活动。关注 r（可运行进程）、b（阻塞进程）、si、so（换入/换出）、us、sy、id、wa。

free -m 显示内存使用情况。检查可用内存是否不足，交换分区使用率是否过高。

ps aux --sort=-%mem | head -20 识别内存占用最高的进程。

3. 检查磁盘I/O

iostat -x 1 报告磁盘利用率、I/O等待和队列长度。高 %util 或高 await 表明磁盘瓶颈。

df -h 检查文件系统空间；磁盘已满会导致应用程序故障。

4. 查看系统日志

dmesg -T | tail -30 显示内核消息，包括OOM killer事件、硬件错误或文件系统问题。

journalctl -u kubelet --since "1 hour ago" 突出显示kubelet问题（例如卷挂载失败、节点状态切换）。

5. 检查Kubernetes节点健康

kubectl describe node <节点名称> 显示MemoryPressure、DiskPressure、PIDPressure等条件，并显示容器运行时问题。

kubectl get events --sort-by='.lastTimestamp' 显示最近的集群事件。

风险控制

• 上述所有命令都是只读的，对生产环境安全。
• 除非明确批准，否则不要在生产节点上运行 stress 或 sysbench。
• 避免对关键进程执行 kill -9；只有在确认进程不是问题原因后，才使用 systemctl restart。
• 在进行任何配置更改之前，保存当前设置（例如 sysctl -a > /tmp/sysctl.bak）。

回滚

• 如果调整了内核参数（例如 sysctl -w vm.swappiness=10），使用 sysctl -p /etc/sysctl.conf 或重启来恢复。
• 如果修改了Kubernetes节点标签或污点，使用 kubectl label node <节点名称> <键>- 或 kubectl taint node <节点名称> <键>- 立即还原。
• 如果重启了kubelet，请监控；如果失败，使用 systemctl status kubelet 查看错误并还原修改的文件。

验证

应用修复后，重新运行关键命令：

• uptime 应显示负载平均值下降。
• vmstat 应显示低 wa 和大量空闲CPU。
• 应用程序p95延迟应回到基线。
• kubectl get nodes 显示所有节点状态为 Ready。

何时向OpsGlobal提交工单

在以下情况下联系OpsGlobal： - 在您执行基本步骤后问题仍然存在。 - 需要24/7持续观察。 - 根本原因超出您团队的Linux或Kubernetes专业知识范围。 - 需要对影响性能的更改获得独立的第二意见。

我们的SRE团队可以接手故障排查，应用热修复，并提供详细的后期分析。