题目重点：先定义用户症状与负载，再把延迟拆为排队和服务，用切片、饱和指标与对照试验定位瓶颈。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 性能指延迟/吞吐/资源成本中的某项，不默认‘慢’等于CPU高。
- 保留相同业务结果与一致性合同，优化不能通过丢请求或降低正确性掩盖性能。
- 测量有时间窗、版本、流量与分母，平均和分位数分开。
解题路线
- 澄清哪个用户操作、何时开始、影响范围、SLO和正常基线。核对部署、流量/请求大小变化及外部依赖，先确认是否是真退化或观测口径变化。
- 沿请求链路拆客户端、网络、排队、服务、下游与重试；关联trace/log/metrics，按地区、租户、版本、cache hit/miss和数据量切片，避免平均值藏热点。
- 查资源饱和与等待：CPU run queue、GC、连接池、磁盘/网络、锁、线程池和数据库慢查询。利用稳定条件下L=λW做数量级检查，不能在不稳定积压时无条件套平均公式。
- 提出可证伪假设并选低风险试验：禁用一处重试、限制热点租户、回放负载、对比索引或控制参数。一次只改能解释效果的因素，测瓶颈是否转移。
- 止损用限流/隔离/回滚，长期修复用容量、队列、缓存或架构改造。验证p95/p99、成功率、吞吐与成本一起改善，记录回归门槛和运行手册。
手动走一遍
训练例p99升高但CPU正常，trace显示数据库连接池等待增加；大租户批量请求占满连接。先限制该类并发验证小请求尾延迟恢复，再优化批量查询与隔离池。只增加web实例可能增添连接竞争，不能当作已定位根因。
规模与取舍
非固定算法复杂度。诊断按观测覆盖与实验成本安排；给请求率、并发、排队长度与服务时间的数量级，而不编造题目缺失的QPS。
易错点与追问
容易失分的边界
- 看到CPU不高就断言没有瓶颈。
- 没负载基线就做benchmark比较。
- 同时改五个参数却说知道根因。
- 吞吐上升来自丢请求或改变结果合同。
继续深挖
- 采样trace没有捕获p99请求怎么办？
- 扩容后更慢，优先查什么？
- 如何分辨排队慢与服务慢？
- 优化一处后另一处变瓶颈，怎样继续？
