0.8 性能工程闭环

上一节：0.7 九条常见谬误自查清单　|　下一节：0.9 从 C++ 到 JVM：哪些直觉必须修正

一句话结论

性能工作不是一个「上线前压一次」的动作，而是一个八步循环。 每一次优化后的回归数据，都会成为下一轮的基线。

一、八步闭环

        ┌─────────────────────────────────────────────────┐
        │                                                 │
        ▼                                                 │
① 定义目标(SLO)                                           │
        ↓                                                 │
② 建立模型（Little's Law / 队列估算）                       │
        ↓                                                 │
③ 采集数据（压测 + 四层指标）                                │
        ↓                                                 │
④ 剖析归因（火焰图 / JFR / 线程快照）                         │
        ↓                                                 │
⑤ 定位根因（证据链 + 贡献占比）                              │
        ↓                                                 │
⑥ 优化（按优先级）                                          │
        ↓                                                 │
⑦ 回归验证（统计显著 + 长稳）                                │
        ↓                                                 │
⑧ 固化为门禁与监控 ─────────────────────────────────────────┘

为什么是循环而不是流程：第 ⑧ 步的监控数据会成为下一轮第 ① 步「目标是否需要调整」的输入；第 ⑦ 步的回归结果会成为下一轮第 ③ 步的基线。性能工作没有终点，只有「当前这一轮的稳定态」。

二、逐步拆解：每步做什么、产出什么、最容易在哪里失败

① 定义目标（SLO）

② 建立模型

这一步最容易被跳过，但它的性价比极高：如果算出来「需要 60 个连接」而你的池只有 10 个，那你连压测都不用做就知道问题在哪。

③ 采集数据

④ 剖析归因

⑤ 定位根因

⑥ 优化

⑦ 回归验证

⑧ 固化为门禁与监控

三、谁在哪个阶段介入

性能不是一个人的事。下表帮你判断什么时候需要拉谁进来：

四、这个闭环在现实中怎么被打破

三种常见的「断环」方式，以及后果：

注意中间那一条：「跳过剖析直接优化」是最高频的错误。它会让你在错误的地方努力，而且因为确实做了一些「看起来专业」的改动，团队会以为问题已经解决。

五、本节小结

1. 八步闭环：定义目标 → 建立模型 → 采集数据 → 剖析归因 → 定位根因 → 优化 → 回归验证 → 固化为门禁。
2. 它是循环：回归数据成为下一轮基线，监控数据提示目标是否需要调整。
3. 最常被跳过的两步是 ② 建立模型（性价比最高）和 ④⑤ 剖析定位（决定优化是否有效）。
4. 每一步都有明确的产出物；没有产出物的步骤等于没做。

六、自测

1. 一个团队的做法是：上线前用 VU 模型压 10 分钟，看 QPS 达标就发布。请指出他们走完了闭环中的哪几步、跳过了哪几步，以及最可能的后果。
2. 为什么「② 建立模型」被说成性价比最高的一步？请举一个它能帮你省下大量时间的具体例子。
3. 如果你只能说服团队补上闭环中的一步，你会选哪一步？为什么？

1. 走完了 ③（采集数据，但方式有缺陷：闭环模型、无预热说明、单次运行）；可能部分做了 ①（如果有 QPS 目标）。跳过了 ①②的模型估算、④⑤的剖析定位、⑥的针对性优化、⑦的统计回归、⑧的门禁固化。后果：QPS 达标但不知道瓶颈在哪、不知道拐点和余量、生产环境一旦数据量增长或流量突增就会出问题，而且下次还得从头再来一遍。
2. 因为它能在动手之前排除掉大量可能性。例子：先用 Little’s Law 算出「1000 QPS × P99 60 ms = 最坏情况下 60 个并发请求」，而你发现连接池只有 10——那么不用压测就知道瓶颈在连接池排队。省下的是搭环境、写脚本、跑测试、分析数据的几个小时甚至几天。
3. 我会选 ④⑤ 剖析定位。理由：跳过①②只会让数据缺乏解释框架，跳过⑦⑧会让成果退化，但跳过④⑤会直接导致优化错地方——既浪费了工程时间，又因为「做了优化」而掩盖了真正的问题，是最贵的错误。