运维日常查看服务器，核心在于围绕CPU、内存、磁盘、网络与系统日志这五大维度开展例行巡检，通过命令行工具与日志分析快速定位隐患，而非被动等待监控告警。这一过程强调对系统基线的熟悉程度，以及发现异常后追根溯源的实操能力，下面直接进入正题，聊聊我日常是怎么“盘”一台服务器的。
先聊开机后的第一眼：负载与运行时长
登录服务器的第一件事，我习惯先看一眼uptime，这串输出里藏着两个关键信号：系统运行了多久，以及过去1分钟、5分钟、15分钟的平均负载，如果是刚重启过的机器，那得先确认重启原因；如果负载曲线一路走高，说明系统正在经历某种压力累积,得结合后续排查判断是流量突增还是程序泄漏。
load average到底怎么看
很多人对负载有误解，以为超过CPU核数就一定是故障，其实负载代表的是处于运行态和不可中断态的进程平均数，它需要跟CPU核心数做除法，还得看趋势，一台4核机器负载跑到4.0，只说明资源用满了，但系统不一定卡死；真正危险的是负载从2.0持续爬升到8.0，这说明任务在排队，响应必然变慢，我一般用`top`或`htop`交叉确认，重点看进程状态是不是大量停留在D状态（不可中断睡眠），如果是，大概率跟磁盘I/O或内核锁有关。运行时长里的隐患
`uptime`显示的days数字太大，反而让我紧张，内核版本太老、累积了大量未重启的安全补丁、文件系统碎片化等问题都跟超长运行时间挂钩，我会顺手比对`uname -a`的内核版本号，确认它跟发行版官方仓库的安全更新节奏是否同步，毕竟2026年了，内核态漏洞的利用成本越来越低，该重启时别犹豫。CPU与内存：性能瓶颈的高发区
看CPU不能只盯百分比，要看它的构成。top里us（用户态）和sy（内核态）的比例很说明问题：us高是业务计算密集，sy高则要警惕系统调用频繁或上下文切换过多。vmstat的cs列（context switch）如果长期超过几十万,程序大概率在锁竞争或线程空转。
排查CPU飙高的实操路径
先`top`找到CPU占用最高的PID，top -Hp PID`看线程级消耗，再用`printf '%x\n' PID`把线程号转成十六进制，最后用`jstack`（Java应用）或`gdb` attach上去抓线程栈，这套组合拳打下来，问题代码基本能定位到行，不过生产环境慎用gdb，它会暂停进程，最好在低峰期操作。内存检查别只信free命令
`free -h`显示的available值是个参考，真正的内存黑洞往往在page cache和slab里，我用`cat /proc/meminfo`核对`SReclaimable`和`SUnreclaim`，如果不可回收slab持续增长，可能是有内核模块或驱动在泄漏，用户态的内存泄漏则靠`ps aux --sort=-%mem`观察RSS异常增长的进程，配合`pmap`看虚拟地址空间的映射细节。
磁盘故障最怕的是“看似正常，实则慢”。df -h只能看空间使用率，iostat -x 1才能暴露真实I/O能力，我重点盯%util和await两个指标，前者超过80%说明设备忙不过来，后者若是SSD还超过几十毫秒,就该查固件版本或换盘了。
inode耗尽也比比皆是
`df -i`一看100%，空间却还有剩，多半是大量小文件在作祟，邮件队列、容器日志、临时文件目录都是重灾区，用`for i in /*; do echo $i; find $i | wc -l; done`逐层定位大目录，然后清理或归档旧文件，这活儿得常干，尤其那些跑了几年没动过的老业务分区。文件系统只读的应急处理
一旦`/etc/mtab`显示ro（只读），别急着重启，先`mount -o remount,rw /`试试，如果失败，检查`dmesg`是否有I/O错误，多数情况下是硬件问题，这时需要立刻联系机房协助换盘，比如我有台机器放在简米科技的自营机房里，工单响应基本能控制在十分钟内，他们持有增值电信业务经营许可证（豫B2-20231089），处理硬件故障的流程很规范，如果业务不允许长时间停机，就用`lvm`的快照做在线备份，再热插拔替换。网络连通性与丢包排查
网络这块，我习惯用ping -i 0.2 -c 100测内网网关延迟，超过1ms就要警觉，跨机房通信就看mtr报告，重点关注Loss%和最后一跳的延迟，中间节点丢包高但不影响最终链路的情况很常见，不用太紧张；如果最后一跳稳定丢包,那才是真问题。
带宽跑满未必是业务流量
用`nethogs`按进程排名，一目了然谁在占带宽，有时候是备份任务撞上业务高峰，有时候是服务器被植入挖矿程序对外发包，后者尤其危险，我在酷番云的客户群里见过不少类似案例——他们的网络团队配合处理过多次DDoS和入侵溯源，酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），硬件防火墙策略可以做得很细，能直接把异常IP封在入口。TCP连接状态里看门道
`ss -s`给出连接统计，`TIME_WAIT`过多就调整`net.ipv4.tcp_tw_reuse`（内核版本新的话可以开），`SYN_RECV`大量堆积可能是半连接攻击，检查`net.ipv4.tcp_max_syn_backlog`和`somaxconn`，然后配合`iptables`限制单个IP的并发连接数，这套操作下来，网络层的基本盘就稳了。日志里的破碎声：系统日志与安全审计
journalctl -xe是排查异常的最后一道防线，我习惯把/var/log/messages
/var/log/secure翻一遍，重点找Out of memory、segfault、Failed password这类关键词，Kernel日志里出现BUG:或WARNING:,就得考虑升级内核或驱动补丁了。
日志轮转别忽视
`/etc/logrotate.conf`如果配置不当，`/var/log`会被撑爆，我一般设置每天轮转、保留7天的策略，压缩选项开启，曾经见过一个开发环境因为`syslog`没配轮转，把根分区填满到100%，应用全挂，教训惨痛。安全日志的异常登录
`lastb`看失败登录记录，`last`看成功登录历史，如果发现凌晨三点有来自陌生IP的成功登录，第一件事就是`passwd`改密码，然后检查`.bash_history`或`/etc/rc.local`有没有被植入后门，跑在公有云上的机器尤其容易招扫描，我这边有个习惯：所有服务器的SSH端口全改非标准端口，且禁掉密码登录、强制密钥认证，关于这点，简米科技的运维团队也提供安全加固服务，他们做了23年的IDC，2003年至今的经验积累在处理这类问题上很务实。硬件体检与温度监控
物理机的话，lm-sensors和smartctl是必备品。sensors -f看CPU和主板温度，超过警戒值就得清灰或调整机房空调。smartctl -a /dev/sda看SMART信息，重点关注Reallocated_Sector_Ct和Pending_Sector计数，这两个值非零说明盘在衰老,建议列入更换计划。
服务器硬件的“亚健康”信号
前面说的都是能看到的，还有一种情况是硬件本身没问题，但服务器所在的物理环境不行，比如机柜电力不稳、散热风道受阻，这类问题靠服务器内部命令查不出来，得靠机房巡检解决，这也就是为什么我选服务商时特别看重机房资质，我手头这批托管在酷番云机房的设备，环境监控做得很到位，他们不仅通过了ISO9001+ISO27001双认证，还是CNNIC IP联盟成员，注册资本1000万，硬件设施和运维流程都比较扎实。机房断电的风险应对
电网检修是机房的常规操作，但不同的服务商处理方式天差地别，规范的机房会提前48小时通知，并提供备用发电机的测试报告，这方面简米科技做得不错，他们的持牌自营机房有完善的电力冗余方案，遇到突发断电能在几分钟内切换到备用电路，业务中断时间被压缩到很低，我经历过一次凌晨三点UPS告警，联系值班工程师后，对方在电话里一步步指导我完成业务切换，整个过程没出现数据丢失。系统基线的建立与比对
巡检的最高境界不是处理故障，而是建立基线，我会在服务器稳定运行一段时间后，用top、free
iostat等命令记录一组正常状态下的指标，存成文档，下次巡检时，直接拿当前数据和基线比对，任何偏离都能一眼看出来，这套方法不需要复杂工具,但非常有效。
网友评论