综合实战 on Dorkytiger 的小屋

项目设定与埋雷清单

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

9.1 项目设定与埋雷清单

上一节：无　|　下一节：9.2 步骤一：定义目标配套代码：09-capstone/01-project-setup

一句话结论

为了让这个实战有东西可查，你必须故意保留几个已知问题。 一个"什么都对"的服务，练不出定位能力——六颗埋雷是本章最重要的准备。

一、服务设计：短链服务

两个接口

POST /links              创建短链
  body: { "url": "https://example.com/very/long/url" }
  → { "code": "aB3xK9" }

GET /{code}              跳转
  → 302 Location: https://example.com/very/long/url

为什么这两个接口够用：

特征	对应知识点
读多写少（读:写 ≈ 50:1）	缓存策略（第 7.4 节）
热门短链被反复访问	幂律分布（第 5.5 节）
读路径有缓存命中/未命中	缓存对 P99 的影响（第 7.4 节）
写路径有唯一索引冲突	数据库错误处理（第 6.6 节）
代码短（6 位 base62）	可以自然地做"加索引/不加索引"的对比

数据表

CREATE TABLE links (
    id          BIGSERIAL PRIMARY KEY,
    code        TEXT NOT NULL,              -- 短码
    url         TEXT NOT NULL,              -- 原始 URL
    user_id     BIGINT NOT NULL,            -- 创建者（用于热点分析）
    created_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
    hits        BIGINT NOT NULL DEFAULT 0   -- 访问计数（用于写路径演示）
);

-- ⚠️ 注意：故意先不建 code 的唯一索引（见埋雷清单）

二、六颗埋雷（本章的核心准备）

这六个问题对应第 6 章的六个瓶颈模式。请在实现时刻意保留它们，不要提前修。

步骤一：定义目标

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

9.2 步骤一：定义目标

上一节：9.1 项目设定与埋雷清单　|　下一节：9.3 步骤二：搭服务与数据用到：第 1 章（SLO 四要素、延迟预算）配套代码：09-capstone/02-step1-goals 产出：docs/slo.md

一句话结论

这一步决定后面所有工作的方向。 没有 SLO，「优化」就是无的放矢——因为你不知道要优化到多少才算够。

一、要回答的三个问题

问题	为什么必须先答
峰值 QPS 是多少？	决定容量规划与压测强度
用户能接受多慢？	决定 SLO 阈值（不能拍脑袋）
数据会涨到多大？	决定测试数据量与容量规划的时间跨度

如果这三个答不出来：

① 去问业务方（这是产品决策，不是技术决策）
② 或者从现有监控里取真实数据
③ 实在拿不到 → 在 SLO 表里标注「待确认」，并写明打算怎么获取

「待确认」本身就是一个有价值的产出——它暴露了「目前的性能目标没有依据」这个事实。

二、SLO 表（四要素）

<!-- docs/slo.md -->

# SLO 表

> 最后更新：YYYY-MM-DD　|　对应版本：<commit>
> 填写说明：四要素缺一不可。写不出来的标「待确认」，并注明获取方式。

## 接口 1：GET /{code}（跳转）

| 字段 | 值 |
| --- | --- |
| 接口 | `GET /{code}` |
| 关键路径 | 客户端 → 服务 → Redis → PostgreSQL |
| **目标 QPS（峰值）** | 3000 |
| **P50 / P95 / P99 / P999** | 5 / 30 / 100 / 300 ms |
| **错误率阈值** | < 0.1% |
| 超时率阈值 | < 0.05% |
| 负载前提：数据量 | 100 万条 links |
| 负载前提：**数据分布** | **幂律（齐夫，alpha≈1.2）**：前 1% 的 code 承担 40% 访问 |
| 负载前提：缓存状态 | warm（预热 5 分钟） |
| **测量点** | 压测客户端（最接近用户体验） |
| 预热时长 | 60 秒 |
| 稳态时长 | 10 分钟 |
| 验收轮次 | ≥ 3 轮，取中位数 |
| 环境 | 单实例 4C8G；压测客户端独立进程 |
| **崩溃线** | P99 > 1s 或错误率 > 1% 持续 30 秒 |
| 测量日期与版本 | YYYY-MM-DD，commit `abc1234` |

**待确认项**：
- [ ] 峰值 QPS 的真实数据（向业务方确认 / 从监控取值）
- [ ] 数据量的一年增长预期

