背景
做了 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（中位数绝对偏差）做动态基线，比固定百分比更稳。
想听大家
- 你遇到过「优化上线后 N 天另一个指标悄悄恶化」的具体案例吗？恶化的是哪个指标，多久才发现的？
- 你的团队对「性能参数变更」有没有灰度 / 自动回滚的工程化实践？触发条件怎么定的？误触发过吗？
- 对于结构类变更（加索引、改 SQL），你们怎么平衡「上线收益即时可见」和「副作用延迟出现」这个矛盾？有没有不靠回滚、而是靠「变更前的副作用预估」来前置拦截的方案？
- 你觉得自动回滚的阈值应该按「绝对值」（P99 > 50ms）还是「相对值」（比基线恶化 > 15%）？在流量波动大的业务里，哪种更可靠？
0赞
0收藏
0楼层