服务器宕机不是突然发生的，多数故障在爆发前几小时到几天就会通过CPU、内存、磁盘、网络和日志留下明显痕迹，抓住这些信号就能把突发停机变成计划内维护。
服务器宕机前兆有哪些？先盯这5个容易忽略的信号
CPU持续飙高且不回落
正常业务高峰期CPU也会升高，但会随流量回落，宕机前常见的情况是：业务量已经降下来，CPU所有核心却长期维持在高位，登录服务器执行top -bn1 | head -20，先看load average，如果load average持续超过CPU核心数的2倍,就要准备排查。
再看CPU时间分布，执行mpstat 1 10，观察%us、%sy、%wa三列，用户态和内核态占用高通常是应用跑满，但%wa长期超过20，说明CPU在等磁盘I/O，用sar -u 1 10可以看历史走势。
低负载服务器的load average通常低于核心数，一旦超过核心数2倍且不回落，配合顶部进程CPU占用异常,这就是明确警告。
内存耗尽与SWAP频繁换页
内存不够时系统开始使用SWAP分区，换页一旦频繁，性能会断崖式下降，执行free -h，重点看available列，如果available长期低于总内存的10%,系统已经站在悬崖边上。
执行vmstat 1 10，观察si和so两列，so持续大于0，说明系统正在把内存页换出到磁盘，更直接的信号是执行dmesg | grep -i "killed process"，如果出现Out of memory: Killed process，说明OOM Killer已经杀过进程,这个信号离宕机往往只差一步。
磁盘I/O等待飙升
磁盘坏道、RAID卡电池失效、日志写满都会让I/O等待升高，执行iostat -x 1，观察%util和await两列。%util长时间接近100%，await从几毫秒升到几百毫秒,写操作就会大量堆积。
执行df -h和df -i查看容量和inode，相当一部分宕机不是因为磁盘物理损坏，而是某个分区被日志写满，执行iotop -o可以看到哪个进程在疯狂写盘，如果磁盘空间已经超过85%且增长速度很快,这本身就是高危状态。
网络丢包与连接数异常
网卡错误、交换机端口故障、TCP半连接队列溢出，都会在网络层先露出马脚，执行
ss -s查看当前TCP连接统计，如果timewait和synrecv异常多,可能是应用连接池配置错误或被攻击。
执行netstat -i查看网卡RX-ERR和TX-ERR列，只要出现非零错误计数，并且数字还在增长，说明物理链路或网卡已经在损坏，执行ping -c 100 网关IP看丢包率，偶发1-2%可以接受，持续超过5%就要检查链路。
系统日志里开始报硬件错误
硬件故障几乎都会先在日志里留下记录，执行dmesg | grep -i error，执行journalctl -p err -n 50，看最后50条错误日志，磁盘用smartctl -a /dev/sda查看Reallocated_Sector_Ct和Current_Pending_Sector，只要这两个值不是0,说明磁盘已经有坏道。
ECC内存错误会在日志里出现Machine Check Exception字样，这类硬件错误不会立刻导致宕机,但累积到一定程度就会触发内核panic。
云服务器宕机前有什么现象？和物理机对比看这3处
CPU steal time异常升高
云服务器上执行top -bn1 | grep Cpu时，会多出一列%st，表示CPU被宿主机上的其他租户抢占，物理机没有这个指标，如果%st长期高于5%，说明宿主机超卖严重，或者邻居实例正在跑高负载，这是云服务器独有的宕机前兆,物理机运维经验在这里完全不适用。
云盘IOPS被限流
云盘有基线IOPS和突发能力，突发额度耗尽后，延迟会突然升高，登录云厂商控制台，查看磁盘平均延迟和IOPS使用率指标，如果平均延迟从几毫秒升到几十毫秒，util走高，就要考虑升配云盘类型，或者清理大文件，物理机本地磁盘没有这个限流问题,这是云环境需要注意的地方。
控制台出现宿主机迁移通知
云厂商有时会在宕机前下发计划迁移事件，控制台会显示“实例所在的物理机需要维护”，这个通知往往提前几小时到几天出现，看到后要主动迁移，或者至少做好快照，物理机没有这种预警,只能靠硬件日志判断。
服务器宕机原因和解决方法：从日志里抓出真凶
宕机原因排查顺序
多数情况下，宕机原因集中在几个方向：资源耗尽、内核崩溃、硬件故障、外部网络中断，排查时先确认宕机具体时刻,再按下面顺序查：
- 登录后先执行
last -x | head -20，看是否有重启记录，确认宕机时间 - 执行
journalctl -p err -n 100，抓取最后100条错误日志 - 执行
grep -i "oom|panic|hung" /var/log/messages，直接搜索关键错误 - 查看
/var/crash是否生成了内核转储文件 - 查看云监控里的CPU、内存、磁盘指标在宕机前的走势，定位最先飙升的指标
不同原因对应的解决方法
- OOM导致宕机：临时加SWAP应急，长期升级内存或限制进程内存，给Java应用加
-Xmx参数 - 磁盘满导致服务停止：删除旧日志，配置
logrotate自动轮转，拆分分区 - 内核panic：升级内核补丁，检查驱动兼容性，配置
kdump便于事后分析 - 硬件故障：更换内存条或硬盘，在BIOS里查看硬件健康状态
- 网络中断：检查交换机端口错误计数，联系机房或云厂商提交工单
服务器宕机一次多少钱？算清这笔账再谈预防
宕机成本不能只看服务器租金，业务损失由多个部分构成，以北京地区中小规模电商网站为例,宕机一小时的成本通常包括：
- 订单流失：按平时每小时订单量乘以客单价估算，具体金额因行业差异很大，但多数情况下网站不可用期间的订单会直接流向竞品
- 广告浪费：如果当天有投放信息流或搜索广告，宕机期间的点击费用照扣，但无法转化
- 运维人力：故障排查一般需要2名工程师投入数小时，按北京地区运维工程师时薪估算，一次重大宕机的人力成本不低
- 云资源额外支出：紧急升配、快照恢复、流量重新调度产生的费用
| 场景 | 主要损失构成 | 事后处理成本 |
| 小型企业官网 | 品牌信任下降，销售线索流失 | 较低，通常只花人工 |
| 中型电商 | 订单流失，广告浪费 | 中等，需要紧急扩容和补偿用户 |
| 大型平台 | 订单、广告、SLA违约金 | 较高，涉及多团队协同和外部赔付 |
行业共识认为，预防性监控投入远低于一次突发宕机的综合损失，把上面几条命令接入Prometheus或Zabbix，设置阈值告警,成本只是少量云主机费用。
北京服务器宕机检测的实操命令清单
北京地区的机房常见问题集中在网络出口和空调散热，但软件层检测命令全国通用,运维人员可以把下面命令做成一个快速排查脚本：
- 系统负载：
uptime - 内存状态：
free -h - 磁盘容量：
df -h - 磁盘inode：
df -i - I/O等待：
iostat -x 1 5 - 进程CPU：
ps aux --sort=-%cpu | head -10 - 进程内存：
ps aux --sort=-%mem | head -10 - 网络错误：
netstat -i - 系统错误：
dmesg | tail -50 - 登录记录：
last -10
把这些命令输出重定向到一个文件，宕机后第一时间查看，比事后翻日志快很多，如果在北京使用云服务器，还可以在控制台开启事件告警,把计划迁移通知直接推到手机短信。
服务器宕机前的信号一直都在，只是多数人没有在故障前打开终端看过一眼，把这套检查动作变成日常巡检，或者交给监控系统自动完成,宕机就不再是黑天鹅。
Q&A
服务器宕机前的常见征兆能用脚本自动监控吗？
可以，把CPU负载、内存可用量、磁盘使用率和I/O等待写成脚本，每分钟采集一次，超过阈值就发短信或钉钉告警，常见的开源方案是Prometheus配合node_exporter,几行配置就能覆盖上面大部分指标。
服务器宕机原因和解决方法有哪些低成本手段？
最便宜的手段是配置crontab定时执行df -h和free -h，输出到日志里，其次是启用logrotate防止磁盘写满，再进一步可以用Zabbix或Prometheus做可视化告警，这些工具本身免费,只消耗少量系统资源。
云服务器宕机前有什么现象容易被忽略？
云服务器上最容易忽略的是CPU steal time升高和控制台里的计划迁移通知，物理机上没有%st指标，很多运维只看CPU使用率，看不到租户争抢的问题，控制台通知如果没设置短信提醒,也会错过迁移窗口。