## 接口 2：POST /links（创建短链）

| 字段 | 值 |
| --- | --- |
| 接口 | `POST /links` |
| 目标 QPS | 60（读:写 ≈ 50:1） |
| P50 / P95 / P99 | 20 / 60 / 150 ms |
| 错误率阈值 | < 0.5%（唯一索引冲突是正常业务，单独统计） |
| 负载前提 | 100 万条已有数据；URL 平均长度 60 字符 |
| 测量点 | 压测客户端 |
| 崩溃线 | P99 > 1s |

注意三处刻意的设计：

步骤二：搭服务与数据

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

9.3 步骤二：搭服务与数据

上一节：9.2 步骤一：定义目标　|　下一节：9.4 步骤三：建立基线与噪声底线用到：第 3 章（组件基准、真实依赖）、第 5.5 节（数据集设计）配套代码：09-capstone/03-step2-build-service 产出：可运行的服务 + 一键起环境脚本 + 100 万行数据

一句话结论

这一步的目标不是"写出好代码"，而是"写出一个能被测量的系统"——它必须有真实的依赖、固定的数据、可观测的指标，以及故意保留的埋雷。

一、服务的四层结构

HTTP 层（Ktor 路由）
  ↓
Service 层（业务逻辑：生成短码、缓存编排）
  ↓
Repository 层（数据访问：PostgreSQL + Redis）
  ↓
基础设施（HikariCP 连接池、Redis 客户端）

每一层对应的埋雷：

层	埋雷	说明
HTTP 层	⑤ 日志同步 IO	每个请求打 INFO 日志
Service 层	⑥ `synchronized` 生成 code	锁 + 可能在协程里
Repository 层	① 无唯一索引、② 每次 UPDATE、④ Default 上 JDBC	数据访问的三个问题
缓存	③ TTL 无抖动	服务层与缓存层交界处

二、一键起环境

# docker-compose.yml
services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: shortlink
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
    ports: ["5432:5432"]
    command:
      - postgres
      - -c max_connections=100
      - -c shared_buffers=256MB
      - -c log_min_duration_statement=200ms     # 慢查询日志（辅助定位）
    volumes:
      - pg-data:/var/lib/postgresql/data
      - ./init.sql:/docker-entrypoint-initdb.d/init.sql:ro
      - ./seed.sql:/docker-entrypoint-initdb.d/seed.sql:ro
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d shortlink"]
      interval: 2s
      timeout: 3s
      retries: 30

  redis:
    image: redis:7-alpine
    ports: ["6379:6379"]
    command: redis-server --maxmemory 512mb --maxmemory-policy allkeys-lru
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 2s

  # 观测栈（第 4 章）
  prometheus:
    image: prom/prometheus:v2.54.1
    ports: ["9090:9090"]
    volumes:
      - ./observability/prometheus.yml:/etc/prometheus/prometheus.yml:ro

  grafana:
    image: grafana/grafana:11.2.0
    ports: ["3000:3000"]
    environment:
      GF_SECURITY_ADMIN_PASSWORD: admin

volumes:
  pg-data:

关键配置：

步骤三：建立基线与噪声底线

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

9.4 步骤三：建立基线与噪声底线

上一节：9.3 步骤二：搭服务与数据　|　下一节：9.5 步骤四：容量曲线与拐点用到：第 4 章（观测）、第 5.7 节（噪声底线）配套代码：09-capstone/04-step3-baseline 产出：experiments/E09-baseline/（基线数据 + 噪声底线）

一句话结论

这一步衡量的是「你的测量工具有多准」。 在测出噪声底线之前，任何"优化了 X%“的说法都是没有依据的——因为你不知道 X% 是不是噪声。

一、三件事，按顺序做

① 观测回路验证（10 分钟）
   → 确认指标、日志、火焰图三条链路都通
        ↓
② 基线测量（30 分钟）
   → 在 SLO 目标负载下跑 3 轮，得到基线数据
        ↓
③ 噪声底线测量（1 小时）
   → 代码不变，重复 10 轮，得到"我的尺子有多准"

顺序不能反：如果观测回路没通，基线数据就是不可信的。

二、① 观测回路验证

#!/usr/bin/env bash
# tools/verify-observability.sh
set -uo pipefail

echo "═══ 观测回路验证 ═══"
echo

