场景
某微服务应用部署在4核8G的Linux服务器上，运行Nginx和Node.js进程。突然，监控告警显示HTTP 502错误率飙升，用户无法访问。
症状
- 服务器负载平均值超过10（正常<2）
- I/O等待时间超过30%
- SSH连接响应缓慢
- dmesg显示大量"hung_task_timeout_secs"错误
诊断步骤
-
检查系统负载
bash uptime top -bn1 | head -5显示load average: 12.5, 10.3, 8.7。 -
识别高消耗进程
bash ps aux --sort=-%cpu | head -10 ps aux --sort=-%mem | head -10发现Nginx worker进程CPU占用300%，疑似陷入无限循环。 -
分析I/O瓶颈
bash iostat -x 1 3%util接近100%，await>100ms，磁盘性能不足。 -
检查磁盘空间和inode
bash df -h / df -i /磁盘使用率85%，inode正常，但日志文件增长过快。 -
查看系统日志
bash tail -100 /var/log/messages | grep -i error发现文件系统日志错误："EXT4-fs error: journal has aborted"。 -
检查文件系统一致性
bash touch /test && sync && rm /test # 测试写入如果失败，建议在维护窗口执行fsck，但生产环境需谨慎。
风险控制
- 避免在业务高峰期执行fsck：可能导致数据丢失。
- 先尝试只读挂载：
bash mount -o remount,ro /dev/sda1 / - 备份关键数据：使用
dd或rsync备份前先确认。
回滚步骤
如果怀疑是近期变更导致（如配置更新或内核补丁）：
1. 回滚应用版本：
bash
systemctl restart nginx # 或加载旧配置
2. 回滚内核（需重启）：
bash
grub2-set-default "CentOS Linux (3.10.0-1160.el7.x86_64) 7 (Core)"
reboot
3. 如果文件系统损坏，从备份恢复或使用LVM快照回滚。
验证方法
- 确认负载恢复正常：
uptime - 确认I/O下降：
iostat -x 1 2 - 确认服务可用：
curl -I http://localhost/health - 查看监控仪表板：错误率下降至0。
何时提交OpsGlobal工单
- 上述步骤无法解决问题
- 需要文件系统修复(
fsck)且无法停机 - 怀疑硬件故障（如磁盘坏道）
- 需内核调试或性能调优
- 需长期根因分析或架构优化
提交工单时请附上：
- dmesg和/var/log/messages日志
- top和iostat输出
- 变更记录时间线
通过本文的标准化流程，SRE团队可以快速定位生产问题并恢复服务，同时通过OpsGlobal获得专家级支持。
适用场景
适合正在处理 DevOps、Linux, SRE, 故障排查, Runbook 相关问题的团队，用于快速建立排查路径和交付标准。
问题背景
本文通过真实场景，详细讲解Linux生产服务器故障排查的标准化流程，包括症状识别、诊断命令、风险控制、回滚步骤及升级条件，帮助SRE团队高效解决问题。
排查步骤
先确认影响范围和最近变更，再收集日志、配置、指标和链路数据，最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名，并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径，避免扩大故障影响。
回滚方案
保留原配置和发布版本；如修复后指标异常，立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题？
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题，可以提交日志和配置文件，我们帮你远程诊断。