持续化

本章定位：前七章把一次性能问题解决好了。这一章解决不再退化——用门禁、告警、发布策略和容量规划，把性能从「一次性工作」变成「持续能力」。

前置知识：第 5 章（噪声底线）、第 7 章（优化验证） 预计总时长：约 4 小时（阅读 2.5 小时 + Lab 8 约 1.5 小时） 配套代码：docs/code/08-continuous-performance/

一、本章要回答的七个问题

1. 为什么「上线前压一次」不足以防止性能问题？（第 1 节）
2. CI 里的性能门禁阈值该设多少？为什么不能设成噪声底线？（第 2 节）
3. 全链路压测该在什么时机跑？（第 3 节）
4. 「错误预算」是什么？为什么它比「P99 超标就告警」更好？（第 4 节）
5. 为什么「有烟就报警」的告警会被所有人忽略？该怎么设计？（第 5 节）
6. 流量回放时，写操作怎么处理？（第 6 节）
7. 怎么从压测曲线算出「需要几个副本」？（第 7 节）

二、为什么「一次性优化」必然退化

第 7 章你优化了 55%，P99 从 400 ms 降到 95 ms。然后呢？

第 1 个月：P99 = 95 ms      ✅
第 2 个月：P99 = 102 ms      （新增了一个接口，多了一次序列化）
第 3 个月：P99 = 118 ms      （数据量涨了 30%，某个查询开始变慢）
第 4 个月：P99 = 140 ms      （有人加了 DEBUG 日志）
第 6 个月：P99 = 210 ms      （又一个 N+1）
第 12 个月：P99 = 400 ms     ← 回到起点

每一步都只退化了 3%–15%——都在噪声范围内，没人察觉。这就是渐进退化，也是性能问题最常见的形态。

关键对比

没有本章，前七章的工作会在一年内归零。

三、小节地图

四、本章的产出物

1. 一个 CI 微基准门禁：经噪声验证、不改代码时零误报。
2. 一组生产告警规则：SLO 燃烧率 + 至少三条领先指标告警。
3. 一份金丝雀判定与回滚条件：可自动判定，含具体阈值。
4. 一张容量表：每个数字都能追溯到某次实验。
5. 一份性能评审清单：新功能上线前必须过的检查项。

五、学完本章的验收标准

• 能解释为什么「一次性优化」必然退化，以及门禁如何阻止它。
• 能说出 CI 门禁的三个设计要点（相对比较、宽松阈值、噪声验证）。
• 能解释错误预算与燃烧率告警的设计逻辑。
• 能列出至少三条领先指标告警（饱和度类），并说明为什么它们比延迟告警更早。
• 能让流量回放不污染生产数据（写操作的四种处理方式）。
• 能写出可自动判定的金丝雀回滚条件。
• 能从压测曲线算出副本数，并说明非线性因素。
• 你的门禁在代码不变时零误报。

六、一个提醒：本章的产出物是「机制」而不是「文档」

前七章的产出物是数据和分析；本章的产出物是自动运行的机制：

❌ 「我们有一份性能检查清单」（文档，没人看）
✅ 「CI 里的门禁脚本会在性能退化 15% 时以非零码退出」（机制）

❌ 「我们定义了 SLO」（文档）
✅ 「错误预算燃烧过快时会自动告警，并附排查步骤」（机制）

判断标准：不需要人记得，它自己会运行。 这才叫「持续化」。