从登录、进程管理、日志查询到磁盘监控，掌握核心命令就能解决绝大多数日常问题。
很多新手面对服务器时，第一反应是去搜“运维命令大全”，但真正到了生产环境，你会发现命令本身并不难，难的是知道什么时候该用哪一条，这篇文章不堆砌命令列表，而是按照真实运营场景来拆解,让你看完就能上手。
服务器日常运维命令有哪些：从登录到状态检查
运营服务器的第一步，永远是安全地连上去，SSH 是唯一推荐的远程登录方式，不要使用明文协议，登录后，第一件事不是东点西点,而是快速判断系统当前是否健康。
登录与基础信息获取
拿到一台服务器，先用 uptime 看运行时长和负载，输出里的 load average 三个值分别代表 1 分钟、5 分钟、15 分钟的平均负载，如果持续高于 CPU 核心数，说明系统有压力,需要进一步排查。
接着用 uname -a 查看内核版本，用 cat /etc/os-release 确认发行版名称和版本号，这两条命令决定了后续安装软件包的方式CentOS 用 yum，Ubuntu 用 apt,别搞混。
如果服务器有多个公网 IP，用 ip addr 查看网卡绑定情况，用 ss -tlnp 查看当前监听的端口，这两条命令结合起来，能快速确认服务是否只监听在内网、端口是否被正确占用。
系统负载与运行时长检查
负载高并不总是坏事，要看是什么进程引起的，用 top 进入实时监控界面，按 P 键按 CPU 占用排序，按 M 键按内存占用排序，注意观察 load average 的同时，要看 wa 列，也就是 I/O 等待占比，如果这个值持续偏高,大概率是磁盘读写卡住了瓶颈。
对于生产环境，我习惯用 vmstat 1 5 打一个 5 秒的采样快照，看 r 列（运行队列）和 si/so（交换分区读写）。si/so 长期不为 0，说明内存严重不足，正在频繁使用 swap，这会显著拖慢数据库和 Java 应用的响应速度。
linux服务器常用运维命令进阶：日志、进程与磁盘
基础状态没问题，下一步就是看服务本身的运行状况,这部分是日常运维中操作频率最高的场景。
进程管理：启动、停止与异常处理
最常用的进程管理命令是 systemctl，systemctl status nginx 查看状态，systemctl restart nginx 重启服务，但如果你用的是裸机部署或容器外的独立进程，就得靠 ps 和 kill。
查找进程用 ps aux | grep java，但 grep 本身也会出现在结果里，更专业的做法是 pgrep -f java，只打印匹配进程的 PID，确认 PID 后，用 kill PID 发送 SIGTERM 信号做优雅退出，10 秒内没退，再用 kill -9 PID 强杀。
这里有个行业共识：不到万不得已不要用 kill -9，强制杀进程会跳过资源清理，可能导致端口未释放、文件锁残留，甚至数据库事务中断，先给进程一个缓冲期,是运维的基本修养。
查看日志：快速定位错误源头
日志是运维的眼睛，用 journalctl -u nginx --since "1 hour ago" 查看 systemd 管理的服务日志，用 tail -f /var/log/nginx/error.log 实时跟踪 Nginx 错误日志。
排查问题时，我建议先 grep "ERROR" app.log | tail -n 100，把最近 100 条错误拿出来，再结合时间戳和上下文逐条看，不要一上来就 cat 整个日志文件,几千行输出只会让你眼花缭乱。
对于日志量大的系统，先用 du -sh /var/log/ 看看哪个日志文件异常增长，单个日志超过 2GB 时，要么是流量确实大，要么是某个服务陷入死循环重复写错误，这时用 logrotate 配置按天轮转，保留最近 14 天的日志,能用极小的代价解决磁盘占满问题。
磁盘空间与 Inode 检查
磁盘满是最常见的故障原因之一，执行 df -h 查看分区使用率，重点看 和 /data 这类业务挂载点，使用率超过 80% 就该预警了，超过 90% 必须马上处理。
但有时候 df -h 显示还剩不少空间，应用却报“No space left on device”，这通常是 inode 耗尽了，用 df -i 查看 inode 总数和已用数，如果已用比例接近 100%，哪怕磁盘还有几十 GB 空闲，也写不进任何新文件，小文件过多的缓存目录、邮件队列、Docker 容器层是 inode 杀手，找到后用 find / -count -xdev -type f | sort -rn | head -20 定位文件数量最多的目录,再清理过期文件。
定位大文件用 du -sh / | sort -rh | head -10，一层层向下找，直到看到具体文件，删除大文件后，如果空间没有立刻释放，说明还有进程保持该文件的句柄，用 lsof | grep deleted 查出来并重启对应进程。
网络与安全运维：防范攻击要从命令做起
服务器暴露在公网上，安全运维是每天都要面对的功课，与其依赖图形面板，不如掌握几条关键的排查命令,做到心中有数。
连接状态与异常 IP 识别
用 ss -s 快速查看当前的 TCP 连接统计，timewait 数量异常高，说明存在大量短连接，可能被爬虫攻击或应用频繁建立连接，用 ss -tp 列出所有连接详情，注意观察 State 列，ESTAB 表示正常连接，SYN-RECV 大量堆积则可能是 SYN Flood 攻击。
找出与攻击 IP 相关的所有连接，用 ss -tp dst 192.0.2.1 筛选，更高效的做法是直接抓包，tcpdump -i eth0 host 192.0.2.1 and port 80 -c 20，看这台 IP 在做什么类型的数据请求，确认恶意后，立即用防火墙规则屏蔽它：iptables -A INPUT -s 192.0.2.1 -j DROP，或使用 firewalld 的 firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.0.2.1 drop'。
安全审计：谁登录过、执行过什么
服务器安全的关键在于可审计，用 last -n 20 查看最近 20 条登录记录，包括登录 IP、时间、终端类型，如果发现有陌生 IP 在凌晨登录成功，马上用 who 查看当前在线用户，并用
pkill -u 用户名 强制踢掉异常会话。
检查 history 命令记录，能还原当时的操作轨迹，但更严谨的做法是查看 /var/log/secure（CentOS）或 /var/log/auth.log（Ubuntu），用 grep "Failed password" /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -rn | head -10 统计暴力破解的来源 IP 次数，据统计，公网服务器每天会遭受数百次自动化密码尝试,这是常态。
常用安全加固命令汇总
- 修改默认 SSH 端口，并关闭 root 密码登录：
sed -i 's/#Port 22/Port 2222/' /etc/ssh/sshd_config，同时设置PermitRootLogin no。 - 开启防火墙并只放行业务端口：
systemctl enable firewalld && systemctl start firewalld,然后逐条添加端口规则。 - 安装 Fail2Ban 自动封禁多次失败的 IP：
yum install fail2ban后配置jail.local，恶意 IP 连续尝试 5 次即封禁 1 小时。 - 定期更新系统补丁：
yum update -y或apt upgrade -y,并重启服务使内核更新生效。
定时任务与自动化：让常看的命令替你打工
运营服务器最怕的是“每天机械式地点几下”,定时任务和脚本可以帮你把重复的操作固定下来。
用 crontab 做定时巡检
crontab -e 编辑当前用户的定时任务，下面是一条 5 分钟执行一次的负载巡检示例：
/5 /root/scripts/check_load.sh >> /var/log/check_load.log 2>&1可以这样写：
#!/bin/bash
load=$(uptime | awk -F'load average:' '{print $2}')
cores=$(nproc)
echo "$(date) load: $load cores: $cores"
如果负载持续超过核心数，自动触发告警，你也可以把 df -h、free -m、ss -s 的输出汇总到一个文件，每天早上 8 点查看一次日报。
crontab -l 列出已有任务，crontab -r 删除全部任务（谨慎操作），新加任务后要确认语法正确，可以用 $(date) 先手动执行一遍脚本,别把语法错误留给机器去发现。
监控命令的黄金组合
日常监控不需要额外安装软件，几条命令组合就能覆盖 90% 的场景：
watch -n 2 'free -m'每隔 2 秒实时刷新内存使用情况。watch -n 5 'ps aux --sort=-%cpu | head -10'持续观察 CPU 占用最高的 10 个进程。sar -n DEV 1 3查看每块网卡的实时吞吐量,确认带宽是否被打满。iostat -dx 1 2查看每块磁盘的%util，如果这个值持续接近 100%，磁盘性能已经到位,再压也上不去了。
熟练了这些组合，就算临时被拉去处理故障，也能在 3 分钟内定位到大方向。
服务器管理命令大全到底怎么用才不踩坑
网上有不少《Linux 运维命令大全》类的资料，我建议你别照着抄，原因在于命令的适用范围和副作用经常被忽略，rm -rf / 这种极端操作，或者用 chmod 777
解决权限问题，真正实用的做法是按场景分类,记准每一条命令的用途和风险。
命令使用中的常见风险点
find / -name ".log" -exec rm {} ;这个写法效率极低，而且容易误删系统日志，推荐改用find /var/log -type f -mtime +7 -delete,会安全得多。- 重定向符
>会清空已有文件内容，日志排查时如果顺手打错，会把原始日志直接清掉，建议用>>追加写。 ssh root@server "kill -9 1234"远程执行命令时要特别注意引号转义,最好先在本地写好脚本再传上去执行。
命令学习的高效路径
不要试图一次性记住上百条命令，我推荐的顺序是：先掌握 top、ps、ss、df、dmesg 这五个基础工具，然后学会看 journalctl 和 tail 的日志输出，最后再深入研究 tcpdump、strace、perf 这些高级排查工具。
操作时多用 man 命令查看官方文档，man df，注意看 -h、-i、-T 这些参数的含义，如果你对某一列输出不确定，优先搜该命令的官方手册,而不是轻信非技术社区里的二手解读。
常见问题与解答
如何快速判断服务器是否被入侵？
先看 last 和 who，对比登录来源 IP 是否属于你自己，然后逐个排查异常进程：ps aux 里找名字可疑、CPU 占用异常的进程，用 ss -tp 看看他们连接了哪些外部地址，接着检查计划任务 crontab -l 以及 /etc/cron.d/，很多持久化后门靠定时任务拉起，最后比对系统文件完整性，用 rpm -V 或 debsums -c,发现文件被篡改立即隔离服务器。
为什么磁盘空间没满但业务报错写不进去？
大概率是 inode 耗尽或文件系统只读，先执行 df -h 和 df -i 做对比，确认是否 inode 使用率达到 100%，inode 充足，再执行 mount | grep "ro," 检查是否有分区被只读挂载，这种情况通常发生在文件系统异常之后，自动修复用 fsck -y /dev/sda1,但必须在卸载分区或重启后执行。
日常运营服务器，哪些命令最值得熟练掌握？
高频使用的命令集中在三层：第一层是 systemctl 和 journalctl，负责服务启停与日志管理；第二层是 uptime、free、df、ps，负责系统状态快照；第三层是 ss 和 tcpdump，负责网络排查，把这三层命令练到不假思索就能敲出来,日常运维中的绝大多数问题都能自己解决。
运营服务器的本质不是会背命令，而是知道命令背后反映的系统状态，每一条命令的输出都是一个信号，把这些信号串起来，你就能在故障发生前预判风险，在故障发生后快速止血，从今天开始，拿起手边的一台测试机，把上面提到的命令依次跑一遍,比任何教程都有效。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/765361.html
