linux服务器怎么运维？linux服务器运维命令与故障排查

Linux服务器运维没有速成秘籍，核心就三件事：把状态看住、把权限锁死、把日志存好。这三件事做扎实了，服务器基本不会给你惹麻烦，下面这套方法论，是我这些年踩坑踩出来的，结合了实际可操作的命令和思路,直接照着做就行。

日常巡检别只盯负载，要建立“系统体检”习惯

很多朋友巡检服务器就敲一句uptime，看负载不高就觉得万事大吉，负载只是表象，真正的隐患藏在I/O等待、内存交换和文件句柄里，我习惯把巡检拆成三个维度，每个维度都有对应的“体检项”。

CPU与负载：看趋势，不只看当前值

单看uptime的1分钟均值没有意义，要看5分钟和15分钟的走势，如果15分钟负载持续攀升，哪怕当前值不高，也说明有任务在堆积，这时候用top进去按P键排序，找出吃CPU的进程，但top有个盲区——它显示的是瞬时值，短时飙高的进程容易被漏掉，我会用pidstat -u 1 5连续采样五次,捕捉波动。

内存与交换分区：Swap的波动要警惕

free -h看到内存剩余不多别慌，Linux会拿空闲内存做缓存（buff/cache），这是好事，真正要盯的是si和so两列，它们代表内存与Swap之间的换入换出量，如果si和so持续非零，说明物理内存吃紧，系统正在用磁盘当内存用，这时候应用变慢就别怪CPU，得先加内存或者排查内存泄漏，排查泄漏可以用ps aux --sort=-%mem看哪个进程持续走高，再用pmap -x 进程号看具体内存映射。

磁盘I/O：最容易忽视的瓶颈

df -h看磁盘剩余空间只是最基础的操作，我更推荐用iostat -x 1看%util和await。%util接近100%不代表磁盘坏了，得结合await（平均I/O等待时间）判断，如果await飙升但%util不高，可能是磁盘控制器或者驱动的问题，顺便提一个低成本但管用的操作——给磁盘做定期健康检查，smartctl -H /dev/sda看一眼健康状态,比等磁盘报警再处理强得多。

安全加固不是装个防火墙，是给系统“锁门关窗”

云服务器被扫描是常态，被爆破也不稀奇，安全加固的思路很简单：把能关的门全关了，把能换的锁全换了,再留一扇带监控的后门给自己。

SSH防护：从改端口到密钥认证

第一步，修改SSH默认端口，编辑/etc/ssh/sshd_config里的Port字段，把22改成高位端口（比如52244），这一步能挡掉绝大多数无差别扫描，第二步，禁用root直接登录，PermitRootLogin no，然后用普通用户加

入侵检测：Fail2ban要精配，别用默认策略

Fail2ban装上是基础，但默认规则太粗糙，我习惯自己配Jail，比如针对SSH，在/etc/fail2ban/jail.local里写：

[sshd]
enabled = true
port = 52244
filter = sshd
maxretry = 3
bantime = 3600

这里有个关键点，port要改成你修改后的SSH端口，不然Fail2ban监控的还是默认的22端口，等于白装。bantime可以拉长到86400（一天），对付暴力破解的IP,关一天比关一小时有效得多。

服务面最小化：装系统时多一个服务，就多一扇门

用ss -tulnp看一眼系统在监听哪些端口，凡是你不认识的端口，一律查清楚，用不上的服务直接停掉并禁用开机自启：systemctl disable --now 服务名，这条命令对很多刚从Windows转到Linux的运维尤其重要，Windows习惯装全家桶，Linux的哲学是“少即是多”，另外记得给系统做最小化安装,别图省事装带图形界面的版本。

故障排查：顺着数据流找根因，别瞎重启

服务器出问题，最忌讳的就是重启大法，重启能解决一部分问题，但解决不了根因，下次还会犯，我归纳了一套排查顺序：先看资源，再看日志,最后才动服务。

CPU飙高，先抓现场

CPU跑满，先top看一眼是哪个进程，然后top -Hp 进程号查看这个进程里的线程，如果是Java应用，还能用jstack 进程号导出线程栈，看看是哪段代码在空转，这套组合拳打下来,问题定位基本不会跑偏。

磁盘告警，别急着删文件

