你是否遇到过这样的场景？凌晨2点客户电话打爆，网站访问不了，日志一看 CPU 100%，又或者 Nginx 崩了、PHP进程死了、数据库连不上……
网站宕机对业务的影响，不仅是流量损失，还是信誉打折。今天这篇文章，我不想写“表面功夫”，而是带你看清 宕机的真实诱因，并用一线运维的角度教你如何预防与解决。
一、资源耗尽：看似“小问题”常成“致命打击”
1.1 CPU / 内存使用率飙升
你的网站可能部署了多个服务（Web + PHP + MySQL + Redis），一旦某个服务占用异常，整个服务器都会响应迟钝，甚至拒绝连接。
常见原因：
死循环脚本；
Redis 设置不当，持久化瞬间吃满 IO；
MySQL 无索引查询导致 CPU 飙高。
解决方案：
使用
top、htop、iotop等实时监控资源；设置
ulimit和进程最大数；利用
monit或systemd检测资源异常并自动重启服务。
二、磁盘空间占满：别让日志把你服务器撑炸
很多网站挂掉，罪魁祸首不是攻击，也不是配置，而是：磁盘满了。
2.1 日志文件无滚动策略
如果你没配置日志切割（logrotate），access.log、error.log、slow.log 会越来越大。
实战建议：
bash
# /etc/logrotate.d/nginx 示例/var/log/nginx/*.log {
daily
rotate 7
compress
missingok
notifempty
}2.2 临时目录未清理
如 /tmp/ 下 PHP session 文件、临时缓存、上传失败的残留文件，也可能“吃掉”磁盘。
三、单点故障：系统的“独木桥”式架构是大坑
你的网站所有服务都部署在一个节点上？那这就像整栋楼只有一条逃生通道，一堵就全军覆没。
3.1 没有负载均衡和冗余
一台 Nginx 出错，全站挂掉；一个数据库宕机，所有业务失联。
应对策略：
Nginx + Keepalived 双主热备；
MySQL 主从复制 + 自动故障切换（如 MHA、Orchestrator）；
使用 LVS / HAProxy 实现服务均衡负载。
四、服务崩溃：应用自身也会“猝死”
就算硬件再稳定，服务也可能因为意外退出而“猝死”。
4.1 PHP-FPM 崩溃、Nginx 无响应、Redis 挂起
这类问题通常日志都来不及写，用户直接访问失败。
实战配置建议：
配置
systemd的Restart=on-failure：
ini [Service]Restart=on-failureRestartSec=5
配合
monit/supervisord做心跳监测；配置 Nginx fallback 页面（避免502错误）：
nginx error_page 502 = /fallback.html;
五、应用层配置错误：你配错一行，全站就挂了
5.1 无意间改了 .htaccess、nginx.conf、.env 文件
轻则站点异常，重则服务无法启动。
建议做法：
每次改动使用版本控制（Git）；
在预发环境测试配置后再上线；
引入配置校验流程，Nginx 提供：
bash nginx -t
加分项：如何“提前知道”快挂了？
运维要做的是“提前看到崩溃”——这就是监控体系的价值。
核心建议：
Prometheus + Node Exporter 监控资源；
Grafana 设置可视化面板；
配合 Alertmanager 设置规则（如 CPU 超 80% 报警）；
设置钉钉/企业微信报警渠道，第一时间响应；
总结：宕机不可怕，不知道“为什么宕”才可怕
回顾今天我们讲的内容，你会发现：
宕机，从来不是“突然”的。它是缓慢积累、疏于防范、配置草率的总和。
真正的高可用，不是永不宕机，而是及时恢复 + 快速自愈。
运维不是消防员，而是建筑师——提前设计、构建容错、布好监控，这才是对抗宕机的王道。
