服务器突然变慢，控制台打不开，网页一直转圈，运维和开发者大多遇到过。先别急着重启或重装。重启能暂时缓解，但原因还在，过几天很可能再来一次。按下面的顺序排查，通常能较快找到原因。
一、先分清是哪一层卡了
“卡”的范围很宽。可能是云服务器自身的CPU、内存、磁盘被占满，可能是网络链路不稳，也可能是控制台或某个云产品本身出了问题。方向不同，接下来要做的事也不同，所以第一步是缩小范围。可以先做三个简单判断：
- 能否通过SSH登录实例。登录不上，多半是负载高到无法响应，或者网络层出了问题。
- 控制台能否正常打开。实例运行正常而控制台打不开，更可能是本地网络或浏览器缓存的问题，换个网络或清一下缓存再试。
- 业务访问是否只在某个地区变慢。如果只有部分地区慢，重点看跨地域访问或运营商线路。
二、看清CPU、磁盘和内存
能登录实例后，先看负载和资源。top 可以快速看到CPU和内存占用最高的进程，df -h 查看磁盘空间，iostat 查看磁盘读写压力。iostat 一般需要先安装 sysstat 才能使用。
磁盘和内存最容易被忽略。内存不足时系统会频繁使用swap，磁盘读写骤增，整台机器就会表现为“卡住”。free -m 能看到swap的使用量。如果swap长期居高不下，要么内存规格确实不够，要么某个进程存在内存泄漏，需要继续查看具体进程。
案例一：某个小型电商站点在大促期间响应越来越慢。登录后发现磁盘使用率已经到100%，日志文件无限增长。应用写日志失败后不断重试，CPU也被拖高。清理过期日志并配置 logrotate 之后，服务几分钟内恢复正常。这类问题的提醒是：日志要有轮转和保留期限，磁盘告警不要等到使用率很高才触发。
案例二：一个定时任务每次运行都会把全部数据读入内存，数据量增长后，单次运行就能占满2GB内存。改成分页处理后，内存稳定在300MB左右，服务器不再频繁卡顿。遇到这种情况，先看任务是不是一次性全量加载，再考虑升级配置，通常更划算。
三、排查网络与安全组
如果实例资源看起来充足，访问却明显变慢，就要转到网络层。检查安全组规则是否过严，有没有误封业务端口；用 ping 和 traceroute 观察延迟和丢包，判断问题出在哪一段；再看带宽峰值是否已经顶到上限。
案例三：某团队的网站在早晚高峰访问缓慢，监控显示公网带宽长期接近上限。原因是静态图片没有走CDN，全部由源站直接输出。接入CDN并开启缓存后，源站带宽占用下降了一半以上。图片、脚本这类静态资源，不应该长期占用源站带宽。
四、别忽略应用与数据库
很多时候服务器指标看起来正常，卡顿的来源却在应用层。数据库连接数耗尽、慢查询堆积、缓存失效后大量请求直接打到数据库，都会让用户觉得整个系统卡住了。这类问题在主机指标上不一定能看出异常，排查时要把数据库和应用日志一起看。
可以在数据库控制台查看慢查询日志，对可疑语句用 EXPLAIN 分析执行计划，同时检查连接池的最大连接数是否合理。连接数设得过大，数据库反而可能先被拖垮。
案例四：某后台管理系统打开列表页要等十几秒。排查发现，一条订单查询语句的筛选字段上没有索引，表数据超过两百万行后，每次查询都是全表扫描。补充联合索引后，同样的查询从十几秒降到几十毫秒。新增索引前最好先在测试库验证，因为索引也会增加写入开销。
五、借助官方工具、工单和预防
自己排查无果时，可以打开阿里云控制台的云监控和运维中心，查看历史指标和告警记录，很多问题的时间线在这里一目了然。也可以查看阿里云服务健康状态页面，确认是否有地域性故障公告。如果判断问题出在平台侧，直接提交工单，并附上时间点、实例ID和具体现象。描述越具体，处理通常越快。
卡顿往往是慢慢积累出来的，预防比救火省事。可以提前做几件事：为CPU、内存、磁盘设置告警阈值；定期清理日志；核心业务预留余量或配置弹性伸缩；重要数据做好备份。监控配好之后，问题刚露头就能发现，不用等用户投诉才知道。
