持续化 on Dorkytiger 的小屋

为什么需要门禁

Mon, 01 Jan 0001 00:00:00 +0000

8.1 为什么需要门禁

上一节：无　|　下一节：8.2 CI 微基准门禁配套代码：08-continuous-performance/01-why-gates

一句话结论

90% 的性能问题不是「某次大改搞坏了」，而是「几十次小改动各退化 3%，累积起来翻了一倍」。 这种退化逃过所有人工评审（因为每次都在噪声范围内），只有自动化的门禁能发现它。

一、用「慢性病」理解渐进退化

一次急性心梗，你会立刻去医院。但高血压、高血脂、血糖偏高——每年只涨一点，你毫无感觉。

十年后，它们一起导致了严重问题。而如果每年体检 + 指标超阈值就干预，就能避免。

健康管理	性能管理
急性病 → 立刻就医	线上故障 → 立刻排查（第 6 章）
年度体检 + 指标趋势	门禁 + 趋势监控（本章）
血压 > 140 就干预	微基准退化 > 15% 就失败
家庭血压计（日常监测）	生产告警（实时监测）

关键：急性病靠医生，慢性病靠机制。 性能工作的大部分价值在后者。

二、渐进退化的四种典型来源

❶ 新增功能带来的额外工作

v2.3：新增"用户画像"接口，每次请求多查一次数据库
     → 订单接口的 P99 从 95ms 涨到 101ms（+6%）
     → 在噪声范围内，code review 也看不出来

为什么难发现：加一次查询看起来"很合理"，而且只涨 6%。

❷ 数据量增长

v2.3 时：订单表 100 万行，某查询走索引，8ms
v2.8 时：订单表 800 万行，同一个查询因为统计信息/选择性变化
         改走全表扫描，45ms（+460%）

为什么难发现：代码一行没改，是数据让执行计划变了。

CI 微基准门禁

Mon, 01 Jan 0001 00:00:00 +0000

8.2 CI 微基准门禁

上一节：8.1 为什么需要门禁　|　下一节：8.3 全链路性能门禁配套代码：08-continuous-performance/02-ci-benchmark-gate

一句话结论

CI 门禁的三条设计纪律：相对比较（不设绝对阈值）、宽松阈值（高于噪声底线）、先报告后失败。 违反任何一条，门禁都会沦为「重跑一下就过」的噪声源。

一、用「体重秤的警报」理解阈值

你家的体重秤误差是 ±1 kg。你设了一个警报：「体重涨了 0.5 kg 就提醒我」。

结果：警报天天响（因为噪声就有 1 kg），三天后你就把它关掉了。

正确做法：

① 先测出秤的实际误差（±1 kg）
② 警报阈值设成 2 kg（误差的 2 倍）
③ 只有真的涨了 2 kg 才提醒

CI 门禁完全一样：阈值必须高于噪声，否则就会被忽略。

二、三条设计纪律

纪律一：相对比较，不设绝对阈值

# ❌ 绝对阈值：换 runner 型号就全线失败
- name: Check performance
  run: |
    SCORE=$(read_score)
    if [ "$SCORE" -lt 16000 ]; then exit 1; fi   # 硬编码数字

# ✅ 相对比较：与仓库中的基线比
- name: Compare against baseline
  run: python3 tools/compare_benchmark.py current.json perf/baseline.json --threshold 0.15

为什么：CI runner 的型号、负载、邻居会变化，绝对阈值意味着每次换环境都要重调，而且调的过程中会放松阈值（最终变成形式主义）。

全链路性能门禁

Mon, 01 Jan 0001 00:00:00 +0000

8.3 全链路性能门禁

上一节：8.2 CI 微基准门禁　|　下一节：8.4 生产观测：SLI 与错误预算配套代码：08-continuous-performance/03-e2e-perf-gate

一句话结论

全链路门禁成本高、噪声大，所以它不该出现在每个 PR 上。 正确的定位是：发布前的最后一道验收——用专用环境、固定机器、触发式运行。

一、用「飞机试飞」理解全链路门禁

汽车出厂前会做路试，但不会每装一个零件就上路试一次。路试的时机是：

时机	目的
每个零件装好后	台架试验（对应微基准）
整车装配完成	转鼓试验（对应集成基准）
出厂前	路试（对应全链路门禁）
上市后	用户反馈 + 定期检查（对应生产告警）

