服务器运维从零上手：先搞懂这四件事，比背命令有用

刚拿到一台服务器的人，多数会经历同一个阶段：SSH 连上去，ls 和 cd 都用得挺顺，可一旦网站变慢或者告警邮件进来，就完全不知道从哪下手。登上去敲 top，看到一堆数字在跳，CPU 使用率 30%、内存用了 60%，看着都不高，但服务就是卡。问题出在没建立一套排查顺序。运维经验里最值钱的部分不是记住多少命令，而是知道先看什么、后看什么、看到什么数值该紧张。下面这套顺序是我自己日常用的，从负载到磁盘再到网络，四步走完基本能定位大部分常见问题。

第一步：load average 不是 CPU 使用率，别被它骗了

uptime 输出的三个数字，分别是过去 1 分钟、5 分钟、15 分钟的平均负载。很多人以为它等于 CPU 占用百分比，其实它统计的是「正在运行 + 等待运行的进程数」。一台 4 核的机器，load 到 4 算跑满，到 8 就是明显过载了。

判断标准我一般这么定：单核 load 持续超过 1 就该看看，超过 2 倍核数基本可以确认有进程在堵。但要注意区分两种情况——CPU 密集型的 load 高，top 里 %us 会同步上去；如果是 IO 等待导致的 load 高，%us 反而不高，%wa 那一列会涨。后者说明瓶颈在磁盘，加 CPU 没用。

• load 高 + %us 高：查是谁在吃 CPU，top 按 P 排序
• load 高 + %wa 高：查磁盘，看 iostat -x 1 里 %util 是否接近 100

第二步：内存要看 available，不是 free

free -h 输出里，Linux 会把没用到的内存拿去做缓存（buff/cache），所以 free 那一列常年很小，这不代表内存不够。真正该盯的是 available 那一列，它表示「还能给新进程用的内存」。available 低于总内存的 10%，就该警惕了。

内存吃紧时，系统会启用 swap。机械盘上 swap 一开，服务响应会掉一个数量级；SSD 上稍好，但也不该长期依赖。查谁在吃内存：

• ps aux --sort=-%mem | head 看进程级占用
• smem -t -p 看按进程统计的实际物理内存（需要装 smem）

我见过不少情况是 MySQL 的 innodb_buffer_pool_size 设得过大，把物理内存吃干，结果系统层频繁 swap。这种时候调小缓冲池反而让整体更快，代价是部分查询要走磁盘。

第三步：磁盘 IO 到瓶颈时，加内存也没用

磁盘是最容易被忽略的一环。CPU 和内存都能靠 top 一眼看出，磁盘得专门看 iostat。关注两个指标：%util 表示磁盘有多忙，await 表示单次 IO 的平均等待毫秒数。

%util 长期 90% 以上，说明磁盘已经是瓶颈了。await 超过 20ms 在 SSD 上算偏高，机械盘上超过 50ms 就该查。这时候常见的原因有两类：一是日志写得太多太频繁，二是数据库的随机读写打满了 IOPS。

处理办法按成本从低到高：先看能不能把日志级别调低，或者把日志写到独立盘；再考虑给数据库加索引减少全表扫描；最后才是换 SSD 或者加盘做 RAID。换硬件最贵，但如果是 IOPS 硬扛不住，前面那些优化只能拖时间。

第四步：网络问题先分清楚是丢包还是延迟

服务「时快时慢」这种描述，十有八九是网络问题。别急着换机房，先用 ping 和 mtr 分清楚是丢包还是单纯延迟高。

mtr -r -c 100 目标IP 会给出每一跳的丢包率和延迟。如果丢包集中在某一跳且之后不再恢复，问题就在那一段；如果丢包从某一跳开始一直持续，可能是对端限制 ICMP，不代表真丢包。真正要看的丢包，通常发生在最后一跳。

延迟方面，同一机房内网通常 1ms 以内，跨省 20~40ms 算正常，跨境到香港 30~60ms，到美国西海岸 150~200ms 是常规水平。如果你用的是秀米云 新加坡大带宽服务器 VII 这类海外节点，50M 带宽下跑满时延迟会比空载略高，这是正常的队列延迟，不是线路问题。

排查完这四块，大部分告警都能落到具体原因上。剩下的就是习惯问题：把关键指标接进监控，别等出事了再登机器看。Zabbix、Prometheus 随便挑一个，先监控 load、available、磁盘 %util 和丢包率这四项，比装一堆花哨的面板有用。