余量目标

在关键资源上保 30-50% 余量使流量尖峰不变成宕机。

为什么

跑 95% CPU 的服务有 5% 余量 — 10% 流量尖峰（黑五、病毒帖、下游重试风暴）推到 105%，延迟尖因调度抖振且服务倒。30-50% 余量目标（峰 70% CPU 利用）吸正常尖峰无自动扩缩延迟，并给自动扩缩时间对更大的踢入。这是便宜保险：30% 超配成本是计算账单 30%，但峰时宕机成本（失收入、客户流失、SLA 罚）是 10-100x。陷阱是"省钱"跑 90% — 你省 10% 计算但付下次宕机 100%。按资源（CPU、内存、DB 连接、队列深）设余量并在利用超目标时告警，故你扩在出前。

何时使用

总是。按关键资源设余量目标并在利用超时告警。

如何做

1. 识别关键资源及其限
   - CPU、内存、盘 I/O、网络（每 pod/实例）
   - DB 连接（池限）、DB CPU、DB 存储
   - 队列深（SQS、Kafka）、缓存命中率、缓存内存

2. 按资源设余量目标
   - CPU：峰 70%（30% 余量）正常，50%（50% 余量）峰事件
   - 内存：峰 80%（20% 余量；OOM 比 CPU 节流难）
   - DB 连接：池 70%（30% 突发余量）
   - 队列深：<50% 消费者容量（50% 突发余量）

3. 利用超目标时告警
   - CPU >70% 持续 5m → 警（扩或调查）
   - CPU >85% 持续 2m → page（宕机迫）
   - DB 连接 >80% → page（池耗尽 → 请求失败）

4. 跟踪峰利用非均
   - 均 CPU 40% 看好，但峰 92% → 峰时无余量
   - 按 p95/p99 利用告警非均

5. 流量变后重评余量
   - 新客户翻倍流量 → 流量到前重查余量
   - 季节峰（假日购物）→ 临时把余量目标提到 50%

示例

# 余量目标（按资源）：
resource_targets:
  cpu:        warn: 70%，page: 85%   # 峰 30% 余量
  memory:     warn: 80%，page: 90%   # 20% 余量（OOM 难）
  db_conns:   warn: 70%，page: 80%   # 30% 突发余量
  queue_depth: warn: 50%，page: 75%  # 50% 突发余量

# 告警（Prometheus）：
- alert: CheckoutCPUHigh
  expr: quantile_over_time(0.95, rate(cpu_usage_seconds[5m])) > 0.70
  for: 5m
  labels: { severity: warn }
  annotations:
    summary: "checkout CPU p95 >70% — 余量缩，考虑扩"

- alert: CheckoutCPUCritical
  expr: quantile_over_time(0.95, rate(cpu_usage_seconds[5m])) > 0.85
  for: 2m
  labels: { severity: page }
  annotations:
    summary: "checkout CPU p95 >85% — 宕机迫，立即扩"

# 仪表盘（跟踪峰非均）：
#   checkout CPU：均 40%、p95 72%、p99 91%  ← p99 超目标！
#   → 行动：扩 checkout +2 pod（把 p99 降到约 75%）
#   → 根因：慢下游导致重试 CPU 尖

常见问题

⚠跟踪均非峰 — 均 CPU 40% 看好但峰 92%；按 p95/p99 告警非均。
⚠DB 连接无余量 — 池突发到 100% 且所有请求失败；池保 30% 余量。
⚠跑 90% 省钱 — 你省 10% 计算但付下次宕机 100%；余量是便宜保险。
⚠不调事件的静态余量 — 30% 对正常流量好但黑五需 50%；为已知峰提目标。

最佳实践

✓在关键资源（CPU、内存、DB 连接、队列深）上设 30-50% 余量并在 p95 利用超目标时告警。
✓按峰（p95/p99）利用告警非均；均藏致宕机的尖峰。
✓把余量当便宜保险：30% 超配成本 30% 计算，但峰时宕机失收入 10-100x。
✓为已知峰（黑五、产品发布）在流量到前提余量目标；流量变后重评。