# ① 四层指标
echo "① 检查四层指标"
M=$(curl -s --max-time 5 localhost:8080/metrics)
check() { echo "$M" | grep -qE "$1" && echo "   ✅ $2" || echo "   ❌ $2（缺这组）"; }
check "^app_requests_total"            "业务层"
check "^app_request_duration.*bucket"  "延迟层（直方图）"
check "^jvm_memory_used_bytes"         "资源层"
check "^db_pool_pending"               "饱和度层 ⭐"
check "^app_cache_hit_rate"            "缓存命中率"

echo
echo "② 检查桶边界（应该在 100ms 附近加密）"
echo "$M" | grep 'app_request_duration_seconds_bucket' | grep -oE 'le="[0-9.]+"' | head -12 | sed 's/^/   /'

echo
echo "③ 检查指标基数（应该是个位数）"
echo "   序列数: $(echo "$M" | grep -c 'app_request_duration_seconds_bucket')"

echo
echo "④ 检查火焰图能采到"
PID=$(jcmd 2>/dev/null | grep app.jar | awk '{print $1}')
if [ -n "$PID" ]; then
  TMP=$(mktemp)
  asprof -d 5 -e cpu -o collapsed -f "$TMP" "$PID" > /dev/null 2>&1
  LINES=$(wc -l < "$TMP")
  [ "$LINES" -gt 10 ] && echo "   ✅ 火焰图有 $LINES 条栈（压测中采集会更多）" \
                       || echo "   ⚠️  只有 $LINES 条栈（可能没在压测，或权限问题）"
  rm -f "$TMP"
else
  echo "   ⚠️  未找到应用进程"
fi

echo
echo "⑤ 检查 Prometheus 抓取"
curl -sf http://localhost:9090/-/ready > /dev/null && echo "   ✅ Prometheus 就绪" \
                                                   || echo "   ⚠️  Prometheus 未就绪"

关键检查：db_pool_pending 与 app_cache_hit_rate——这两个是后面定位的关键指标，如果没有，后面的分析会缺一大块。

步骤四：容量曲线与拐点

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

9.5 步骤四：容量曲线与拐点

上一节：9.4 步骤三：建立基线与噪声底线　|　下一节：9.6 步骤五：剖析定位用到：第 1.6 节（容量曲线）、第 3.4 节（阶梯加压）配套代码：09-capstone/05-step4-capacity-curve 产出：experiments/E10-capacity/（曲线 + 拐点）

一句话结论

「CPU 打满时的 QPS」不是容量，「延迟开始非线性上升的那个点」才是。 而且在埋雷服务上，拐点会低得惊人——这正是埋雷的价值：让你亲眼看到「一个缺失的索引如何把容量砍掉一半」。

一、阶梯加压设计

// loadtest/capacity-staircase.js
export const options = {
  scenarios: {
    staircase: {
      executor: 'ramping-arrival-rate',
      startRate: 100,
      timeUnit: '1s',
      preAllocatedVUs: 1000,          // ⚠️ 必须给够，否则实际到达率低于设定值
      maxVUs: 5000,
      stages: [
        { target: 200,  duration: '30s' }, { target: 200,  duration: '2m' },
        { target: 400,  duration: '30s' }, { target: 400,  duration: '2m' },
        { target: 700,  duration: '30s' }, { target: 700,  duration: '2m' },
        { target: 1000, duration: '30s' }, { target: 1000, duration: '2m' },
        { target: 1500, duration: '30s' }, { target: 1500, duration: '2m' },
        { target: 2000, duration: '30s' }, { target: 2000, duration: '2m' },
      ],
      // 每级：爬升 30s + 稳态 2m（⚠️ 稳态窗口才是采数据的区间）
    },
  },
  // 故意不设 thresholds：容量测试的目的是找拐点，不是判定通过/失败
  discardResponseBodies: true,
};

关键设计（第 3.4 节）：

步骤五：剖析定位

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

9.6 步骤五：剖析定位

上一节：9.5 步骤四：容量曲线与拐点　|　下一节：9.7 步骤六：优化与验证用到：第 6 章（五步法、延迟分解、火焰图、瓶颈模式库）配套代码：09-capstone/06-step5-diagnose 产出：bottlenecks.md（瓶颈清单：证据链 + 贡献占比 + 被排除的假设）

一句话结论

在拐点负载下剖析（不是在低负载下）——因为低负载时一切都很健康，看不出问题。这一步的产出是一份能被人追问的瓶颈清单。

一、五步法在埋雷服务上的应用

