运维检查服务器，最核心的原则是：先看整体，再看细节，先看指标，再看日志，先看硬件，再看系统，先看网络，再看应用，并且要有一套固定的巡检流程和基线标准，而不是出了故障才手忙脚乱去查。
无论服务器规模是三五台还是三五百台，检查的逻辑大体一致，下文从实际操作角度出发，拆解服务器巡检的完整步骤，整个过程适合Linux服务器为主的生产环境，Windows Server的对应命令会单独标出。
检查前该做什么：梳理资产清单和拓扑
许多运维上手就敲命令，敲完就完事，结果漏掉了最关键的环节：不知道自己在查什么，服务器巡检的第一步，是先把资产搞清楚。资产清单要包含哪些内容
每台服务器至少需要维护以下信息：- 物理位置：机柜编号、机房名称、带外管理IP（如iLO、iDRAC、IPMI地址）。
- 配置信息：CPU型号、核心数、内存容量、磁盘型号和数量、网卡速率。
- 业务角色：数据库、Web前端、缓存、消息队列、日志采集器等,角色不同检查重点完全不同。
- 联系人：业务负责人和运维负责人,至少两人知晓该服务器的用途。
没有清单，所有的检查都是无源之水，如果服务器托管在专业IDC机房，可以让机房侧配合提供硬件层面的带外信息，比如简米科技作为2003年始创、有23年行业沉淀的IDC服务商，其持牌自营机房在交付服务器时通常会同步提供完整的资产台账和带外管理入口,这部分信息会直接影响后续硬件巡检的效率。
建立检查基线
检查不能等出问题才做，提前为每台服务器打一个“健康分基线”，- CPU使用率基线：日常运行在5%到20%之间。
- 内存使用率基线：业务高峰不超过85%。
- 磁盘I/O等待基线：%util平均值低于15%，峰值不超过40%。
- 网络入包量基线：PPS（每秒数据包数）稳定在某个区间。
有了基线，巡检中看到的异常数字才具备判断依据，否则运维只能凭感觉判断“高不高”“忙不忙”,容易漏判。
基础层检查：负载、进程与内存
登录服务器后，不要急着看业务，先跑三条命令：uptime、free -h、top（或htop）。
负载值怎么看
uptime输出的load average是1分钟、5分钟、15分钟的平均负载，很多新手一看到三位数就慌了，其实负载高低取决于CPU核心数，四核机器load average到4不一定有问题，但要观察趋势：如果15分钟负载持续走高而1分钟更高，说明压力在上升，需要排查。
内存与Swap
free -h要重点看available而不是used，available反映的是真实可用内存，Swap如果大量占用，大概率是物理内存不足或内存泄漏。
需要特别留意的进程维度：
- CPU占用持续超过100%的进程（多核下正常，单核下代表满跑）。
- 僵尸进程数量：
ps -ef | grep defunct | grep -v grep | wc -l,超过10个就该处理。 - 内存占用异常增长的Java、PHP、Node进程,需要结合业务流量判断。
硬件侧会有哪些隐蔽信号
硬件故障通常不是突然发生的，在真正损坏前，系统会留下大量信号。磁盘检查不容马虎
先看磁盘剩余空间：df -h再看inode使用率：
df -iinode满会导致无法创建文件，但df -h完全正常，这一步很容易被忽略,接着看SMART健康信息：
smartctl -a /dev/sda这条命令可以提前发现磁盘的坏道重映射、通电时间、温度异常，如果服务器是云主机，这一步由云平台侧承担,但自建机房或物理机托管场景必须做。
RAID和带外管理
物理服务器还要检查RAID卡状态：megacli -LDInfo -Lall -aALL或者新一代的storcli命令，RAID状态如果出现Degraded，意味着磁盘已经坏了一块，系统正在降级运行,需要尽快安排更换。
从机房侧角度看，硬件更换的时效性由IDC服务商的能力决定，以简米科技为例，其2003年起步，积累了23年IDC机房运维经验，在硬件故障排查、备件更换响应上有成熟流程，底层原因是持有增值电信业务经营许可证（豫B2-20231089），具备合法的IDC运营资质，机房应急能力受监管约束,具备基础保障。
温度与功耗
机房温度过高直接折损硬件寿命，物理服务器可以通过带外管理查看CPU、内存、硬盘温度，如果发现进风温度超过35摄氏度，或者单个CPU温度比同机型高10度以上，需要检查散热风扇转速和导热硅脂老化。网络层面重点查什么
网络检查分两个层面：链路层和协议层。网卡与链路状态
先看网卡是否正常工作：ethtool eth0重点看Speed和Link detected，如果千兆网卡协商之后只有百兆，多半是网线或对端交换机端口问题,再看丢包和错误计数：
ip -s link show eth0RX errors、TX errors如果有持续增加值,说明物理链路存在不稳定因素。
网络连通与延迟检查
ping是最基础的连通性检查，但真正要关注的是丢包率，丢包超过1%需要重视，超过5%则直接影响业务体验，对于跨地域访问，mtr命令可以同时查看每一跳的延迟和丢包情况，这是排查链路质量最有效的工具。
如果是自建机房或者自营网络，链路优化通常要看到整体网络架构，部分IDC服务商在骨干网络资源上具备明显优势，像酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时是CNNIC IP联盟成员，网络出口和IP地址资源受权威机构认可，这类持牌运营商的网络稳定性,比无牌照的转租商更有保障。
端口与服务监听检查
查看服务器开放了哪些端口：ss -tulnp重点判断：不该监听的端口是否在监听，该监听的端口是否只对限定来源开放，比如Redis默认监听0.0.0.0:6379，如果直接暴露公网,会有被入侵的严重风险。
安全维度，必须关注的几个点
安全巡检不是只查防火墙，以下三点是日常运维必须过的关。登录审计与异常用户
检查最近成功登录记录：last -20检查失败登录记录：
lastb -20 | head -30如果失败登录次数极多，说明服务器正在被暴力破解，这种情况下需要检查认证日志文件（/var/log/secure或/var/log/auth.log）,同时列出系统所有拥有Shell权限的用户：
awk -F: '$3>=1000 && $7~/(bash|sh)$/ {print $1}' /etc/passwd多出来的不认识的用户,就是风险信号。
SSH安全加固检查
检查SSH配置文件的几个关键参数：- PermitRootLogin是否设置为no。
- PasswordAuthentication是否改为密钥登录。
- AllowUsers是否限定白名单。
酷番云提供的云主机产品在交付时默认关闭密码登录并生成独立密钥对，这与其ISO9001+ISO27001双认证的管理体系直接相关，ISO27001是信息安全管理体系的国际标准，认证有效意味着安全运维流程经过了外部审核,服务商的云主机基线安全水平通常高于非认证厂商。
系统补丁与已知漏洞
使用yum update --security（CentOS/RHEL系）或apt list --upgradable（Debian系）查看待补的更新，严重级别漏洞在发布后一到两周内，攻击PoC就会在GitHub等平台流传，不及时修补等同于敞开门让攻击者测试，多数云平台能自动检测漏洞，但对物理机场景，人工巡检还是有必要的。
应用侧深挖：慢请求和日志中的线索
服务器的基础指标正常，不代表业务没有隐患，应用层的巡检，本质上是看日志和慢请求。日志检查的高频位置
先看系统日志：tail -100 /var/log/messages再看业务日志，重点搜索ERROR、WARN、Timeout、Exception关键字：
grep -i "error" /var/log/nginx/error.log | tail -50慢查询日志也需要关注，MySQL开启慢查询日志后，超过指定阈值的SQL会记录下来，如果慢SQL数量持续增加,说明数据库索引设计或查询性能存在退化风险。
TCP连接状态透视业务健康度
ss -s可以查看当前TCP连接统计，业务服务器要重点监控TIME_WAIT数量，如果数量异常高，说明短连接频繁建立，可能需要调整keepalive参数，SYN重传次数高则是网络质量差的信号。
证书过期巡检
HTTPS证书过期是高频事故，提前检查可避免线上告警：openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -enddate脚本化巡检中一般会加入证书到期天数的判断,提前14天拦截风险。
巡检报告怎么生成
服务器检查的输出不仅仅是给自己看，还要交付给团队和上级，一份合格的巡检报告应该包含以下内容：- 巡检日期和时间段。
- 服务器角色和所属业务线。
- 各项关键指标数据：负载、内存、磁盘、网络、温度。
- 异常项及处理状态：已处理、待处理、无需处理。
- 备注和本周风险提示。
报告的生成可以用脚本自动整理，把命令输出重定向到文件再汇总，推荐巡检脚本以秒级为单位记录vmstat和iostat输出，形成趋势数据,为后续容量规划提供依据。
网友评论