8.3 全链路性能门禁

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

数据集要求：
  ① 数据量固定（每次跑之前重置到同一状态）
  ② 分布固定（用同一份幂律分布的数据）
  ③ 缓存状态固定（每次清空或预热到同一程度）
  ④ 写操作有隔离（避免数据累积导致每次不一样）

❌ 第 1 次跑：100 万行 → P99 = 95ms
   第 2 次跑：130 万行（上次压测写的）→ P99 = 120ms
   → 你以为是代码退化，其实是数据涨了

#!/usr/bin/env bash
# tools/e2e-perf-gate.sh <VERSION_TAG>
#
# 全链路性能门禁：发布候选阶段运行。
set -euo pipefail

VERSION="${1:?usage: e2e-perf-gate.sh <version_tag>}"
EXP_DIR="docs/experiments/gate-${VERSION}"
mkdir -p "$EXP_DIR/results"

echo "═══ 全链路性能门禁：$VERSION ═══"
echo

# ① 环境检查（必须通过）
echo "【1/6】环境检查"
tools/check-environment.sh "gate-${VERSION}"
if grep -q "❌" "$EXP_DIR/results/env-check.txt"; then
  echo "❌ 环境检查未通过 —— 本次门禁结果不可信，终止"
  exit 1
fi
echo

# ② 重置数据集（保证每次一致）
echo "【2/6】重置数据集"
scripts/reset-dataset.sh
scripts/restart-app.sh "$EXP_DIR/results/gc.log"
sleep 10
echo

# ③ 预热（不计入统计）
echo "【3/6】预热 60 秒"
BASE_URL="$TARGET_URL" k6 run --quiet --vus 20 --duration 60s \
  loadtest/profile-constant.js > /dev/null
echo

# ④ 正式测量（跑 3 轮，取中位数）
echo "【4/6】测量 3 轮"
for i in 1 2 3; do
  BASE_URL="$TARGET_URL" RATE=500 DURATION=5m \
  k6 run --summary-export="$EXP_DIR/results/round-$i.json" \
         loadtest/profile-constant.js > /dev/null
  echo "  第 $i 轮完成"
done
echo

# ⑤ 与基线对比
echo "【5/6】与基线对比"
python3 tools/compare_e2e.py "$EXP_DIR/results" perf/e2e-baseline.json
RESULT=$?
echo

# ⑥ 输出结论
echo "【6/6】结论"
if [ $RESULT -eq 0 ]; then
  echo "✅ 性能门禁通过"
  echo
  echo "后续："
  echo "  ① 把本次结果存为新的候选基线"
  echo "  ② 继续发布流程"
else
  echo "❌ 性能门禁失败"
  echo
  echo "后续："
  echo "  ① 查看 $EXP_DIR/results/ 下的详细数据"
  echo "  ② 判断是真退化还是噪声（第 8.2 节的排查流程）"
  echo "  ③ 【不要】在未验证的情况下更新基线"
  exit 1
fi

❌ 只看 SLO：P99 = 190ms < 200ms ✅ 通过
   但连接池 pending 从基线的 0 涨到了 8
   → 系统已经在排队，只是还没反映到延迟上
   → 一旦流量再涨 10%，就会崩

✅ 同时看饱和度：pending > 0 → 拒绝通过（或标记为警告）

门禁失败
    │
    ├─ ① 检查是不是环境问题
    │      ├─ 环境检查有没有 ❌？
    │      ├─ 数据集是否重置成功？
    │      └─ 是否在预期的时间窗口内跑（避开备份等）？
    │
    ├─ ② 判断幅度
    │      ├─ P99 变化 < 噪声底线 → 可能是噪声，重跑 1 次
    │      ├─ P99 变化 1~2 倍噪声 → 需要查清（用第 6 章的方法定位）
    │      └─ P99 变化 > 2 倍噪声 → 高度怀疑真退化
    │
    ├─ ③ 定位（用第 6 章的分析流程）
    │      ├─ 延迟分解：哪一段变慢了？
    │      ├─ 依赖指标：是数据库/缓存/下游？
    │      └─ 火焰图：有没有新的热点？
    │
    └─ ④ 决策
           ├─ 真退化 → 阻塞发布，修复后重跑
           ├─ 预期变化（如新增功能带来合理开销）→ 更新基线（单独提交 + 说明）
           └─ 环境噪声 → 重跑；记录到误报日志

❌ 不要做：在开发机/共享 CI 上跑全链路门禁
   → 数据不可信，会不断误报，最终被关闭

✅ 应该做：
   ① 先建微基准门禁（成本低、见效快）
   ② 用「发布前手动压测」代替自动门禁（第 3 章的方法）
      - 每次发布前跑一次
      - 结果记录进实验档案
      - 与上次发布的基线对比
   ③ 等有了专用环境，再把手动流程自动化