回归需要基线
“应用变慢”不可行动。回归是相对已知基线的变化：部署 42 之后，GET /checkout 的 p95 从 180 毫秒升到 640 毫秒，错误率不变。这个陈述可以被检验。先记录指标、对比窗口和受影响人群。
hey -z 30s -c 50 https://staging.example.com/checkout在同一环境中对上一构建和当前构建运行相同命令。如果改变负载后差异消失，问题可能是容量或流量结构，而不是代码。当工作负载难以复现时，生产金丝雀对比通常比预发环境更好。
先缩小范围再优化
把开始时间与部署、开关、依赖版本和数据库变更关联。如果多个变更一起发布，使用分组或受控环境中的 git bisect。火焰图或追踪可以定位慢跨度，但要在回归复现之后。没有复现就优化，常常改进了不是问题的那条路径。
先缓解，再修复
回滚是一种有效的诊断工具。它恢复用户并确认变更窗口包含原因。功能开关可以不完整部署就禁用新路径。如果是容量问题，扩容可能缓解用户压力，但要把它记录为缓解而不是修复。
守住分位数
在 CI 中增加基准测试，或对受影响分位数设置生产告警。用固定负载比较 p50、p95 和 p99。只检查平均值的性能预算会漏掉尾延迟，而尾延迟正是用户体验和下游超时感受到的部分。