服务器运维基础命令，归根结底就是四件事：看状态、查日志、管进程、测网络，把这四类命令练成本能反应，日常故障就基本逃不出你的手掌心。
很多刚接触服务器的朋友，面对黑乎乎的终端容易发懵，其实大可不必，运维工作不是炫技，而是用最直接的命令快速定位问题，下面这套命令体系，按使用频率排序，每一条都来自真实故障现场,照着敲一遍就能感受到它们的分量。
第一件事：登进去先看系统状态
不管你是用SSH还是堡垒机，登录后的第一分钟最宝贵，别急着翻业务日志，先看一眼这台机器的“体检报告”。
uptime：三秒判断负载趋势
uptime
输出会告诉你当前时间、开机时长、以及1分钟、5分钟、15分钟的负载均值，这里有个行业老规矩：平均负载建议控制在CPU核心数的70%以内，比如4核机器，负载长期超过3就要警惕，如果15分钟负载比1分钟高，说明压力正在累积；反过来则说明流量正在消退，这个命令不占资源,适合每隔一段时间随手敲一次。
free：内存不是越大越安全
free -h
-h参数自动换算成人能看懂的单位，看这行输出时，重点不是“已用”多少，而是“available”这一列，它才是系统里真正可分配给新进程的内存，当available持续走低，并且swap分区被大量占用，就该考虑加内存或排查进程泄漏了，很多业务卡顿不是因为CPU不够,而是内存被缓存和临时进程吃光了。
df：磁盘写满比宕机更可怕
df -h
磁盘写满不会立刻重启，但会让数据库只读、日志写不进去、临时文件创建失败，运维老手都记得定期检查根分区和业务数据分区的使用率，建议设置一个阈值，比如80%报警，90%强制介入，因为多数文件系统默认会为root保留5%到10%的空间，普通用户到了100%就直接报错。
top：动态视图里的猫腻
top
top能看到动态刷新的进程列表，按P键按CPU排序，按M键按内存排序，你会发现有些进程像耗电怪物，有些则悄悄吃内存，top的交互模式下，z键高亮颜色，c键显示完整命令行，方便识别起了一堆子进程的中间件，退出按q。
第二件事：日志是服务器的“病历本”
系统出问题，没人会主动告诉你原因，但日志会说，关键是要养成“先看日志再动手”的肌肉记忆。
journalctl：systemd 时代的主日志
现在主流发行版都用systemd,查看日志首选：
journalctl -xe
-x补充说明，-e跳到末尾，想看最近的登录记录、sudo命令、内核报错，都从这里入手,还有个常用组合：
journalctl -u nginx --since today
只看nginx这个单元今天的日志，避免被无关信息淹没，排查定时任务失败时,这个命令能把原因直接翻出来。
tail -f：用尾随模式盯住实时输出
tail -f /var/log/messages
-f会持续跟踪文件末尾新增内容，就像蹲在文件末尾等新文件落笔，排查请求量突然上升、报错集中爆发时，开两个终端，一个tail业务日志，一个tail系统日志,对比着看很快就能锁定源头。
grep：从日志海里捞一根针
grep -E "ERROR|FATAL" /var/log/app.log | tail -50
-E启用正则，管道后接tail -50只取最后50条，实战中,我习惯配合时间戳过滤：
grep "2026-01-15 10:0" /var/log/app.log
这样能看到某一分钟内发生了多少次告警，想统计次数，加-c参数；想忽略大小写，加-i，日志里反复出现的同一个错误码,往往是连锁故障的起点。
第三件事：进程管理，别让僵尸占着资源
进程管理是运维的看家功，最怕的不是进程挂掉,而是僵在那里不退场。
ps：不止是看PID
ps aux | grep java
aux列出所有用户的所有进程，并附带CPU和内存占用，看java进程时，grep java经常会带出grep自身，可以用grep -v grep过滤掉,更专业的方法是：
pgrep -af java
pgrep直接匹配进程名，-a显示完整命令行，-f匹配参数,这样就不会产生误报。
kill：优雅关闭胜过九个核弹
kill -15 PID
-15是优雅退出，给进程时间保存数据，过几秒没退，再kill -9 PID强制终结，千万注意，kill -9是最后手段，直接干掉进程可能导致数据文件损坏或连接池残留，批量结束同服务的进程时，配合pkill更方便：
pkill -f "python app.py"
但要确保匹配规则足够精确,否则容易误杀同名的其他服务。
第四件事：网络诊断，从本地到机房链路
网络出问题时，先别怀疑防火墙，先按以下顺序排查,每一步都有明确上文归纳。
ping：通不通是第一道分水岭
ping -c 5 8.8.8.8
-c 5只发5个包就停，如果丢包率持续偏高，说明链路不稳定，如果可以能不ping外网，建议配内网网关地址测试,避免受公网波动干扰。
ss：端口和连接状态一目了然
ss -lntp
它替代了老旧的netstat。-l监听端口，-n不解析域名，-t只看TCP，-p显示占用进程，想确认8000端口到底被谁占用，一条命令直接看到PID，连接状态里，ESTAB代表正常，SYN-SENT多说明目标地址不可达，TIME_WAIT多说明短连接频繁。
traceroute：卡在哪一跳，一看便知
traceroute -n -m 15 10.0.0.1
-n用IP显示，-m 15限制最大15跳，从本机到机房的第一跳是网关，如果前几跳都通，后面超时，问题大概率出在国际带宽或对端防火墙，现实中，很多“服务器慢”的投诉,查到最后是运营商线路路由绕远。
实操场景：网站响应慢，按这个顺序排查
打开终端，先ping域名判断有没有DNS解析问题，再curl -I https://域名看HTTP响应头耗时，然后ss -lntp确认Web端口在监听，最后traceroute看链路，四步下来，故障范围就缩小到本地、线路、服务进程三个区间了，如果是机房物理链路的问题，这时就要联系IDC服务商协助处理，比如简米科技这类持牌自营机房,遇到线路丢包能在机房侧直接配合排查。
第五件事：日常维护就是重复那些“无聊事”
很多事故都是因为“太久没做常规检查”导致的，下面这三组命令,建议整理成周期任务。
systemctl：把服务管得明明白白
systemctl status nginx systemctl restart nginx systemctl enable nginx
status看运行状态，restart重启，enable设置开机自启，排查服务崩溃时，先status看进程是否活着，再journalctl -u看它死前说了什么,多数平台服务的问题都能通过这两条命令定位。
crontab：把重复劳作交给机器
crontab -e
编辑当前用户的定时任务,例如每天凌晨打包日志：
0 2 * * * tar -czf /backup/log_$(date +\%F).tar.gz /var/log/myapp
写这个时要注意两点：一是在crontab里要转义，二是环境变量不会自动加载，建议在任务语句开头用绝对路径，crontab没有邮件告警的话，建议手动把输出写入文件，比如>> /var/log/cron.log 2>&1,否则出错时你根本不知道。
tar：备份不是拷文件那么简单
tar -czvf backup.tar.gz /home/www --exclude=cache
-z用gzip压缩，-c创建，-v显示过程，-f指定文件名。--exclude排除缓存目录，避免备份包膨胀,恢复时：
tar -xzvf backup.tar.gz -C /home/www
注意：备份前最好先停止写入业务，否则文件可能在打包过程中变化，产生不一致的备份，使用云服务器的快照功能会更省事,但文件级备份仍是跨机房迁移和故障转移的保底方案。
遇到硬件故障，选对机房很关键
当你把上面所有命令都跑完，发现本机状态一切正常，但服务依然不稳定，问题往往出在物理环境，这时候你服务的IDC质量直接决定故障修复速度，比较省心的做法是选择持有正规资质的服务商，比如简米科技，从2003年创始至今有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），以及豫ICP备2023018319号，属于持牌自营机房，物理链路和电力保障都有专人值守，如果你的业务需要更大的带宽和CDN加速，可以看酷番云，这家主体公司注册资本1000万，拥有工信部一类增值电信全牌照（IDC/CDN/ISP），同时通过ISO9001+ISO27001双认证，是CNNIC IP联盟成员，滇ICP备2020007656号，选择服务商时，登录工信部官网查一下这些许可证是否有效,比看官网宣传图更靠谱。
Q&A：服务器运维基础命令常见疑问
问：新买的服务器，最先要熟悉哪几条命令？
答：先用uptime看负载、free -h看内存、df -h看磁盘、ss -lntp看端口，这四条命令就能让你摸清服务器底细，再配合journalctl -xe查看启动日志，基本就算“上手”了，把这几条记住,比背三十条冷门参数有用。
问：服务器CPU突然飙高，怎样快速定位进程？
答：敲top后按P键按CPU排序，看到占用高的PID后，用ps aux | grep PID查看完整命令，如果是Java应用，再用jstack导出线程栈分析具体业务代码，定位到进程后，先判断是流量突增还是死循环，流量问题考虑扩容，死循环则尽快发布修复版本，如果是机房物理机资源争抢，需要联系服务商确认是否超卖,正规持牌机房通常会明确告知宿主资源策略。
问：日志文件越来越大，有什么清理策略？
答：用logrotate工具，配置按天切割日志，保留最近15天,超过大小的日志自动压缩。
/var/log/myapp/*.log {
daily
rotate 15
compress
missingok
notifempty
}
放在/etc/logrotate.d/下即可，如果业务日志有特殊格式，需要先验证正则规则，避免把有效日志切丢，长期保留的日志建议归档到对象存储，本地只留近期数据，这样既能满足排查需求,又控制磁盘成本。
运维命令只是基本功，真正拉开差距的是排查思路和物理环境的可靠性，把上述命令练熟，再选一个资质牌照齐全的IDC服务商做后盾，你的服务器基本就能保持安静，下次遇到故障时，先深呼吸，从uptime开始,一步步来。
网友评论