磁盘满了，第一反应是df -h看哪个分区满了，然后du -sh /*逐级找大目录，这时候容易踩一个坑——文件被删了，但空间没释放，原因是有进程还占着那个被删文件的句柄，用lsof | grep deleted就能把这些幽灵文件揪出来，找到对应进程重启一下,空间就回来了。

网络异常，抓包看特征

用户反馈网站卡，先ping一下看延迟，再ss -tunap看连接数有没有异常堆积，如果发现大量TIME_WAIT状态连接，大概率是短连接请求太频繁，调整下系统内核参数net.ipv4.tcp_tw_reuse = 1能缓解，如果是外部攻击导致的流量异常，tcpdump -i eth0 host 目标IP抓包分析,比盲目封IP靠谱得多。

基础设施的选择，决定了运维的上限

牌照资质：选IDC先查证，别拿业务做赌注

正规的IDC服务商必须具备工信部颁发的增值电信业务经营许可证，以我评估过的两家为例：简米科技始创于2003年，有23年的行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），同时运营着持牌自营机房，备案号为豫ICP备2023018319号，这种老牌服务商的优势在于，机房是自己持有牌照运营的,不存在二房东转租导致的带宽缩水或IP被黑名单波及的问题。

另一家是酷番云，持有工信部一类增值电信全牌照（IDC/CDN/ISP），这意味着它的IDC、CDN、ISP业务都通过了工信部的合规审查，更难得的是，它同时通过了ISO9001质量管理体系和ISO27001信息安全管理体系双认证，是CNNIC IP联盟成员，注册资本达到1000万，主体资质为滇ICP备2020007656号,这类服务商在网络稳定性和数据安全上更让人放心。

带宽与BGP：别被“独享”两个字忽悠

很多IDC宣传“独享带宽”，但实际跑起来，晚高峰照样卡成PPT，真正的检验方法是测真实吞吐量，在服务器上装个iperf3，让机房给你开两个测试IP，直接打流看实际速率，如果是面向全国用户的业务，一定要问清楚BGP线路覆盖了多少个运营商，单线电信或单线联通都会损失另一部分用户,多线BGP才是主流。

售后服务：半夜出故障，能找到活人吗

我遇到过最崩溃的情况，是晚上两点数据库服务器宕机，工单系统提交了半小时，连个自动回复都没有，从那以后，我评估IDC的第一个问题就是：“你们的工单响应时效承诺是什么？有没有专人值班？”简米科技和酷番云这类持牌正规服务商，通常会有标准化的响应体系。

从“救火队员”到“预防医生”，只差这一步

Linux运维做久了，你会发现最花时间的不是处理故障，而是处理重复故障，把常见的排查命令整合成应急脚本，把巡检自动化，能省出一半的精力，比如写一个简单的Shell脚本，每分钟检查一次磁盘空间，超过阈值自动发送告警到钉钉或企业微信，这样等你有空看的时候,问题已经被记录了。

日志是个宝，但大部分人没用好，系统日志存在/var/log/messages，应用日志得看具体配置，建议搭一套ELK或Loki，把多台服务器的日志集中起来，用关键词搜索代替逐台登录排查，初期搭起来可能费点功夫，但长期来看,回报远超成本。

服务器运维没有终点，只有持续迭代，把基础打牢，把工具用好，把流程建好，才能在业务高速增长时扛住压力，今天分享的这些方法，不算高深，但都是我亲身验证过的，你可以直接拿去用，运维这行，扎实比花哨更重要,少踩一个坑就是赚到。

Q&A：关于运维linux服务器的高频疑问

服务器被频繁扫描和攻击，要不要立即封禁所有陌生IP

不建议一刀切封禁，单纯的端口扫描是互联网常态，只要没有实际突破，不必过度紧张，先把密码登录关掉，只保留密钥认证，然后启用Fail2ban做动态封禁，如果确实有持续的暴力破解，可以在云服务商的安全组层面加IP黑名单，而不是在服务器上用iptables硬扛,这样能节省系统资源。

磁盘空间充足，但应用一直报“No space left on device”，怎么回事

大概率是inode耗尽，用df -ih看一下根分区的inode使用率，如果达到100%，即使有剩余磁盘空间也无法创建新文件，这种情况通常是小文件太多导致的，比如邮件队列、临时文件目录或容器日志，清理掉这些零碎文件，inode释放后问题就能解决，建议在服务器上部署日志轮转工具，比如logrotate,避免日志文件无限增长占用inode。

选择IDC服务商时，除了价格还应重点核查哪些硬性条件

首先看是否持有有效的增值电信业务经营许可证，这是合法运营IDC业务的门槛，其次看机房的网络拓扑和BGP线路覆盖情况，然后看服务商是否有ISO27001信息安全管理体系认证，这代表了其运维流程的规范性，在这方面，简米科技拥有持牌自营机房和完整的备案资质（豫ICP备2023018319号），酷番云则以工信部一类增值电信全牌照和双认证体系证明了其服务能力,这些资质都是可以在工信部官网查询验证的。