背景
做了 8 年性能优化，复盘过十几个「优化上线 → 核心指标确实改善了 → 3~7 天后另一个指标悄悄恶化 → 紧急回滚」的循环。举两个真实案例：
- 某支付网关把 DB 批量提交从 50 条调到 500 条，写吞吐上去了 40%，但 5 天后单条最大写入延迟从 8ms 飙到 42ms——因为大事务持有行锁时间变长，并发写热点表时锁等待被放大。当时没有自动回滚，靠 oncall 半夜手动把参数改回来，止血花了 40 分钟。
- 某搜索服务给一个慢 SQL 加了覆盖索引，P99 从 35ms 降到 12ms，但 2 周后写入侧的 insert 延迟涨了 18%（索引维护开销），而且因为该表是核心交易表，回滚索引需要 DDL 锁表，回滚窗口比上线窗口还长。
这两个案例的共同点：优化的收益是即时的、可量化的，但副作用是延迟的、分布在另一个维度的。如果当时有自动回滚机制（指标恶化超阈值自动恢复原参数），第一次案例的止血时间能从 40 分钟压到 30 秒。
常见分歧（我观察到的三种做法）
做法 A：「性能优化 = 一次性配置变更，改完观察即可」 很多团队把改 HikariCP maximumPoolSize、改 Kafka max.poll.records、改批量大小当作运维操作，改完看 30 分钟 dashboard 没炸就收工。回滚就是再改回来，没有工程化流程。
做法 B：「性能优化应该走灰度 + 自动熔断」 把参数变更当作"发布"：先在 1 个实例上生效，观察 1~4 小时，核心指标（P99、P999、错误率、锁等待、CPU steal）全部不恶化才全量推；任何指标恶化超过预设阈值（比如 P99 恶化 > 15% 或 P999 恶化 > 50%）自动回滚到上一版本参数。
做法 C：「性能优化是持续调参，不存在回滚」 部分团队认为参数没有"版本"概念，只有"当前值"，每次调参都是基于最新压测 / 线上数据的"当前最优"，回滚没有意义——因为环境已经变了，旧参数不一定是"正确"的。
我的倾向与理由
我倾向 B，但有一条边界：
- 参数类变更（连接池大小、批量大小、超时、线程池、GC 参数）→ 适合自动回滚。变更和回滚的代价对称（都是改一个数字），回滚窗口短，自动化的收益远大于误触发成本。
- 结构类变更（加 / 删索引、改表结构、改 SQL 逻辑、改分片策略）→ 不适合自动回滚。回滚代价不对称（加索引 1 分钟，删索引可能要 DDL 锁 30 分钟），而且结构变更的副作用往往不是"某个指标恶化"，而是"写入放大 → 磁盘 I/O 打满 → 连锁反应"，单指标阈值很难准确捕捉。这类变更应该走灰度 + 人工确认，而不是自动回滚。
自动回滚的触发条件设计也有讲究，我的经验是：
- 不要只看 P99，至少同时看 P999 + 错误率 + 锁等待 P95（MySQL）或 commit 延迟 P95（PG）；
- 观察窗口至少 4 小时（覆盖一个完整的业务潮汐），不要 30 分钟就判定"没炸"；
- 阈值不要拍脑袋，用过去 14 天同指标的同时间段 P50 + 2×MAD（中位数绝对偏差）做动态基线，比固定百分比更稳。
MAD 动态基线的具体算例（补一个我复盘时漏掉的细节）
上面说「P50 + 2×MAD」，这里给一个真实算例，方便直接抄：
某订单服务 P99 延迟，过去 14 天工作日上午 10:00~11:00 的逐分钟 P99 值（共 14×60=840 个样本）：
- P50 = 14.2ms
- 每个样本与 P50 的绝对偏差中位数（MAD）= 3.8ms
- 动态上界 = 14.2 + 2×3.8 = 21.8ms
如果优化上线后，观察窗口内 P99 连续 5 分钟 > 21.8ms → 触发回滚。
对比固定阈值方案（「P99 > 30ms 回滚」）：
- 固定 30ms 在流量低谷期（凌晨 QPS 只有 50）永远不会触发——漏报；
- 固定 20ms 在大促前压测期（基线 P99 本来就到 25ms）会误触发；
- MAD 基线随时间段自适应，14 天窗口覆盖了工作日/周末/大促前后的分布变化。
MAD 的一个坑：如果你的指标分布是多峰的（比如 P99 在「正常 14ms」和「批量任务跑批时 35ms」两个峰之间跳），MAD 会偏大，阈值偏松。这种情况建议先按业务场景分桶（跑批时段 vs 非跑批时段），每个桶单独算 MAD，而不是混在一起算。
自动回滚的误触发：我踩过的 2 次（补一个原帖漏掉的坑）
原帖只讲了「怎么设计触发条件」，没讲触发条件本身会误触发——这是我上线 3 个月后踩到的：
Case 1：流量潮汐 + 连接池参数联动 我们 HikariCP maximumPoolSize 从 20 调到 40（自动回滚机制在线），下午 3 点大促预热流量涨了 60%，P99 从 18ms 升到 24ms（超过 MAD 上界 22ms），自动回滚把池子改回 20——结果连接池打满，P99 直接飙到 80ms，回滚反而制造了事故。根因：流量涨了但基线还是 14 天前的，MAD 没跟上。修复：触发回滚前加一个「流量基线偏移检查」——如果当前 QPS 偏离 14 天同时段 P50 超过 40%，不自动回滚，只告警，让 oncall 人工判断是「参数错了」还是「流量涨了该扩容」。
Case 2：GC 暂停 + 锁等待的假关联
一次 Full GC（2s STW）导致 P999 瞬时飙高 + 锁等待 P95 飙升，两个指标同时触发回滚条件。但 GC 结束后一切恢复正常，回滚把刚调好的批量参数改回去了，白调。修复：回滚判定窗口从「连续 5 分钟超阈值」改为「连续 5 分钟超阈值且无 GC 暂停事件」，GC 暂停期间（gc_events 计数器有增量）暂停回滚判定，等 GC 结束后重新计时。
总结：自动回滚不是「设个阈值就完事」，它本身是一个需要灰度验证的变更——先跑 2 周「只告警不执行」的 dry-run 模式，确认误触发率 < 1/月再切到自动执行。
想听大家
- 你遇到过「优化上线后 N 天另一个指标悄悄恶化」的具体案例吗？恶化的是哪个指标，多久才发现的？
- 你的团队对「性能参数变更」有没有灰度 / 自动回滚的工程化实践？触发条件怎么定的？误触发过吗？
- 对于结构类变更（加索引、改 SQL），你们怎么平衡「上线收益即时可见」和「副作用延迟出现」这个矛盾？有没有不靠回滚、而是靠「变更前的副作用预估」来前置拦截的方案？
- 你觉得自动回滚的阈值应该按「绝对值」（P99 > 50ms）还是「相对值」（比基线恶化 > 15%）？在流量波动大的业务里，哪种更可靠？