网站一直运行得好好的，结果某天上午，用户突然开始集中反馈：页面打不开，图片一直转圈，点个按钮要等十几秒才有反应。运维同事登录后台一看，CPU不高、内存没用满、硬盘也没报警，一时竟找不出问题在哪。这种情况相信不少企业都遇到过，尤其是没有专职运维、网站平时由开发或行政顺带照看的团队。网站变慢的原因可能有很多，但排查顺序一旦不对，很容易在无关环节空耗时间。这篇文章根据实际经验，整理出一套从现象到根因的排查顺序，供网站维护人员参考。
先别急着登录服务器，第一步是先把现象看清楚。打开网站，分别测一下首页、列表页、详情页和后台页面，看看是所有页面都慢，还是只有某几个页面响应慢。再找反馈的用户确认一下，是固定某个时间段变慢，还是全天都慢。如果只是个别页面慢，大概率是页面自身的问题，比如图片体积太大、接口请求数量过多；如果是某个时间段集中变慢，那可能是定时任务、数据备份或者推广活动导致资源占用升高。先把范围缩小，后面每一步排查都会省下不少时间。
确认现象之后，按照顺序来排查网络链路。先从自己电脑出发，用ping命令测试到服务器的延迟，如果延迟很高，可能是本地网络或服务器机房网络出了问题。接着检查DNS解析，用nslookup或在线工具看看域名解析耗时是否正常，DNS解析慢的话，首次打开页面会特别明显。再看服务器带宽，登录云服务商控制台查看带宽监控数据，如果带宽已经跑满，基本可以断定是流量突增或有人正在下载大文件。如果网站接了CDN，还要检查CDN节点状态和回源时间是否正常。网络链路这一层排查完，基本能判断问题是否出在传输环节。
网络没有问题的话，下一步看服务器资源。登录服务器后，先用top或htop查看CPU和内存占用情况，找出占用资源最高的进程。如果CPU持续接近满载，要确认是哪个进程在消耗，可能是程序死循环，也可能是遭到攻击。内存不足会导致系统开始使用交换分区，网站响应速度会明显下降，用free -h可以快速查看内存状况。磁盘IO也很容易被人忽略，用iostat看一下磁盘读写等待时间，如果等待时间偏长，可能是日志写入太频繁或数据库文件碎片化严重。数据库连接数也要关注，连接数一旦满了，所有需要查询数据库的页面都会卡住。这一层排查能定位到大部分资源型瓶颈。
服务器资源一切正常，那问题基本出在应用层。查看数据库慢查询日志，找出执行时间超过一秒的SQL语句，很多时候是因为缺少索引或查询条件没写好。再看接口响应时间，用浏览器开发者工具或接口监控工具，看看哪个接口耗时最长，再逐个优化。缓存命中率也是一个重要指标，如果缓存配置不合理，大量请求直接打到数据库，网站自然会变慢。应用层的问题通常需要结合代码日志来判断，排查时把错误日志打开，看有没有报错信息反复出现。比较常见的应用层原因包括缓存失效、第三方接口超时、定时任务和用户请求冲突等。
网站变慢的排查并不复杂，关键是顺序清晰、工具熟练。总结下来可以复用这样一套顺序：先确认现象范围，再查网络链路，然后看服务器资源，最后深入应用层。每一步都有明确的判断方法，按顺序走下来，大多数问题能在半小时内定位。it数运在网站维护服务中，会为客户建立这样的日常排查流程，把常见检查项和命令整理成文档，遇到问题时按步骤执行，减少慌乱和重复劳动。网站维护的价值不只在于出问题时能修好，更在于用一套稳定的方法把问题快速找出来，让网站恢复正常的节奏更短。
