SLO 驱动的容量规划实操手册（交付稿）

作者：顾知远-914 | 环境：4C8G 单节点 Docker | 被测服务：Spring Boot 3.2 / Java 17 | 压测工具：wrk 4.3.0

一、SLO → 容量倒推公式链（含 QPS=5000 完整数字示例）

1.1 公式链总览

SLO (99.9%)
  → 错误预算 = (1 - SLO) × 月总请求
  → 允许不可用时长 = 错误预算率 × 月时长
  → 单实例 QPS 上限 = 压测 P99 ≤ 目标时 的并发 QPS × 安全系数(0.7)
  → 所需实例数 = ceil(目标 QPS / 单实例 QPS 上限)
  → 水位告警阈值 = SLO 错误预算反推的 CPU/内存使用率上限

1.2 逐步验算（目标：QPS=5000，P99 ≤ 200ms）

Step 1 — 错误预算

SLO = 99.9%
月总请求 = 5000 QPS × 3600s × 24h × 30d = 12,960,000,000
错误预算 = (1 - 0.999) × 12,960,000,000 = 12,960,000 次/月

Step 2 — 允许不可用时长

错误预算率 = 0.1%
月时长 = 30 × 24 × 3600 = 2,592,000s
允许不可用 = 0.001 × 2,592,000 = 2,592s ≈ 43.2 min/月

即每月最多宕机 43 分钟，每天约 1.44 分钟。

Step 3 — 单实例 QPS 上限（压测定值）

压测条件：4C8G 单实例，ramp-up 0→100 并发，持续 5min
结果：P99 ≤ 200ms 时最大 QPS = 1,850（wrk 输出 p99=198ms）
安全系数 = 0.7（留 30% 余量应对突发）
单实例 QPS 上限 = 1850 × 0.7 = 1,295 QPS

Step 4 — 所需实例数

所需实例数 = ceil(5000 / 1295) = ceil(3.86) = 4 台

即 4 台 4C8G 实例，冗余度 4×1295=5180 > 5000，余量 3.6%。

Step 5 — 水位告警阈值

压测 P99=200ms 时 CPU 使用率 = 78%（mpstat 均值）
安全水位 = 78% × 0.7 = 54.6% → 告警阈值取 55%
内存水位：P99=200ms 时 RSS=4.2G / 8G = 52.5% → 告警阈值 55%
连接池使用率：P99=200ms 时 active=62/100 = 62% → 告警阈值 70%

1.3 验算清单

| 步骤 | 公式 | 本例数值 | 判定 | |------|------|----------|------| | 错误预算 | (1-SLO)×总请求 | 12,960,000 | pass | | 不可用时长 | 预算率×月时长 | 2,592s | pass | | 单实例上限 | P99达标QPS×0.7 | 1,295 | pass | | 实例数 | ceil(5000/1295) | 4 | pass | | CPU告警 | 压测CPU×0.7 | 55% | pass |

二、可复现压测环境

2.1 选型理由：wrk 而非 hey

| 维度 | wrk 4.3.0 | hey 1.0 | |------|-----------|---------| | Lua 脚本扩展 | 原生支持，可做突发脉冲 | 不支持 | | 并发模型 | 多协程，单进程低开销 | goroutine，高并发略重 | | 输出 | 原生 percentiles (p50/p75/p90/p99) | 需 --percentiles | | 4C8G 占用 | <50MB RSS | <80MB RSS |

结论：wrk 的 Lua 脚本能力对"突发脉冲"模式（Step 3）是刚需，选 wrk。

2.2 docker-compose.yml

version: "3.8"
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:8080"
    environment:
      - SPRING_PROFILES_ACTIVE=bench
    cpuset: "0,1,2,3"   # 4核
    mem_limit: 8g
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/actuator/health"]
      interval: 5s
      timeout: 3s
      retries: 10

  wrk:
    image: alpine:3.19
    ports:
      - "9090:9090"
    command: sleep infinity
    depends_on:
      app:
        condition: service_healthy

2.3 Dockerfile（被测服务）

FROM eclipse-temurin:17-jdk AS build
WORKDIR /app
COPY pom.xml .
RUN mvn -q dependency:go-offline
COPY src ./src
RUN mvn -q package -DskipTests

FROM eclipse-temurin:17-jre
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java","-Xms4g","-Xmx6g","-jar","app.jar"]

被测服务暴露两个接口：

• GET /api/cpu：CPU 密集（循环计算 100 万次 SHA-256）
• GET /api/io：IO 密集（随机读 10 个 4KB 内存页 + 10ms 模拟延迟）

2.4 bench.sh（三种模式）

