故障处理最大的浪费是猜。没有信息就重启、重装、重启 —— 往往既没修好，又把现场破坏了。这一页写的是我们排查的顺序，以及你在出故障时可以先做的几件事。
第一时间该做的三件事
- 保留现场
不要立刻重启。截图、记录报错、保存日志（dmesg、nginx / apache error log、journalctl）。重启会清掉大量关键信息。
- 确认范围
是单台机器、一个服务、一个用户，还是全部？最近有没有变更（升级、改配置、换 IP、装软件）？多数故障与变更相关。
- 先恢复还是先查清
业务等不起就先恢复，但至少保留一份现场信息。很多「已经好了」的问题其实是把现场清掉了。
常见故障与判断路径
| 现象 | 可能原因（按概率排序） | 关键检查点 |
|---|---|---|
| 网站打不开，502 | 后端服务挂了 / PHP-FPM 进程耗尽 / 连接数据库失败 | 服务状态、错误日志、连接数、数据库是否可达 |
| 网站 500 | PHP 致命错误 / 内存不足 / 文件权限 | PHP error log、memory_limit、目录属主 |
| 突然很慢但负载不高 | 磁盘 IO 打满 / 内存不足在 swap / 数据库慢查询 | iostat、free + vmstat、慢查询日志 |
| 磁盘写满 | 日志未轮转 / 未清理的临时文件 / 备份未清理 / 数据库 binlog 堆积 | du 逐层定位、看 inode 是否耗尽 |
| 内存耗尽 | 进程数超限 / 某服务泄漏 / 没设 swap 保护 | 进程 RSS 排行、是否有频繁重启的服务 |
| 频繁重启 / RAID 降级 | 电源不稳 / CPU 过热 / 硬件故障 | IPMI 日志、SMART、RAID 卡事件、温度与风扇状态 |
| 硬盘告警 | SMART 状态异常 / 坏道增长 / 振动 | SMART 关键属性趋势（不要只看通断）、厂商工具检测 |
| 网络不通 | 网卡故障 / 交换机端口 / 上游线路 / 路由配置 | 分层 ping、网卡状态、机房侧确认 |
| 被攻击 / 异常流量 | DDoS / 扫描 / 漏洞利用 | 流量趋势与来源分布、WAF 日志、连接数 |
| 证书过期 | 没配自动续期 / 续期失败 / 路径变更 | 证书实际有效期、续期任务日志与最近一次执行结果 |
排查时的通用原则
先看时间线
故障开始时间与最近一次变更时间对得上，十有八九是变更引起的。系统日志的时间戳可能不准，要先确认时区。
分层定位
物理层（硬件、链路）→ 系统层（资源、进程）→ 服务层（应用、日志）。跳过前面直接看应用日志，容易在错误层面浪费时间。
一次只改一个变量
同时改三处然后问题消失了，你不会知道是哪一处生效的，下次还会犯。改一处、验一次。
修复后查根因
「重启好了」不等于解决。要说明为什么坏、为什么没告警、怎么防止再发生，这部分会写进月报。
你能先做的准备
- 确保有可用的管理通道（IPMI / iDRAC / iLO，或云控制台的 VNC）—— 故障时 SSH 可能连不上
- 保留一份可恢复的备份，且知道怎么恢复
- 关键角色与端口清单留档（谁在管、怎么联系、开了哪些服务）
- 监控告警真的有人在看，而不是发到没人看的邮箱
常见问题
紧急故障多久能到？
签了 7×24 响应的客户，紧急故障（业务中断、数据丢失风险、安全事件）我们会在第一时间接手处理。具体响应时间以合同约定为准，签约前会明确写清哪些算紧急。
硬件故障你们负责换吗？
我们负责判断、协调与验证。硬件本身由厂商或机房负责，我们配合定位槽位、协调上门或远程更换、更换后做重建与验证。协商流程和责任划分会在签约前讲明白。
能不能只做故障处理，不签长期？
可以，按次计费。但需要提醒的是：如果环境本身有配置缺陷（没监控、备份不可用、没有文档），单次修好了还会再坏。我们会直接把这个风险告诉你。