① 现象量化 → 已有（步骤三、四的数据）
② 分层拆解 → 找出哪一段占大头
③ 提出假设 → 六颗埋雷对应六个假设
④ 设计验证 → 每条假设一条可证伪的命令
⑤ 得出结论 → 证据链 + 贡献占比 + 被排除的假设

第 ① 步已经在步骤三、四做完了——这正是前面步骤的价值：你不用再从头量化。

二、② 分层拆解：找出大头

# 在拐点负载（约 700 RPS）下测量
tools/decompose-at-knee.sh E11-diagnosis

#!/usr/bin/env bash
# tools/decompose-at-knee.sh <EXP_ID>
set -uo pipefail

EXP_ID="${1:?usage: decompose-at-knee.sh <exp_id>}"
DIR="docs/experiments/${EXP_ID}"
mkdir -p "$DIR/results"

# ⚠️ 关键：在【拐点负载】下剖析，不是在低负载下
KNEE_QPS="${KNEE_QPS:-700}"

scripts/restart-app.sh "$DIR/results/gc.log"
sleep 5
BASE_URL=http://127.0.0.1:8080 k6 run --quiet --vus 20 --duration 60s loadtest/read-path.js > /dev/null

# 后台施压（持续整个剖析过程）
BASE_URL=http://127.0.0.1:8080 RATE="$KNEE_QPS" DURATION=5m \
k6 run --summary-export="$DIR/results/k6-knee.json" loadtest/read-path.js > /dev/null 2>&1 &
K6_PID=$!
sleep 40    # 等进入稳态

PID=$(jcmd | grep app.jar | awk '{print $1}')

echo "═══ 在 ${KNEE_QPS} RPS 下采集证据 ═══"
echo

# ① 四类火焰图
echo "① 火焰图"
for E in cpu wall alloc lock; do
  asprof -d 20 -e "$E" -f "$DIR/results/$E.html" "$PID" > /dev/null 2>&1
  asprof -d 20 -e "$E" -o collapsed -f "$DIR/results/$E.collapsed" "$PID" > /dev/null 2>&1
  echo "   $E.html / $E.collapsed"
done
echo

# ② 线程快照（连续 3 份）
echo "② 线程快照"
mkdir -p "$DIR/results/threads"
for i in 1 2 3; do
  jcmd "$PID" Thread.print > "$DIR/results/threads/threads-$i.txt"
  sleep 3
done
python3 tools/analyze-threads.py "$DIR/results/threads"/threads-*.txt \
  > "$DIR/results/threads/analysis.txt"
echo "   分析已生成"
echo

# ③ 指标快照
curl -s localhost:8080/metrics > "$DIR/results/metrics.txt"

# ④ 数据库侧
echo "③ 数据库诊断"
psql "${PG_CONN:-postgresql://app:app@localhost:5432/shortlink}" > "$DIR/results/pg-diagnostics.txt" 2>&1 <<'SQL'
-- 最贵的语句（看 calls 与 mean）
SELECT calls, round(mean_exec_time::numeric,2) AS mean_ms,
       round(total_exec_time::numeric,0) AS total_ms,
       left(regexp_replace(query,'\s+',' ','g'), 50) AS query
FROM pg_stat_statements
WHERE query NOT LIKE '%pg_stat_statements%'
ORDER BY total_exec_time DESC LIMIT 10;

-- 当前活跃查询与等待
SELECT pid, round(extract(epoch from (now()-query_start))::numeric,1) AS dur_s,
       state, wait_event_type, wait_event, left(query,50)
FROM pg_stat_activity WHERE state <> 'idle' AND pid <> pg_backend_pid()
ORDER BY dur_s DESC NULLS LAST LIMIT 10;
SQL
echo "   已保存到 pg-diagnostics.txt"

wait $K6_PID 2>/dev/null || true

echo
echo "═══ 关键证据摘要 ═══"
echo
echo "── 数据库最贵的语句 ──"
head -8 "$DIR/results/pg-diagnostics.txt" | tail -6

echo
echo "── 火焰图热点（自身耗时 Top 5）──"
for E in cpu wall; do
  echo "[$E]"
  python3 tools/analyze-flamegraph.py "$DIR/results/$E.collapsed" 2>/dev/null \
    | grep -A6 "自身耗时 Top" | tail -5 | sed 's/^/  /'
done

