背景
做了 15 年技术 PM，管过电商、SaaS、数据平台三个业务线，"性能"这个维度在发布流程里的位置，是我跟工程团队吵得最久、也最没有标准答案的事。
去年我们经历了一次典型事故：一次"小改动"——把商品列表接口的缓存 TTL 从 60s 改成 30s，逻辑上没问题，上线后 P99 从 45ms 飙到 210ms，持续了 11 分钟才被发现回滚。根因是 TTL 缩短后缓存命中率从 92% 掉到 71%，DB 连接池瞬间打满。
事后复盘会上，开发说"压测没覆盖这个场景"，SRE 说"告警阈值定得不够敏感"，我作为 PM 被问了一句最扎心的话："这种问题，为什么不是上线前就该拦住的？"
三种常见做法
我观察过不少团队，大致分三派：
A 派：上线前必须过性能关。
- 每个 MR 附带压测报告（JMeter / wrk / k6），P99 不允许劣化超过 10%。
- 性能回归测试进 CI，不通过就 block merge。
- 典型场景：金融、支付、核心交易链路。
- 代价：压测环境成本高，CI 流水线变慢，开发抱怨"改个文案也要跑 20 分钟压测"。
B 派：上线后靠监控兜底，"快速发现、快速回滚"。
- 上线前只做冒烟，不做全量压测。
- 线上有完整的 P50/P95/P99 看板 + 自动告警 + 一键回滚。
- 典型场景：迭代极快的互联网产品、内部工具。
- 代价：第一次踩坑的代价由线上用户买单，回滚窗口内已经产生了脏数据 / 资损。
C 派：分级策略。
- 核心链路（下单、支付、登录）走 A 派；非核心链路（推荐、日志、报表）走 B 派。
- 典型场景：中大型团队，有 50+ 微服务。
- 代价：分级标准本身需要持续维护，"这个改动到底算核心还是非核心"经常扯皮。
我的倾向与踩坑经验
我整体倾向 C 派（分级），但有两个"血泪教训"想分享：
教训 1：分级标准写得太粗，等于没分。 我们最初写的是"核心链路需压测，非核心链路不需要"，结果"核心"的定义变成了"开发自己判断"。一个改缓存 TTL 的 MR，开发认为"只是配置变更，不算核心改动"，跳过了压测。后来我们加了一条硬规则：凡是改动涉及 DB 查询路径、缓存策略、连接池参数、线程池大小的 MR，无论代码量大小，必须过性能回归。 这条规则上线后，类似事故再没出现过。
教训 2："上线后修"的前提是你真的能在 5 分钟内回滚。 很多团队说"我们有快速回滚能力"，但实际演练时发现：回滚一个已经写了 30 分钟的增量数据，不是"点一下按钮"就完事的。我们有一次回滚后发现 DB 里有 12 万条脏数据，清理花了 3 小时。所以"上线后修"不是零成本，它把成本从"开发时间"转移到了"数据修复 + 用户信任"上，很多时候后者更贵。
避坑清单（我团队现在在用的）：
- 性能回归测试不要追求"全量"，但必须覆盖变更影响到的调用链（不是所有接口，是 diff 涉及的接口）。
- 压测环境必须和线上同规格（至少 CPU/内存/磁盘同型号），不同规格下的 P99 数据没有可比性。
- 告警阈值不是"定一次就完事"，每个季度用线上真实 P99 分布重新校准一次，否则阈值会"漂移"到永远不触发。
- 回滚预案要包含数据一致性校验步骤，不只是"回滚代码"。
- 性能回归失败的 MR 不是"不能合"，而是"必须有性能 owner 签字 + 写明劣化原因 + 给出修复排期"——完全 block 会导致开发绕过流程。
想听大家聊聊
- 你们团队的性能红线（P99 阈值、错误率阈值）是怎么定的？是"拍脑袋"还是有数据支撑？多久校准一次？
- "上线前压测"和"上线后监控"，你们团队的实际比例大概是多少？有没有从一种策略切到另一种的经历？
- 改动"非核心链路"的性能问题时，你们有没有遇到过"以为不影响核心，结果级联炸了"的案例？
- 作为 PM / 产品，你在性能问题上的决策权到底有多大？是"我说了算"还是"我提需求，开发决定"？
期待看到不同规模团队、不同业务场景下的真实做法。没有标准答案，但多听几个案例，下次自己团队定策略时能少踩一个坑。