全链路门禁的定位就是「出厂前路试」——不是每次都做，但发布前必做。

二、什么时候跑全链路门禁

触发时机	是否合适	理由
每个 PR	❌ 不合适	成本太高（几十分钟），噪声大，会拖慢开发
主干合并后	⚠️ 可以	比 PR 好，但仍是高频
发布候选（RC）	✅ 推荐	发布前的最后一道门
每日夜间	✅ 推荐	与发布解耦，能发现趋势
手动触发	✅ 推荐	用于验证重大改动

推荐组合：

① 主干合并后：跑【微基准门禁】（分钟级）
② 每日夜间：跑【全链路回归】（发现趋势退化）
③ 发布候选：跑【全链路门禁 + 容量复测】（发布前验收）
④ 重大架构改动：手动触发

三、全链路门禁的三个必要条件

条件一：专用环境

不能在共享的 CI runner 上跑全链路压测。

生产观测：SLI 与错误预算

Mon, 01 Jan 0001 00:00:00 +0000

8.4 生产观测：SLI 与错误预算

上一节：8.3 全链路性能门禁　|　下一节：8.5 告警设计：燃烧率与领先指标配套代码：08-continuous-performance/04-production-observability

一句话结论

错误预算（Error Budget）= 性能的「流量套餐」。 如果 SLO 是 99.9%，那么每月有 0.1% 的请求「允许违约」——这个额度用完了，就该停止发布新功能，先修稳定性。

一、用「手机流量套餐」理解错误预算

你每月有 10 GB 流量：

情况	你的行为
用了 3 GB	随便用，不用担心
用了 7 GB	开始留意，但还能用
用了 9.5 GB	关掉视频，只用必要功能
用完了	限速，或者买加量包

错误预算完全一样：

SLO = 99.9%（30 天窗口）
→ 错误预算 = 0.1% 的请求可以违约
→ 按 100 万请求/天算，30 天共 3000 万请求
→ 预算 = 3 万个请求可以失败

用了 1 万（33%）→ 健康，正常发布
用了 2.4 万（80%）→ 警告，谨慎发布
用了 3 万（100%）→ 冻结发布，先修稳定性

关键洞察：错误预算把「性能」变成了一个可以量化管理的资源——而不是一个模糊的「要快、要稳」。

告警设计：燃烧率与领先指标

Mon, 01 Jan 0001 00:00:00 +0000

8.5 告警设计：燃烧率与领先指标

上一节：8.4 生产观测：SLI 与错误预算　|　下一节：8.6 流量回放与金丝雀发布配套代码：08-continuous-performance/05-alerting

一句话结论

告警的目标不是「发现所有异常」，而是「发现值得人介入的异常」。 因此：用燃烧率代替瞬时阈值（避免误报）、用饱和度作为领先指标（更早发现）、每条告警都配 runbook（否则只是制造焦虑）。

一、用「火灾报警」理解告警设计

一栋楼的火灾报警器有两种设计：

设计	结果
有烟就响	做饭、抽烟、蒸汽都会触发 → 所有人把电池拆了
探测烟浓度 + 温升速率	真实火灾才响 → 大家相信它

第二种设计的两个要点：

看"速率"而不是"瞬时值"——浓度上升快才是危险。
多传感器交叉验证——烟 + 温升同时满足才报警。

告警设计完全一样：

❌ P99 > 200ms → 告警       （看瞬时值，天天响）
✅ 燃烧率 > 14.4 → 告警      （看消耗速度 + 双窗口交叉验证）

二、燃烧率告警（错误预算的核心用法）

什么是燃烧率

燃烧率 = 当前错误率 / 允许的错误率

例：SLO = 99.9% → 允许错误率 = 0.1%
    当前错误率 = 1%
    → 燃烧率 = 1% / 0.1% = 10
    → 意味着"照这个速度，30 天的预算 3 天就用完了"

常用的燃烧率阈值

燃烧率	含义	窗口	处理
14.4	2 天烧完 30 天预算	1 小时 + 5 分钟	page（立即叫人）
6	5 天烧完	6 小时 + 30 分钟	ticket（工单）
1	正好用完	3 天	观察

为什么是 14.4：30 天 / (1 小时 / 30 天) ≈ 14.4 × 2——它保证「1 小时内消耗的预算不超过 2%」，同时能在 2 天内耗尽预算时及时报警。

