背景

我们收到一个报障，用户在收银台页面（付款页面）卡在了支付那一步不动。

表现就是按钮的文字从 “立即支付” 变成了 “支付中…”，这个状态是我们的用户体验用户，本身是没有什么问题的。

但是，对于我们程序员来说，完全不知道问题出在哪一步。

支付现状

目前从用户点立即支付开始，我们大概要经历下面这些步骤：

1. 各种校验，比如是否有地址等
2. 当前使用的地址是否可以正常发货
3. 绑定订单地址
4. 各种打点
5. 获取支付信息
6. 调用支付
7. 处理支付结果

从上面的现象看肯定是这其中的某一个步骤出错而我们没有捕获到。

但单纯从代码层面看，并没有发现有隐患的地方，只要涉及到额外的调用我们都加了异常处理。

所以奇了怪了，到底是那一部分出错呢？

解决

我们是不是可以显式的展示出各个操作步骤呢？

就是直观在用户点击 立即支付 按钮后，显式的在按钮上展示每一步的动作。

从技术上来说没有任何问题，但从产品层面来说，用户其实是不关心这些的，用户只关心有没有正常支付，而且本身也会对用户产生很多的困扰。

所以，从这个角度看，这个方式不太行。

那，我们还有没有其他的方式呢？

目标

先理清楚我们的核心目标是能够具体的定位到具体是哪一步出错。

然后从这个目标出发，我们首先能做的就是在每一步开始的时候都打上标记，然后出问题后直接上报

之后的问题就是如何判断用户当时是出错了呢？？？

用户现象

当前的用户现象是用户卡在了 支付中… 这么一个状态。

那我们有没有可能统计一下用户从点支付到支付完成大概要经历多久的时间呢？

这个时间我们目前是可以通过 pipe 去计算出来的，那么我们有理由认为，当用户支付的这个操作处理如果超出了某个值（支付时间平均值 * 1.5），我们认为当前用户就是遇到了支付问题。

我们就应该主动的去关注，去查看，去解决。

最后就剩下去找 pipe 统计一下支付操作的平均时间。

总结

我们认为支付操作的本身应该是在一个预期时间内完成的，如果没有完成，就认为当前用户在支付过程中出问题了。