echo
echo "── 线程分析关键结论 ──"
grep -E "BLOCKED|持续|⚠️|❌" "$DIR/results/threads/analysis.txt" 2>/dev/null | head -6 | sed 's/^/  /'

echo
echo "✅ 证据已采集 → $DIR/results"

三、预期发现：六颗埋雷的证据

埋雷	预期证据	在哪份数据里
① 无索引	`pg_stat_statements` 里 `SELECT ... WHERE code = ?` 的 mean 高；`EXPLAIN` 显示 `Seq Scan`	`pg-diagnostics.txt`
② 每次 UPDATE	`lock` 火焰图有内容；`pg_stat_activity` 有 `wait_event_type=Lock`	`lock.collapsed`
③ TTL 无抖动	缓存命中率曲线有周期性下凹	需要额外采集
④ Default 上 JDBC	`cpu` 火焰图很空，`wall` 火焰图全是阻塞栈	`cpu.collapsed` vs `wall.collapsed`
⑤ 日志同步 IO	`sys` CPU 偏高；火焰图有文件写栈	`cpu.collapsed`
⑥ `synchronized`	线程 dump 有 `BLOCKED`	`threads/analysis.txt`

埋雷 ④ 的证据（最重要的教学点）

cpu.collapsed  → 很空（几乎没有采样）
wall.collapsed → 大量栈停在 socketRead0 / JDBC 调用

这个对比就是第 6.3 节的核心：
「只采 CPU 火焰图会得出『没有瓶颈』的错误结论」

验证：

步骤六：优化与验证

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

9.7 步骤六：优化与验证

上一节：9.6 步骤五：剖析定位　|　下一节：9.8 步骤七：长稳与回归用到：第 7 章（优先级金字塔、三问纪律、否决记录）配套代码：09-capstone/07-step6-optimize 产出：OPTIMIZATION.md（优化收益报告）

一句话结论

按优先级金字塔从下往上改，一次只改一处，每处都回答三个问题。 而且——你至少要主动否决一项优化，否则说明你没有真的评估过备选方案。

一、优化的优先级排序

用第 7.1 节的金字塔对六个瓶颈排序：

瓶颈	金字塔层级	预期收益	成本	排序
① 缺索引	② 算法与数据访问	90%	极低（一条 SQL）	1
④ Default 上 JDBC	③ 架构与并发	6%（但对全局卡顿 100%）	低（几行代码）	2
② UPDATE hits	② 算法与数据访问	2.4%	中（要改数据模型）	3
⑤ 日志同步 IO	⑤ 微观常数	1.2%	极低（降级别）	4
⑥ `synchronized`	③ 架构与并发	写路径为主	低	5
③ 缓存 TTL 无抖动	④ 缓存	周期性尖刺	低	6

注意排序结果：前两名来自 ② 和 ③ 层（算法/架构），后四名收益都在个位数——这正是金字塔的体现。

步骤七：长稳与回归

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

9.8 步骤七：长稳与回归

上一节：9.7 步骤六：优化与验证　|　下一节：9.9 步骤八：固化门禁与交付报告用到：第 3.5 节（浸泡测试）、第 7.8 节（回归验证）配套代码：09-capstone/08-step7-soak-and-regression 产出：experiments/E13-soak/（长稳数据）+ 回归确认

一句话结论

短跑发现不了的问题，长跑才能发现。 而且这一步还要回答一个问题：我优化了 A，会不会让 B 变慢了？

一、为什么要做这一步

前六步做的都是"短跑"（3–5 分钟的压测）。短跑发现不了：

问题类型	为什么短跑发现不了
内存泄漏	每小时涨 30 MB，5 分钟只涨 2.5 MB（在噪声内）
连接泄漏	每次异常路径漏一个连接，需要累积才显现
文件描述符泄漏	同上
缓存无界增长	需要长时间才能填满
长周期 GC 问题	老年代回收可能需要几十分钟才一次
缓存 TTL 无抖动的影响	TTL 是 10 分钟——短跑看不到它失效

注意最后一条：埋雷 ③（缓存 TTL 无抖动）只有在这一步才能被观察到。

二、浸泡测试设计

tools/run-soak.sh E13-soak 1h

关键参数：

参数	值	理由
时长	1 小时（最低要求）	覆盖缓存 TTL（10 分钟）× 6 轮、老年代 GC 周期
负载	目标容量的 60%–80%	不要用满负载（排队会掩盖泄漏信号）
模型	恒定到达率	不要做阶梯
采样间隔	30 秒	太稀会漏掉趋势，太密产生大量数据

