上月结算转化率下降 8%
问题描述
2 月 1 日至 28 日，网页端结算完成率从 4.6% 下降至 4.2%（相对降幅 8%）。下降主要集中在晚间时段，移动端 App 保持平稳。统计窗口内未进行定价调整或重大界面发布。
子问题
这是一个范围较大的问题，因此被拆分为下列子问题。点击任一子问题可查看其假设、实验与结论。若某个子问题本身仍然很大，可按同样方式继续拆分。
结算环节的技术故障
子问题描述
判断技术故障——服务器错误、网关超时或结算路径中的响应缓慢——是否导致用户放弃结算。下降集中在晚间，强烈暗示高峰流量下的负载相关故障。
假设
实验
结论
实验确认存在与负载相关的 504 超时，根源在于 payment-service 的数据库连接池（实验 1.1–1.2）。技术故障是导致晚间下降的确定性因素之一。
某个漏斗环节流失用户
子问题描述
判断是否有某个具体的结算步骤比以往流失更多用户——与技术报错无关——例如表单改动、更严格的校验，或窗口期内引入的布局变化。
假设
实验
结论
漏斗分析显示额外流失集中在支付步骤，与技术发现一致，而非交互变化；表单与校验步骤逐月无变化（实验 2.1）。漏斗 / 交互变化不太可能是主因。
在受控负载下复现结算超时
1 · 实验过程
对预发布环境的结算流程进行压力测试，将并发结算会话从 50 逐级提升至 300（每级递增 50），每级保持 5 分钟，使用与生产相近的数据。每级记录 HTTP 状态码、端到端延迟与数据库连接池指标。
2 · 数据
图表 1 · 504 错误数与并发结算会话数对比。
3 · 数据分析
并发低于 200 时错误接近于零，超过后急剧上升，并与数据库连接池饱和逐级吻合。该关系与负载相关，且与生产环境中晚间高峰的表现一致。
4 · 结论
504 超时可复现且与负载相关，约在 200 并发结算时开始出现，此时 payment-service 的数据库连接池达到饱和。
高峰期各步骤延迟测量
1 · 实验过程
为结算路径埋点，记录各步骤（购物车 → 地址 → 支付 → 确认）的 p95 延迟，并在三个晚间高峰采样，与 1 月基线对比。
2 · 数据
| 步骤 | 1 月 p95 | 2 月 p95 |
|---|---|---|
| 购物车 | 0.3s | 0.3s |
| 地址 | 0.5s | 0.5s |
| 支付 | 1.1s | 6.2s |
| 确认 | 0.4s | 0.4s |
3 · 数据分析
新增延迟几乎全部出现在支付步骤（1.1s → 6.2s），其余步骤均无变化。这将问题定位到 payment-service，与实验 1.1 一致。
4 · 结论
延迟恶化仅出现在支付步骤；漏斗的其余部分运行正常。
按步骤的漏斗流失分析（1 月 vs 2 月）
1 · 实验过程
使用分析数据导出，对比 1 月与 2 月结算漏斗中各步骤的转化情况，查找通过率下降的步骤。
2 · 数据
| 步骤 → 下一步 | 1 月 | 2 月 |
|---|---|---|
| 购物车 → 地址 | 88% | 88% |
| 地址 → 支付 | 81% | 80% |
| 支付 → 确认 | 74% | 66% |
3 · 数据分析
仅在「支付 → 确认」环节通过率下降（74% → 66%）；表单与校验步骤无变化。该流失与子问题 1 中发现的支付步骤延迟和超时相吻合——属于技术原因，而非漏斗改版。
4 · 结论
支付步骤之外的漏斗没有异常流失；交互 / 漏斗变化不太可能解释此次下降。