结论先行：用户说慢、监控说正常，这两句话并不矛盾——它们测的不是同一件事。资源指标测的是服务器忙不忙，用户感受到的是「从点击到看见结果」这一段有多长，中间还夹着网络、前端渲染与第三方依赖。可行的判定顺序是从用户侧往内查：先确认慢发生在哪一步（首屏、点击、提交、查询），再看这条请求在链路上哪一段耗时最长，最后才去看那一段依赖了什么。顺序反了，就会陷入「指标全绿、问题依旧」的循环。

「慢」至少是四种不同的东西

用户说「慢」，落到技术上可能是完全不同的四件事，处置方式也不同。

  • 首屏慢：页面打开要等很久才有内容。这类问题多半在资源加载与渲染，服务器侧的 CPU 与内存可能毫无异常。
  • 操作慢：页面能打开，但点一个按钮之后要转圈很久。问题通常在接口响应，可能是单次查询慢，也可能是排队。
  • 偶发卡顿：大部分时候正常，某个时段突然变慢，几分钟后又好。这类最难查，因为它往往与并发量、缓存失效、连接池耗尽这些「有触发条件」的因素相关。
  • 感觉慢：耗时数据看起来正常，但用户就是觉得慢。可能是一次多余的跳转、一个不必要的人工确认步骤，纯粹是流程设计的问题。

不分清是哪一种，就会把所有「慢」当成同一种问题处理：加内存、加机器。这类处置对偶发卡顿也许有效，对流程问题完全无效。

先看用户侧：把「慢」变成可描述的现象

真实用户侧的耗时数据，是这条链上最容易被忽略、也最不该忽略的一环。它能回答几个纯靠服务端指标答不出的问题：慢发生在哪个页面、哪个地区、哪种设备、哪个运营商；是一次很慢，还是每次都慢一点。

如果暂时没有这类数据，退一步的做法是让用户描述三件事：从哪一步开始慢、慢的时候屏幕在做什么、换个网络或换台机器还慢不慢。这三句话能快速把范围缩小一半——换设备也慢，多半不是端侧；只在自己工位慢，多半是链路或本地环境。

再看链路侧：一段请求，五段耗时

把一次用户操作还原成一条完整路径，通常要跨过五段：浏览器发起、网关接入、应用处理、数据库或缓存、第三方接口。有没有一条贯穿的请求标识把这五段串起来，决定了排查是「看一条线」还是「翻五套系统」。

没有贯穿标识时，典型的表现是：每套系统都能证明自己这一段正常，但合起来就是慢。这时候团队会开始互相怀疑，而每一方拿出的证据都成立。补齐的办法不复杂，但需要一次性改造：统一请求标识的生成与透传、统一时间戳口径、让应用、数据库与接入层都能按同一个标识检索。

有了这条线之后，判定就变成一句可执行的话：看这条请求在哪一段停留时间最长。停留在一段之内，就往那段里查；如果是平均分布在多段，那多半是网络往返或连接建立的问题，而不是某一处代码。

最后看依赖侧：那些「不是我们的问题」

隐性性能问题里，很大一部分落在依赖上：慢查询、第三方接口抖动、连接池耗尽、线程阻塞。它们的共同点是——在自己的系统里看一切正常，因为等待发生在别人那里。

这一类问题有两个可操作的动作。其一是给每个外部依赖设定独立的耗时指标与失败率，而不是只记录整条请求的总耗时；总耗时变长时，能立刻看出是哪一类依赖在拖。其二是把「依赖变慢」与「依赖报错」分开统计：报错会触发告警，变慢不会，而后者往往影响面更大——因为它不产生错误日志，只是让所有请求慢一点。

线程阻塞与死锁这类问题还要额外看一眼并发模型：在请求量上升时，如果耗时是台阶式上升而不是平缓上升，通常意味着某处的并发上限被打满了。

三类问题，三种不同的修法

  • 容量问题：加资源能缓解。但要注意先确认瓶颈在哪一层，盲目加应用节点可能只是把压力推给数据库。
  • 结构问题：加资源无效，必须改调用关系。比如一次页面加载串行调用了十几个接口，加机器只会让每个接口都快一点，总耗时仍然被串行次数决定。
  • 体验问题：技术侧可能没有可优化空间，要动的是交互——先返回骨架屏、把非关键请求延后、把三个确认步骤合并成一个。

把问题归到这三类里，讨论才会从「到底谁慢」转到「该怎么改」。分类本身也是一种共识工具：技术团队与业务方对同一现象的判断经常不同，往往不是谁错，而是各自看到了不同的一段。

哪些指标值得放进日常看板

不需要几十个指标，四项就够启动：用户侧请求耗时的分位值（关注尾部，不看平均）、按依赖拆分的耗时占比、慢请求的分布（集中在少数请求还是普遍变慢）、以及一次故障从发现到定位所用的时间。最后一项最容易被忽略，但它反映的恰恰是这套能力到底有没有用——如果每次定位仍要几个小时，说明串联与检索的能力还没建起来。

边界与前提

其一，用户侧采集涉及终端与个人信息，采集范围、告知方式与留存期限要按合规要求单独确认，不能因为「排查方便」而无限扩大。其二，末尾耗时数据本身有统计口径问题（分位值算法、采样比例不同会得出不同结论），做对比时要用同一套口径。其三，本文讨论的是判定顺序，不涉及具体工具的选型；不同环境的可观测能力差别很大，先确认能拿到哪些数据，再谈顺序。

深圳市奇摩计算机有限公司在做全链路监测类项目的交付时，会先把「用户侧—链路侧—依赖侧」这三段的数据打通，再谈告警规则——数据没串起来之前，配再多的告警也只是让噪音更大。需要把这套判定顺序对照自己的系统过一遍，欢迎 预约咨询。