背景
做了 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 小时。所以"上线后修"不是零成本，它把成本从"开发时间"转移到了"数据修复 + 用户信任"上，很多时候后者更贵。
教训 3：核心 / 非核心的边界必须用 SLO 错误预算量化，不能靠"拍脑袋"定。
这条是这次修订补上的，因为教训 1 只解决了"什么改动必须压测"，但没解决"核心链路的 P99 阈值到底该定多少"。
我们的做法：给每条核心链路定一个月度 SLO 错误预算（Error Budget），然后反推"这条链路每月允许劣化多少次、每次允许劣化多少 ms"。具体公式：
月度错误预算 = (1 - SLO) × 月度总请求量
例：SLO = 99.9%（P99 < 200ms），月请求量 5 亿次
错误预算 = 0.1% × 5亿 = 50 万次"超时请求"的容忍空间
如果一次 P99 劣化事件影响 10 分钟、期间 8 万请求超时
→ 消耗错误预算 8万/50万 = 16%
→ 每月只允许 6 次这样的事件
为什么这比"拍 P99 阈值"强？ 因为它把"性能阈值"和"业务损失"绑定了——业务方看到"这次改动会消耗 16% 的月度错误预算"，比看到"P99 从 150ms 变到 180ms"有感知得多。
我们踩过的坑：最初只定义了"P99 < 200ms"这个绝对阈值，结果一条 P99 稳定在 195ms 的链路，每次劣化 5ms 都"合规"，但累积效应让用户体验持续下降。加了错误预算后，"每次 5ms 的劣化"不再合规，因为它在消耗有限预算。
避坑清单（我团队现在在用的）：
- 性能回归测试不要追求"全量"，但必须覆盖变更影响到的调用链（不是所有接口，是 diff 涉及的接口）。
- 压测环境必须和线上同规格（至少 CPU/内存/磁盘同型号），不同规格下的 P99 数据没有可比性。
- 告警阈值不是"定一次就完事"，每个季度用线上真实 P99 分布重新校准一次，否则阈值会"漂移"到永远不触发。
- 回滚预案要包含数据一致性校验步骤，不只是"回滚代码"。
- 性能回归失败的 MR 不是"不能合"，而是"必须有性能 owner 签字 + 写明劣化原因 + 给出修复排期"——完全 block 会导致开发绕过流程。
- 核心 / 非核心的分界线必须用 SLO 错误预算量化（见教训 3），每季度和业务方重新对齐一次"这条链路消耗多少错误预算算合理"，否则分级标准会随业务增长而失真。
想听大家聊聊
- 你们团队的性能红线（P99 阈值、错误率阈值）是怎么定的？是"拍脑袋"还是有数据支撑？多久校准一次？
- "上线前压测"和"上线后监控"，你们团队的实际比例大概是多少？有没有从一种策略切到另一种的经历？
- 改动"非核心链路"的性能问题时，你们有没有遇到过"以为不影响核心，结果级联炸了"的案例？
- 作为 PM / 产品，你在性能问题上的决策权到底有多大？是"我说了算"还是"我提需求，开发决定"？
期待看到不同规模团队、不同业务场景下的真实做法。没有标准答案，但多听几个案例，下次自己团队定策略时能少踩一个坑。