流量回放与金丝雀发布

Mon, 01 Jan 0001 00:00:00 +0000

8.6 流量回放与金丝雀发布

上一节：8.5 告警设计：燃烧率与领先指标　|　下一节：8.7 容量规划配套代码：08-continuous-performance/06-traffic-replay-and-canary

一句话结论

流量回放解决「人造流量不像真实流量」，金丝雀解决「上线后才发现问题」。 两者配合：回放做上线前的验证，金丝雀做上线时的保护。

一、用「彩排」和「矿井金丝雀」理解这两件事

流量回放 = 彩排

话剧正式演出前会彩排：用真实的剧本、真实的走位、真实的灯光。

但有一条铁律：彩排时演员不能真的受伤（道具刀是假的）。对应到后端：回放时不能让写操作污染生产数据。

金丝雀 = 矿井里的金丝雀

旧时矿工会带一只金丝雀下矿。金丝雀对瓦斯更敏感——它先倒下，矿工就知道要撤。

关键：金丝雀是"小范围先试"，而不是"全量上线后观察"。

二、流量回放的四种数据来源

来源	保真度	成本	适用
生产访问日志回放	高（真实分布）	中（要脱敏、要处理写操作）	推荐
生产 trace 回放	高	高（需要 tracing 系统）	大型项目
从生产统计生成（幂律分布）	中	低	快速搭环境
纯人工构造	低	低	❌ 容易失真（第 5.5 节）

为什么推荐访问日志：它天然包含真实的访问分布（幂律热点）、真实的参数、真实的时序。

# 从 PostgreSQL 导出真实的 ID 访问分布
psql -tAc "
SELECT user_id FROM request_log
WHERE created_at > now() - interval '1 day'
ORDER BY random() LIMIT 100000;" > sampled-ids.txt

# 在 k6 里按这个列表取样（保持真实分布）
# const ids = open('./sampled-ids.txt').split('\n');
# const id = ids[Math.floor(Math.random() * ids.length)];

三、写操作怎么处理（最关键的问题）

回放写操作会污染数据，而且会累积（每次回放都写一遍）。

容量规划

Mon, 01 Jan 0001 00:00:00 +0000

8.7 容量规划

上一节：8.6 流量回放与金丝雀发布　|　下一节：8.8 性能评审与组织落地配套代码：08-continuous-performance/07-capacity-planning

一句话结论

容量 = 拐点 × (1 - headroom)，不是「CPU 打满时的 QPS」。 而且容量不是一次测完就固定的——数据量增长、依赖变化、业务形态变化都会移动拐点。

一、用「餐厅订桌」理解容量规划

一家餐厅要决定「今晚准备多少食材」：

依据	问题
按「平均每天 50 桌」备料	❌ 周末 120 桌时不够
按「历史最高 200 桌」备料	❌ 平时浪费严重
按「上座率的临界点」备料	✅ 超过这个点服务质量会崩

「上座率的临界点」就是拐点：

60% 上座率 → 服务员从容，出菜快，翻台正常
80% 上座率 → 开始排队，出菜变慢
95% 上座率 → 厨房崩溃，所有人等很久
100%       → 实际上已经瘫痪（等位的人走了，实际营业额反而下降）

所以备料的目标不是「撑到 100%」，而是「撑到 80% 且留有余量」。

后端完全一样。

二、从拐点到副本数

四步推导

① 压测找拐点
   → 4C8G 单实例在 900 RPS 时 P99 开始非线性上升
   → 拐点 = 900 RPS

② 应用 headroom
   → 安全容量 = 900 × (1 - 0.4) = 540 RPS
   → headroom 通常 30%~50%

③ 按峰值流量计算副本数
   → 峰值 = 3000 RPS
   → 副本数 = ceil(3000 / 540) = 6

④ 加冗余
   → N+1 冗余（坏一台不影响服务）
   → 最终副本数 = 7

headroom 该留多少

依据是排队论（第 0 章 0.5 节）：

性能评审与组织落地

Mon, 01 Jan 0001 00:00:00 +0000

8.8 性能评审与组织落地

上一节：8.7 容量规划　|　下一节：8.9 Lab 8 配套代码：08-continuous-performance/08-review-and-org

一句话结论

