1. 服务器故障排查基础入门刚入行做运维那会儿我最怕半夜接到报警电话。记得有次凌晨三点线上商城突然宕机手忙脚乱查了半天才发现是磁盘满了。其实服务器故障就像人生病早期症状往往有规律可循。今天我就把十年踩坑经验总结成这套望闻问切诊断法。硬件层检查永远是第一步。就像医生先测体温血压我们要先看服务器生命体征电源指示灯是否正常风扇有没有异响我有次遇到服务器反复重启折腾两小时最后发现是机柜PDU插座接触不良。推荐这个检查清单电源测试备用电源模块检查UPS电池状态存储RAID卡告警灯硬盘SMART健康度散热CPU/GPU温度风扇转速曲线网络网口指示灯光纤模块收发功率系统启动故障有个经典处理流程。上周同事遇到服务器卡在BIOS界面按这个步骤20分钟解决拔插内存条金手指氧化是常见原因最小化启动只留系统盘和单条内存查看IPMI/iDRAC远程管理口的硬件日志用U盘启动PE系统判断是否软件问题2. 网络故障的六脉神剑网络问题最让人头疼的是现象相似但病因各异。去年我们机房搬迁后有台服务器时通时断最后发现是网线被机柜压成了斑马纹。分享几个必杀技物理层排查要像法医网线测试仪检查八芯通断光功率计测光纤衰减值多模不宜超过3dB观察交换机端口CRC错误计数千兆网卡强制百兆模式测试排除电磁干扰协议层诊断三板斧# 第一式连通性测试 mtr -n --tcp -P 3306 10.0.0.2 # 数据库端口路径追踪 # 第二式传输质量 iperf3 -c 10.0.0.2 -t 30 -w 256K # 带宽与窗口测试 # 第三式协议分析 tcpdump -i eth0 -w /tmp/problem.pcap port 80 # 抓包取证遇到SSH连不上别急着重启先试这几个后门通过IPMI的KVM控制台直连本地console线接入思科设备用RJ45转DB9单用户模式修改sshd_config3. 性能问题的福尔摩斯分析法上个月MySQL突然变慢我用下面这套方法定位到是某业务批量查询没走索引资源瓶颈四象限定位法CPU瓶颈vmstat 1看r列就绪队列# 找到CPU杀手 perf top -g -p $(pgrep -d, nginx)内存不足watch -n 1 free -h观察buff/cacheIO等待iostat -x 1看%util和await网络拥堵sar -n DEV 1看rxkB/s是否饱和延迟分布分析技巧# 统计API响应时间分布单位ms histogram() { awk {print $NF} access.log | sort -n | awk { bucketint($1/50)*50; count[bucket] } END { for(b in count) print b,count[b] } }遇到系统卡顿但资源没用满可能是透明大页碎片化建议关闭THPNUMA内存分配不均numactl调整文件描述符耗尽lsof -p PID查泄漏4. 安全事件的应急响应流程去年某次挖矿病毒入侵让我总结出黄金一小时原则入侵检测三板斧# 异常进程筛查 ps -eo pid,ppid,cmd,%mem,%cpu --sort-%cpu | head -20 # 隐藏连接检测 ss -antp | awk $1!~/(LISTEN|ESTAB)/{print} # 文件指纹突变监控 find /usr/bin -type f -mtime -1 -exec ls -lh {} \;勒索软件应急步骤立即拔网线物理隔离最可靠拍摄现场systemctl list-units --staterunning内存取证LiME或Volatility工具包溯源分析journalctl -u sshd --since 2 hours ago日志分析神技# 爆破攻击特征提取 awk $6~Failed{print $NF} /var/log/auth.log | sort | uniq -c | sort -nr | head -20 # webshell检测 grep -RPn (eval\(|base64_decode\() /var/www5. 高可用架构的故障转移策略有次主库宕机因为VIP漂移配置错误导致30分钟业务中断。现在我们的切换checklist包含数据库主从切换七步法从库执行SHOW SLAVE STATUS\G确认同步位点主库设置read_onlyON防止脑裂从库STOP SLAVE; RESET SLAVE ALL新主库CHANGE MASTER TO指向其他从库应用层修改连接字符串配合配置中心DNS记录TTL调为60秒阿里云API修改原主库修复后作为新从库加入负载均衡器故障预案健康检查配置interval5s fall2 rise1静态备用节点nginx的backup参数多AZ部署时设置cross-zonetrue灰度发布时权重调整步长不超过10%6. 存储故障的经典处理方案磁盘故障就像定时炸弹我经手过最棘手的案例是RAID5双盘失效。现在遵循这些原则RAID运维铁律RAID5不超过8块盘重建时间MTBF热备盘容量需大于等于数据盘每周检查/proc/mdstat同步进度重建时禁用write-back缓存文件系统修复口诀ext4用fsck -y /dev/sdb1xfs用xfs_repair -L慎用-L选项NTFS用chkdsk /f /rZFS用zpool scrub tank数据恢复四不原则不直接在原盘操作先dd全盘备份不写入故障文件系统不信任单份备份验证备份可恢复性不跳过SMART检测badblocks会加速死亡7. 虚拟化环境的特有故障OpenStack集群曾出现虚拟机大规模宕机最后定位是Ceph集群osd_no_down_out设置不当。这类问题要关注Hypervisor诊断要点# KVM虚拟机状态检测 virsh list --all | awk $3!running{print $2} # ESXi主机健康检查 esxcli hardware memory get | grep ECC存储性能优化参数# qemu-kvm磁盘参数 disk_cachewriteback,discardunmap,iothreads # NFS客户端配置 vers4.1,noatime,nodiratime,rsize65536,wsize65536常见坑位预警虚拟机时钟漂移配置NTPQEMU agentvCPU过载不要超过物理核数的1.5倍内存气球balloon驱动未安装VirtIO网卡多队列未启用