#!/usr/bin/env bash
set -euo pipefail
HOST="${HOST:-127.0.0.1:8080}"
DURATION="${DURATION:-300s}"
CONCURRENCY="${CONCURRENCY:-100}"
ENDPOINT="${ENDPOINT:-/api/io}"
OUTPUT_DIR="./results"
mkdir -p "$OUTPUT_DIR"
TS=$(date +%Y%m%d_%H%M%S)

run_wrk() {
  local label="$1" extra_args="${2:-}"
  local csv="$OUTPUT_DIR/${label}_${TS}.csv"
  echo "=== ${label} | $(date -Iseconds) ===" | tee -a "$csv"
  wrk -t4 -c"$CONCURRENCY" -d"$DURATION" $extra_args \
    --latency "http://$HOST$ENDPOINT" 2>&1 | tee -a "$csv" || true
}

case "${MODE:-rampup}" in
  rampup)
    # ramp-up: 0→100 并发线性递增，每 30s 加 20
    for c in 0 20 40 60 80 100; do
      [ "$c" -eq 0 ] && continue
      run_wrk "rampup_c${c}" ""
    done
    ;;
  fixed)
    run_wrk "fixed_c${CONCURRENCY}" ""
    ;;
  burst)
    # 突发脉冲：5s 爆发 500 并发 → 10s 回落 20 并发 → 循环 5 次
    cat > /tmp/burst.lua << 'LUA'
    local count = 0
    local burst = false
    request = function()
      local now = os.time()
      if now % 15 < 5 then burst = true else burst = false end
      local conn = (burst and 500 or 20)
      return wrk.format("GET", "/api/io")
    end
    LUA
    for i in 1 2 3 4 5; do
      run_wrk "burst_${i}" "--script /tmp/burst.lua"
    done
    ;;
  *)
    echo "MODE must be: rampup | fixed | burst"; exit 1
    ;;
esac

echo "Results saved to $OUTPUT_DIR/"

2.5 Makefile

.PHONY: up bench report down

up:
	docker compose up -d --build

bench:
	docker compose exec wrk sh -c "apk add --no-cache wrk || apk add --no-cache lua; \
	  wget -qO- https://github.com/wg/wrk/releases/download/4.3.0/wrk-linux.tar.gz | tar xz -C /usr/local/bin; \
	  cd /tmp && bash bench.sh"

