系统上线时挺快，用了半年一年开始卡。用户报上来的说法通常是系统变慢了，但这句话包含的信息量几乎为零。同一个慢字后面，可能是网络问题、数据库问题，也可能是代码问题，处理方式完全不同。
排查的第一步不是改代码，是把范围缩小。下面这套顺序，甲方自己也能先走一遍，走完再找开发方，沟通效率会高很多。
一、先确认慢的范围
要问清楚三件事。是所有页面都慢，还是只有某几个页面慢。是所有人都慢，还是只有某些人或者某些地点慢。是一直慢，还是集中在某个时间段慢。
这三问能把范围砍掉一大半。全都慢且所有人慢，通常指向服务器或者数据库这类公共资源。只有某个地点慢，多半是网络或者终端的问题。只有某几个页面慢，一般是这几个页面涉及的查询或者逻辑有问题。集中出现在某个时段，则要看看那个时段是不是有批量任务在跑。
这里有个容易忽略的点，要区分感觉慢和真的慢。有的慢是因为页面加载的东西多，有的是因为操作后没有任何提示，用户以为没反应又点了一次。前者是技术问题，后者是交互问题，改法完全不同。
二、看几个能拿到的数据
服务器层面的资源占用，这个是运维能直接看的。中央处理器的使用率、内存占用、磁盘空间和读写情况。磁盘空间占满是很常见的原因，表现就是什么都慢，清理一下立刻恢复。
数据库层面的数据量增长。看看主要业务表现在有多少条数据，一年前是多少。数据量从五万涨到两百万，很多原本没问题的查询就会开始变慢，这是最典型的随时间推移变慢的原因。
网络层面可以做个简单测试。在同一台电脑上打开别的网站是否正常，在同一个网络里换一台电脑打开系统是否正常。这些对比能快速排除或者确认网络因素。
三、三类原因各有什么特征
网络问题的典型特征是，页面能打开但元素加载不全，或者操作要等很久才提交出去，同一台电脑换个网络环境就正常。这种情况通常跟服务器的带宽、路由或者中间的安全设备有关。
数据库问题的典型特征是，查询类页面明显慢于录入类页面，翻到后面几页特别慢，带统计的页面最慢。这些症状都指向数据检索效率，常见处理方式是加索引、优化查询语句、把历史数据归档。
代码问题的典型特征是，某个具体操作特别慢，比如保存一张单据要等十秒，而其他操作都正常。这类往往是这段代码里有循环调用或者串行的外部请求，属于实现层面可以优化的问题。
四、该找谁处理，怎么提要求
网络问题找运维或者网络服务商。数据库和代码问题找开发方。服务器资源问题看是自建还是托管，自建的自己处理，托管的联系服务商。
向开发方提的时候，最好带上前面收集的信息，什么时间、哪些人、哪些页面、大概慢多少秒、是不是每次都能重现。有条件的话截个屏或者录一小段。这些信息能让开发方少走很多弯路，也避免对方用没重现出来搪塞过去。
有一点要提醒，系统变慢和系统不行是两回事。大多数慢是可以优化的，优化之后能恢复到可用水平，不一定需要推倒重来。碰到有人一上来就建议重做系统，可以先问清楚慢的具体原因是什么，再看这个建议是否成立。