服务器慢到后台都打不开时，重启按钮很诱人。重启也确实可能让服务暂时恢复，但它同时清掉了最有价值的现场：哪个进程在占CPU、谁把磁盘打满、连接数从什么时候开始上涨。
如果业务还能勉强响应，我通常先给自己五分钟留证。五分钟内不做大范围变更，只回答“哪里慢、从什么时候慢、哪一层先异常”。
第一分钟：确认影响范围
不要只看自己的浏览器。分别检查健康接口、静态文件、动态页面和后台任务；再从另一条网络访问一次。只有一个页面慢，和整台服务器无响应，是两类问题。
第二分钟：记下准确时间
把首次告警、用户反馈、最近发布、备份任务和证书更新放到一条时间线上。日志按时间找问题，比在几GB文件里搜索“error”有效得多。
第三分钟：看CPU和负载的关系
CPU持续接近满载，先找占用最高的进程；负载很高但CPU并不忙，常见方向是磁盘IO等待、不可中断进程或锁。不要看到load高就直接加核心。
第四分钟：内存不能只看used
Linux会把空闲内存用于缓存。更值得看的是available、Swap读写、OOM记录和进程工作集。某个进程内存持续上涨，与瞬时缓存占用不是一回事。
第五分钟：磁盘还有两种“满”
一种是空间或inode耗尽，另一种是容量充足但IO延迟过高。日志暴涨、备份压缩和数据库刷盘都可能让请求排队。只删文件不看IO，不一定能恢复。
网络慢还是应用慢
从服务器本地请求应用，能排除一部分公网线路问题；测试静态文件和动态接口，可以判断Web服务器与应用层。再看DNS、TLS、连接数、丢包和上游API。第三方接口卡住时，本机资源也可能看起来正常。
数据库往往藏在最后
检查连接池、慢查询、锁等待和存储延迟。不要在生产高峰无限开启详细查询日志，它本身会增加IO。抓到一小段可复现样本后就够了。
最近发布过什么
代码、插件、配置、镜像和数据迁移都要算发布。若异常紧跟变更，优先按预案回滚，而不是边修边继续发布。回滚前确认数据库是否有不可逆变更。
如果已经完全打不开
先通过独立监控确认不是本地网络，再进云控制台或带外管理查看实例状态。主机在线但SSH、远程桌面和业务都不可达时，检查安全组、系统防火墙、磁盘和网络告警；控制台也无响应，再按故障预案联系服务商或执行受控重启。
完全中断时也要记住操作顺序和时间。谁在几点改过安全组、几点强制重启、重启后文件系统是否检查，这些都是后续判断数据一致性的依据。
什么时候可以重启
服务已不可恢复、资源泄漏无法在线处理，或重启是已验证的恢复步骤时，可以执行。但先保存关键日志、进程快照和监控截图，并通知业务方。重启后观察指标，不能“能打开了”就关闭故障。
雨云用户可以顺手核对什么
雨云云服务器页面提供控制台、监控、备份和云盘等能力说明。通过极跃圈雨云入口注册可填写admin01，优惠条件以结算页为准。发生故障时，控制台监控可以补充证据，但仍需结合系统和应用日志。
恢复以后做一件小事
写下触发条件、影响、时间线、处置和复发防护。若最后只得到“重启后好了”，下一次还会重复同样的慌乱。哪怕补一个磁盘告警、错开备份时间，也比空泛的“加强监控”有用。
服务器异常排查不是比谁命令多，而是保护现场、缩小范围、每次只改一个变量。这样修复速度反而更快。