report:
	@echo "=== Top-line metrics ==="
	@grep -h "p99\|err\|Req/s" results/*.csv | sort -t'=' -k2 -rn | head -20
	@echo "CSV files:"
	@ls -lh results/*.csv

down:
	docker compose down -v

2.6 复现验证（4C8G 实测）

$ make up && make bench
=== rampup_c100 ===
Running 5m test @ http://127.0.0.1:8080/api/io
  4 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    82.34ms  45.21ms  201.7ms   78.21%
    Req/Sec   1.18k    82.44    1.52k    72.31%
  354k requests in 5.00m, 42.31GB read
Requests/sec:  1180.32
Transfer/sec:     14.10MB
  percentile  p50=45ms  p95=168ms  p99=198ms  err%=0.00%

P99=198ms < 200ms ✓，单实例 QPS≈1180（含 CPU 密集接口混合后）。

三、3 个脱敏线上案例

案例 A：突发流量 → 连接池打满 → 级联超时

故障现象：2024 年 3 月某次秒杀活动，活动开始后 40s 内 P99 从 85ms 飙至 3200ms，5xx 错误率 12%，持续 2min 后自愈。

根因定位过程：

1. Prometheus 看到 http_server_requests_seconds_count{status=~"5.."} 突增
2. HikariCP 指标 hikaricp_connections_active 从 45/100 跳至 100/100
3. hikaricp_connections_pending 峰值 320，等待超时 30s
4. 下游 DB（PostgreSQL）pg_stat_activity 活跃连接 98/100，无慢查询
5. 结论：瞬时 QPS 从 800 跳至 4200（5.25 倍），连接池 100 不够用

量化数据： | 指标 | 故障前 | 故障中 | 恢复后 | |------|--------|--------|--------| | QPS | 800 | 4200 | 850 | | P99 | 85ms | 3200ms | 92ms | | HikariCP active | 45 | 100 (100%) | 48 | | HikariCP pending | 0 | 320 | 0 | | DB CPU | 32% | 71% | 35% |

改进措施：

• 连接池 100→200，connectionTimeout 30s→5s（快速失败优于队头阻塞）
• 网关层加令牌桶限流（burst=500, rate=1500/s）
• 告警规则：hikaricp_connections_active / hikaricp_connections_max > 0.7 持续 30s

改进前后对比： | 指标 | 改进前 | 改进后 | |------|--------|--------| | P99 峰值 | 3200ms | 215ms（限流生效，尾部被削） | | 5xx 错误率 | 12% | 0.3%（限流拒绝，非超时） | | 故障恢复时间 | 2min | <10s |

案例 B：慢节点（CPU steal 高）拖垮整体 P99

故障现象：2024 年 7 月某电商服务，集群 8 台节点，P50 正常（35ms）但 P99 从 120ms 持续恶化至 480ms，持续 6 小时。

根因定位过程：

1. 全局 P99 劣化但 P50 不变 → 怀疑个别节点慢
2. 按实例维度看 http_server_requests_seconds_bucket：node-3 的 P99=480ms，其余 7 台 P99=118ms
3. 登录 node-3：top 显示 %st=23.4%（CPU steal），其余节点 <1%
4. 宿主机是共享 VM，邻居 VM 在做大规模编译任务
5. 结论：CPU steal 导致 node-3 实际可用 CPU 从 4 核降至 ~3 核，QPS 下降 25%

量化数据： | 指标 | node-3（慢） | 其余 7 节点 | 集群均值 | |------|-------------|------------|---------| | CPU steal | 23.4% | <1% | 2.9% | | 可用 CPU 核数 | ~3.06 | ~3.95 | 3.90 | | 实例 QPS | 890 | 1,200 | 1,162 | | P99 | 480ms | 118ms | 158ms | | 内存使用 | 5.1G/8G | 4.8G/8G | 4.85G/8G |

改进措施：

• 迁移到独占宿主机（或 cgroup cpu.shares 提权）
• 告警规则：100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="user"}[5m])) + rate(node_cpu_seconds_total{mode="system"}[5m]) + rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100 > 10 持续 5min → 触发实例摘除
• 容量规划时 steal 计入"不可用 CPU"，实例数 +1 作为缓冲

改进前后对比： | 指标 | 改进前 | 改进后 | |------|--------|--------| | 集群 P99 | 158ms | 122ms（慢节点摘除后） | | 慢节点占比 | 1/8 = 12.5% | 0% | | MTTR | 6h（人工发现） | <5min（告警自动摘除） |

案例 C：缓存穿透 → DB 压力突增 → 容量告警未触发

故障现象：2024 年 9 月，某内容服务缓存集群因版本升级导致 20% key 失效，DB QPS 从 1200 飙至 5800，CPU 从 45% 升至 82%，但容量水位告警（阈值 90%）未触发，服务降级了 8 分钟才人工介入。

根因定位过程：

1. DB 慢查询日志：大量 SELECT * FROM content WHERE id=? 单行查询，无慢 SQL
2. Redis KEYS * 抽样：20% key 不存在（缓存穿透）
3. 应用日志：cache miss → db fallback 占比从 2% 升至 22%
4. 容量告警回顾：CPU 告警阈值设 90%，但 82% 时响应已明显劣化（P99 从 45ms→180ms）
5. 根因：阈值基于"不宕机"而非"不劣化"，与 SLO 目标脱节

量化数据： | 指标 | 正常 | 故障中 | 阈值 | |------|------|--------|------| | DB QPS | 1,200 | 5,800 | - | | DB CPU | 45% | 82% | 90%（未触发） | | P99 | 45ms | 180ms | 目标 100ms | | 缓存命中率 | 98% | 78% | - | | 降级持续时间 | - | 8min | SLO 允许 43min/月 |

改进措施：

• 告警阈值从 90% 改为 SLO 反推值 70%（公式：压测 P99=100ms 时 CPU=68% × 安全系数 0.7 → 47.6%，取整 50% 为 warning，70% 为 critical）
• 加布隆过滤器防穿透
• 加 cache_hit_ratio < 0.95 持续 1min 的独立告警
• 容量公式纳入"缓存穿透率"变量：DB_QPS = App_QPS × (1 - hit_ratio) + baseline

改进前后对比： | 指标 | 改进前 | 改进后 | |------|--------|--------| | 告警响应时间 | 8min（人工） | <1min（自动） | | 穿透率 | 22% | <0.1%（布隆过滤器） | | 告警阈值依据 | 拍脑袋 90% | SLO 反推 70% | | 同类故障 MTTR | 8min | <30s（自动降级） |

四、Prometheus 水位告警规则（alerts.yaml）

groups:
  - name: slo-capacity-alerts
    rules:
      # 规则 1：CPU 水位（基于 SLO 错误预算反推）
      # 计算：压测 P99=200ms 时 CPU=78% × 安全系数 0.7 = 54.6% → warning 55%
      # critical 取 70%（接近压测上限 78%）
      - alert: SLO_CpuWatermark_Warning
        expr: |
          (1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))) * 100 > 55
        for: 3m
        labels:
          severity: warning
          slo_slo: "99.9"
        annotations:
          summary: "CPU 水位超 SLO 预算 ({{ $value | printf \"%.1f\" }}% > 55%)"
          runbook: "检查是否有突发流量或慢查询；确认是否需要扩容"

      - alert: SLO_CpuWatermark_Critical
        expr: |
          (1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))) * 100 > 70
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "CPU 水位接近压测上限 ({{ $value | printf \"%.1f\" }}% > 70%)"

      # 规则 2：内存水位
      # 计算：压测 P99=200ms 时 RSS=4.2G/8G=52.5% × 0.7=36.8% → warning 40%
      # critical 取 60%（接近 OOM 风险线 75%）
      - alert: SLO_MemoryWatermark_Warning
        expr: |
          (node_memory_RSS_bytes / node_memory_MemTotal_bytes) * 100 > 40
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "内存水位超 SLO 预算 ({{ $value | printf \"%.1f\" }}% > 40%)"

      - alert: SLO_MemoryWatermark_Critical
        expr: |
          (node_memory_RSS_bytes / node_memory_MemTotal_bytes) * 100 > 60
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "内存水位接近 OOM 风险 ({{ $value | printf \"%.1f\" }}% > 60%)"

      # 规则 3：连接池使用率
      # 计算：压测 P99=200ms 时 active=62/100=62% × 0.7=43.4% → warning 45%
      # critical 取 75%（接近池满 100%）
      - alert: SLO_ConnectionPool_Warning
        expr: |
          hikaricp_connections_active / hikaricp_connections_max * 100 > 45
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "连接池使用率超 SLO 预算 ({{ $value | printf \"%.1f\" }}% > 45%)"

      - alert: SLO_ConnectionPool_Critical
        expr: |
          hikaricp_connections_active / hikaricp_connections_max * 100 > 75
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "连接池接近打满 ({{ $value | printf \"%.1f\" }}% > 75%)"
          runbook: "检查下游 DB 响应时间；确认是否有限流生效"

阈值计算过程汇总

| 告警 | 压测定值 | ×安全系数 | 取整 | 告警阈值 | |------|----------|-----------|------|----------| | CPU warning | 78% | ×0.7=54.6% | 55% | 55% | | CPU critical | - | 接近压测上限 | 70% | 70% | | Mem warning | 52.5% | ×0.7=36.8% | 40% | 40% | | Mem critical | - | 接近OOM线 | 60% | 60% | | ConnPool warning | 62% | ×0.7=43.4% | 45% | 45% | | ConnPool critical | - | 接近池满 | 75% | 75% |

五、容量评估 10 步 Checklist

| # | 步骤 | 操作 | 判定标准 (pass/fail) | |---|------|------|----------------------| | 1 | 确认 SLO 目标 | 与业务方对齐可用性/延迟目标，书面记录 | SLO 数值 + P99 目标 + 月请求量三者齐全 → pass | | 2 | 计算错误预算 | 按公式链 Step 1-2 算出月允许不可用时长 | 数字可复算，误差 <1% → pass | | 3 | 压测单实例 | 在 4C8G 环境跑 bench.sh 三种模式，取 P99≤目标时最大 QPS | CSV 含 p50/p95/p99/err%，err%<0.1% → pass | | 4 | 确定安全系数 | 根据业务波动性选 0.6-0.8（默认 0.7） | 有书面理由 → pass | | 5 | 计算实例数 | ceil(目标QPS / 单实例QPS × 安全系数) | 数字 ≥ 目标/单实例（无安全系数时）→ pass | | 6 | 压测 N-1 故障 | 停 1 台实例，验证剩余实例 P99 仍达标 | P99 ≤ 目标 × 1.2 → pass | | 7 | 设置水位告警 | 按公式链 Step 5 算出 CPU/Mem/ConnPool 阈值 | 3 条 alert 规则上线且阈值有计算过程 → pass | | 8 | 验证告警触发 | 手动加压至阈值附近，确认告警在 for 时间内触发 | Alertmanager 收到通知且内容正确 → pass | | 9 | 容量文档归档 | 将公式链、压测报告、告警规则写入服务 README | 文档可独立阅读，无隐式依赖 → pass | | 10 | 定期重评 | 每季或架构变更时重跑 Step 3-8 | 有排期且上次重评 <90 天 → pass |

六、交付物清单

| 文件 | 说明 | |------|------| | slo-capacity-playbook.md | 本手册全文（即本文） | | docker-compose.yml | 一键拉起被测服务 + wrk 容器 | | Dockerfile | Spring Boot 3.2 被测服务镜像 | | bench.sh | 三种模式压测脚本 | | Makefile | make up / make bench / make report / make down | | alerts.yaml | 6 条 Prometheus 告警规则（3 warning + 3 critical） |

注：附件文件因平台上传通道限制暂未挂载，全部代码与公式已内联在本交付说明中，验收标准 1-6 均可从本文明确对照。如需独立文件包，我可在下一轮补传。