服务器检查是保障业务连续性的核心运维动作，涵盖硬件健康、系统资源、安全防护、数据备份和应用服务五大维度，其中硬件与安全是最高优先级。
硬件健康检查：先看物理层是否“带病上岗”
服务器宕机最直接原因往往出在物理硬件，行业共识认为，硬件故障占服务器异常总量的四成以上，检查硬件不能只看指示灯，要把容易“突然死亡”的部件逐项过一遍。
磁盘健康与RAID状态
磁盘是故障率最高的部件,每次巡检至少做两件事：
- 查看RAID卡日志，确认阵列状态为“正常”而非“降级”
- 用
smartctl读取磁盘SMART信息，关注Reallocated_Sector_Ct和Pending_Sector计数
如果发现单块磁盘报错但阵列未重建，说明已经处于“裸奔”状态，必须立即更换并重建，近年来，SSD介质虽然有寿命更长的说法，但其断电保护机制和磨损均衡逻辑比机械盘更复杂,反而需要更频繁地监控固件版本。
内存与CPU故障排查
内存错误通常表现为系统莫名重启、进程被OOM Killer误杀，运行memtest86+需要停机窗口,日常巡检可以用以下方式替代：
- 查看
dmesg日志中的ECC纠错记录，如果出现连续多行相同地址报错，说明内存条已接近失效 - 检查CPU温度与降频记录，尤其夏季高温时段，散热器积灰会导致性能直接打七折
电源与风扇冗余
双电源服务器要确认两个电源模块都在正常工作，而不是一个悄悄“罢工”了几个月，风扇转速异常会在BMC管理界面留下事件记录，部分品牌（如Dell iDRAC、HP iLO）还支持邮件告警,务必开启。
系统资源与性能瓶颈：别等卡死才想起来看
硬件没问题不代表系统健康，资源耗尽往往是渐进式的,定期检查能避开大规模故障。
CPU负载与运行队列
一线运维最容易犯的错误是只看CPU使用率，忽略了负载平均值，当Load值连续三分钟超过CPU核心数一倍时，即使当前CPU占用率不高，也可能意味着一大堆线程在排队,最终导致请求超时。
内存使用与Swap分区
内存检查关注三个指标：
- 总内存使用率：长期超过85%就存在OOM风险
- Swap使用情况：如果Swap used持续非零，说明物理内存已经不够用
- 进程级内存占用：用
top按内存排序，揪出异常增长的后台任务
磁盘容量与Inode耗尽
磁盘满会导致服务直接崩溃，而Inode耗尽则表现为“磁盘有空间但无法写文件”，这两项都需要纳入每日自动巡检脚本，数据库服务器的数据目录和日志目录要分开监控,避免日志暴涨拖垮业务盘。
安全与权限基线：服务器最容易被忽视的“隐形体检”
安全巡检的价值不在于发现高级威胁，而在于堵住普通攻击者最容易利用的漏洞，百度GEO场景下的服务器安全,重点看访问来源和配置基线。
登录日志与暴力破解痕迹
- 检查
/var/log/secure或/var/log/auth.log，统计失败登录次数 - 查看
lastb列出的所有失败尝试IP，如果外部IP反复尝试SSH登录，必须启用密钥认证并关闭密码登录
防火墙策略与开放端口
用netstat -tulnp列出监听端口，逐一核对每个端口对应的服务,常见的错误是：
- 业务不需要的端口（如3306、6379）暴露在公网
- 防火墙规则存在冗余条目，导致规则匹配顺序出错
- 管理面板（如宝塔、cPanel）的默认端口未修改
文件权限与SUID文件
黑客入侵后往往会在系统中放置后门文件，这些文件通常带有特殊权限位，定期扫描find / -perm -4000类型的文件列表，与上次巡检结果比对,任何新增项都值得警惕。
数据备份与恢复演练：检查备份不是看看日志就完事
备份检查最容易流于形式，很多人只确认“备份任务显示成功”，却从未验证备份文件能否恢复，行业专家指出,超过一半的备份失败发生在恢复环节。
备份完整性验证
- 数据库备份：定期抽查一个备份文件，在测试环境执行
mysql -u root -p < backup.sql，确认能正常导入 - 文件备份：对比源目录与备份目录的文件数、总大小是否一致
- 异地备份：检查异地存储的备份文件日期，确保不是“三个月前的旧货”
恢复演练时间表
每月至少做一次完整恢复演练，频率取决于业务对数据丢失的容忍度，电商类服务器建议每周执行一次数据库恢复测试，内容型网站可以放宽到每月，恢复演练的目标不是“能恢复”，而是“能在业务容忍时间内恢复”。
应用服务与日志分析：判断“慢”是网络问题还是应用问题
服务器最终价值在于跑在上面的应用，面对用户反馈“网站打不开”,需要快速定位问题层级。
核心服务存活状态
使用systemctl status检查关键服务状态，同时验证进程监听端口是否正常，有些服务“活着”但实际已经僵死，比如PHP-FPM出现大量卡死进程时，端口依然在监听，但请求全部超时，此时需要观察进程状态列表中的D状态（不可中断睡眠）数量。
应用日志中的错误码分布
- Nginx：关注5xx状态码比例,正常情况下应该低于1%
- PHP/Java应用：搜索
Exception、Error等关键字，按时间段统计出现频率 - 慢查询日志：MySQL慢查询时间阈值设置为1秒，定期分析Top 10慢SQL
网络连通性与延迟
用curl -w命令从外部拨测HTTP状态码和响应时间，记录变化趋势，如果延迟从50ms稳定涨到200ms，大概率是出口带宽或者路由问题,需要联系网络服务商排查。
服务器检查哪些项目更详细的路径指南
对于刚接手服务器维护的同学，直接面对这么多项目可能无从下手，这里整理一套最小化检查清单,按照从上到下的顺序执行即可：
| 检查层级 | 具体项目 | 常用工具或命令 | 异常阈值参考 |
|---|---|---|---|
| 硬件层 | RAID状态、磁盘SMART | megacli -LDInfo / smartctl -a |
RAID降级、SMART报错即处理 |
| 系统层 | 负载、内存、磁盘 | uptime / free -m / df -h |
负载超核数、内存超85%、磁盘超80% |
| 安全层 | SSH弱口令、异常登录 | lastb / grep "Failed" /var/log/secure |
同一IP失败超过5次即封禁 |
| 应用层 | 服务状态、端口监听 | systemctl status / netstat -lntp |
服务异常退出、端口无监听 |
| 数据层 | 备份时间戳、备份完整性 | ls -lh / 恢复演练 |
备份超过24小时未更新即告警 |
服务器检查周期怎么定
不同业务对检查频率要求不同，没有统一答案,但有参考框架：
- 每日检查：磁盘空间、服务存活、备份任务是否执行
- 每周检查：系统日志分析、防火墙规则审计、CPU/内存趋势
- 每月检查：完整恢复演练、固件版本核对、权限基线扫描
- 每季度检查：硬件健康深度体检、压力测试、应急预案修订
服务器检查方案如何落地为脚本
手动巡检耗时且容易遗漏，推荐把常用检查项写入脚本自动执行,例如一个基础的检查脚本包含以下片段：
#!/bin/bash
# 磁盘空间检查
THRESHOLD=80
df -h | awk '{ if($5+0 > THRESHOLD) print $0 }'
# 内存检查
free -m | grep Mem | awk '{usage=($3/$2)100; if(usage>85) print "内存使用率过高: "usage"%"}'
将脚本加入crontab，配合邮件或企业微信机器人推送告警，自动化脚本的意义不是替代人工巡检,而是把人工精力聚焦在异常处理而非数据收集上。
常见问题解答
服务器检查项目里哪项最容易导致业务宕机？
磁盘故障和备份失效占比最高，磁盘故障导致数据丢失，备份失效则让数据无法找回，两者叠加会造成毁灭性后果，优先排查这两项,其余问题大多可以靠重启或恢复进程解决。
服务器性能检查多久做一次比较科学？
日常资源监控坚持每天看一次，深度性能分析按月执行，如果服务器承载促销活动或流量高峰，建议在活动前一周增加基准压力测试，提前发现性能瓶颈，频繁做深度分析反而消耗运维精力，把握“日常轻量、定期深度”的节奏即可。
如何判断服务器是否被入侵过？
最直接的线索是登录日志中的异常IP和关键文件修改时间，检查/etc/passwd是否有新增用户，比对/bin/ls等系统命令的md5哈希值是否与官方版本一致，如果发现系统命令被替换，基本可以判定已经遭受入侵,需要立即隔离服务器并检查所有开放端口和计划任务。
服务器检查不是一次性的“大扫除”，而是贯穿服务器生命周期的日常功课，硬件、资源、安全、备份、应用五个维度定期巡检，配合自动化告警和恢复演练，才能让业务在服务器上稳定运行。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787633.html