技术手段只能解决技术问题，而「性能持续不退化」最终是一个流程问题。 需要三样东西：评审清单（把性能纳入 review）、明确的责任人（谁对整体指标负责）、能被执行的语言（用业务方听得懂的方式讲性能）。

一、用「起飞前检查单」理解评审清单

飞行员起飞前不会凭记忆，而是逐项核对检查单：

为什么用清单	对应性能评审
人会忘（尤其疲惫时）	开发者专注于功能正确性，会忽略性能影响
清单是最低标准	保证没人漏掉关键项
事后可追溯	“这个检查项当时做了吗？”
不依赖个人经验	新人也能按清单执行

航空业的经验：清单化的流程比个人能力更可靠。

二、性能评审清单（新功能上线前）

## 性能评审清单

### 数据访问
- [ ] 这个功能对每个请求增加了多少次 IO / RPC / 序列化？
- [ ] 有没有循环里的数据库调用（N+1）？
- [ ] 新增的查询走索引吗？在数据量增长 10 倍后还快吗？
- [ ] 有没有可以批处理的机会？

### 资源与边界
- [ ] 是否引入了无界的缓存、队列或内存结构？
- [ ] 新增的缓存/队列有淘汰策略吗？有容量上限吗？
- [ ] 是否引入了新的线程/协程池？并行度是多少？
- [ ] 是否引入了新的连接池？它与数据库的 `max_connections` 匹配吗？

### 超时与失败
- [ ] 每个新增的下游调用都有超时吗？
- [ ] 超时是否小于上游给的预算？（逐层递减）
- [ ] 超时后是否正确释放资源？
- [ ] 失败时是快速失败还是排队等待？
- [ ] 失败会不会放大（重试风暴）？重试有次数上限、退避、抖动吗？
- [ ] 这个调用是幂等的吗？（决定能否重试）

### 可观测性
- [ ] 新增的接口有延迟、错误率、饱和度指标吗？
- [ ] 新增的依赖有独立的计时指标吗？
- [ ] 出现问题时能否回答「这个接口的 P99 里，数据库占多少毫秒」？
- [ ] 指标标签里有没有无界维度（用户 ID / URL 全路径）？

### 兼容性与影响
- [ ] 这个改动会不会影响其他接口？（性能回归）
- [ ] 是否改变了共享资源的用量（连接池、线程池、缓存）？
- [ ] 是否需要更新容量规划？
- [ ] 是否需要更新 SLO 或告警规则？

### 验证
- [ ] 做了组件基准或集成基准吗？
- [ ] 关键路径做了性能对比吗？（before/after）
- [ ] 引入新组件时做了长稳（浸泡）验证吗？

注意最后一段：验证是清单的一部分——不是"有空再做"。

Lab 8：做一个不会误报的性能门禁

Mon, 01 Jan 0001 00:00:00 +0000

8.9 Lab 8：做一个不会误报的性能门禁

上一节：8.8 性能评审与组织落地　|　下一节：第 9 章综合实战配套代码：08-continuous-performance/09-lab8 预计时长：90 分钟

一、这个 Lab 的目标

做一个真正可用的性能门禁——它的验收标准只有一条：在代码不变时，连续跑多次零误报。

做完之后你会得到一个数字：在你自己的 CI 环境里，多大的退化才值得失败。 这个数字是门禁能否长期存活的关键。

二、任务清单

#	任务	产出	时长
1	选出 3–5 个核心基准	基准代码	20 min
2	在 CI 环境测噪声底线（跑 10 次）	噪声数据	25 min
3	定阈值 + 写比较脚本	门禁脚本	20 min
4	验证零误报（跑 5 次）	验证记录	15 min
5	写告警规则草案	`alerts.yml`	10 min

三、任务 1：选出核心基准

选择原则：纯计算、无外部依赖、在 CI 环境稳定、退化后果严重。

候选	是否适合 CI	理由
序列化/反序列化	✅	稳定，退化常见
核心算法（排序、匹配、计算）	✅	纯计算
热点工具函数（字符串、集合操作）	✅	影响面广
加解密/哈希	✅	稳定
启动时间（到健康检查通过）	✅	影响滚动发布
构建时间 / 镜像体积	✅	影响开发效率
数据库查询	❌	CI 环境不稳定
HTTP 接口	❌	需要完整环境

建议的基准集合（用一个真实的业务对象）：