为什么负载用 60%–80% 而不是满负载：

步骤八：固化门禁与交付报告

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

9.9 步骤八：固化门禁与交付报告

上一节：9.8 步骤七：长稳与回归　|　下一节：9.10 Lab 9：总编排用到：第 8 章（门禁、告警、容量规划）、第 6.8 节（结论写法）配套代码：09-capstone/09-step8-gate-and-report 产出：门禁 + 告警 + 容量表 + PERF-REPORT.md（最终交付物）

一句话结论

前七步产出了数据和分析；这一步把它们变成"机制"和"一份能被决策的报告"。 判断标准是：不需要人记得，它自己会运行；以及报告能被非性能工程师用于决策。

一、要交付的五样东西

#	交付物	来自	判断标准
1	CI 微基准门禁	第 8.2 节	代码不变时零误报
2	生产告警规则	第 8.5 节	每条都有 runbook、含领先指标
3	容量表	第 8.7 节	每个数字能追溯到实验
4	性能报告	第 6.8 节	能被非性能工程师用于决策
5	回归基线	本步骤	优化后的版本成为新基线

二、① CI 微基准门禁

复用第 8 章的流程，但只保留与本项目相关的基准：

// src/main/kotlin/bench/ShortlinkBenchmark.kt
@State(Scope.Benchmark)
class ShortlinkBenchmark {
    private val base62 = Base62Codec()

    @Benchmark
    fun generateCode(bh: Blackhole) {
        bh.consume(base62.encode(Random.nextLong(1, 62L.pow(6))))
    }

    @Benchmark
    fun encodeUrl(bh: Blackhole) {
        bh.consume(base62.encode(Random.nextLong()))
    }
}

// 序列化基准（短链的响应体很小，但仍值得测）
@State(Scope.Benchmark)
class SerializationBenchmark {
    private val format = Json
    private lateinit var response: CreateLinkResponse

    @Setup
    fun setup() {
        response = CreateLinkResponse(code = "aB3xK9")
    }

    @Benchmark
    fun encode(bh: Blackhole) {
        bh.consume(format.encodeToString(response))
    }
}

门禁配置（沿用第 8 章的脚本，阈值用实测的 CI 噪声底线）：

Lab 9：总编排

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

9.10 Lab 9：总编排

上一节：9.9 步骤八：固化门禁与交付报告　|　下一节：无（全书结束）配套代码：09-capstone/README 预计时长：3–5 天（分为 8 次，每次 2–6 小时）

一、这个 Lab 的定位

它不是"一个新的练习"，而是把前八章的 Lab 串成一条线：

本 Lab 的步骤	复用了哪个 Lab
步骤一（定义目标）	Lab 1
步骤二（搭服务）	Lab 3（组件基准的环境）
步骤三（基线）	Lab 4（观测回路）+ Lab 5（噪声底线）
步骤四（容量曲线）	Lab 3（阶梯加压）
步骤五（剖析定位）	Lab 6（埋雷定位）
步骤六（优化验证）	Lab 7（优化与三问）
步骤七（长稳回归）	Lab 3（浸泡）+ Lab 5（回归）
步骤八（门禁报告）	Lab 8（门禁）+ Lab 2（基准）

如果你做过前八个 Lab，这里你会很熟悉——区别是：这次要在一个完整的、有真实依赖的服务上做。

二、八次实施安排

第 1 次：立项与搭环境（4 小时）

## 目标
跑通「服务 + 依赖 + 观测」三件套

## 任务
- [ ] 实现两个接口（POST /links、GET /{code}）
- [ ] `docker compose up -d` 起 PostgreSQL + Redis
- [ ] 灌入 100 万行数据（幂律分布）+ `ANALYZE`
- [ ] 埋四层指标（确认 `/metrics` 有四组）
- [ ] **确认六颗埋雷都存在**（`verify-traps.sh`）

## 产出
- 可运行的服务
- `docs/experiments/E09-baseline/results/env.txt`

## 验收
- [ ] `curl localhost:8080/metrics | grep db_pool_pending` 有输出
- [ ] `verify-traps.sh` 显示六颗埋雷全部生效
- [ ] 手工验证两个接口功能正常

提示：这一步最容易卡在埋点——如果指标埋错了，后面所有分析都缺一块。宁可多花 1 小时确认四层指标齐全。