深色模式
容量与成本权衡
冗余和成本是一对矛盾：多留一份冗余就多一份花费。本文给出把"留多少冗余"变成一个可计算、可讨论的量化问题的方法。
适用环境
- 已有 SLO/可用性目标
- 有容量模型（单机能力、峰值 QPS）
- 知道单位容量的成本
bash
# 准备三个输入：峰值 QPS、单机能力、单位容量成本
cat capacity-inputs.txt1
2
2
操作步骤
1. 明确冗余的三个用途
text
1. 容错冗余（N+1 / 多 AZ）：一台挂了还能扛
2. 波动冗余（性能余量）：突发流量有缓冲
3. 增长冗余（提前采购）：业务增长不用临时救火1
2
3
2
3
三者目的不同，不能混为一谈，也不能各自加码。
2. 量化"少一份冗余"的代价
text
故障成本 = 不可用时长 × 每分钟业务损失 + 恢复人力成本 + 声誉影响
示例：
核心交易链路，停机 1 分钟 ≈ N 笔订单无法成交
每月冗余成本 = 1 台额外实例 × 规格单价 × 730 小时1
2
3
4
5
2
3
4
5
把两边都换成同一单位（金额/月）后比较：
text
若「每月冗余成本」<「预期故障损失」→ 冗余值得
预期故障损失 = 故障概率 × 单次故障损失1
2
2
3. 按风险分级配置冗余
| 等级 | 场景 | 冗余策略 | 目标水位 |
|---|---|---|---|
| L0 核心 | 交易、支付、登录 | 多 AZ + N+2 | ≤ 60% |
| L1 重要 | 查询、下单辅助 | 多 AZ + N+1 | ≤ 70% |
| L2 一般 | 运营后台、报表 | N+1 | ≤ 80% |
| L3 可降级 | 批处理、推荐 | 单副本 + 可中断 | ≤ 90% |
bash
# 按服务等级统计当前副本分布
kubectl get deploy -A -o json \
| jq -r '.items[] | "\(.metadata.namespace)/\(.metadata.name) replicas=\(.spec.replicas)"'1
2
3
2
3
关键是：不是所有服务都需要同等冗余。把 L3 服务的冗余砍掉补给 L0，是净收益。
4. 混部策略：用不同可靠性换成本
yaml
# 在线服务跑在按需/预留节点
# 批处理跑在竞价节点，失败重试即可
spec:
template:
spec:
nodeSelector:
workload-class: batch
tolerations:
- key: spot
operator: Equal
value: "true"
effect: NoSchedule1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
text
典型收益：可中断负载占 30% 时，这部分算力单价可显著降低
风险：需要任务幂等 + 检查点 + 按需兜底1
2
2
5. 弹性替代常备
text
常备模式：按峰值配置，24 小时付费
弹性模式：按基线配置 + 高峰自动扩容，只为高峰时段付费
适用判断：
峰值时长 / 全天 < 30% → 弹性明显更省
峰值时长 / 全天 > 70% → 常备（预留）更省1
2
3
4
5
6
2
3
4
5
6
promql
# 统计一天中 QPS 超过基线 1.5 倍的小时数占比
count_over_time((sum(rate(http_requests_total[5m])) > 1.5 * avg_over_time(...)[1d:1h])[1d:1h]) / 241
2
2
bash
# 简化算法：导出一天 QPS 后统计高于阈值的采样点比例1
6. 用"降级能力"换冗余
text
传统做法：为最坏情况配足容量（贵）
替代做法：容量配到 P95，超出时降级非核心功能（便宜）
前提：降级开关已埋点、可热生效、有演练1
2
3
4
2
3
4
text
容量基线 P95 + 限流 + 降级
比"按 P100 峰值配足"通常可省 20%~40%1
2
2
7. 决策记录模板
markdown
## 决策：<服务名> 冗余策略调整
- 现状：8 副本，跨 2 AZ，月度成本 X
- 提议：6 副本 + HPA 上限 12，月度成本约 0.8X
- 风险：AZ 故障时峰值水位升至 90%，P99 可能超标
- 缓解：HPA 扩容窗口 60 秒，超限流降级开关
- 收益：月省 0.2X，单位订单成本降 5%
- 决策人：<姓名>，复审日期：2026-12-011
2
3
4
5
6
7
2
3
4
5
6
7
验证
bash
# 权衡实施后必须验证三件事
# 1) 演练：停一台实例，水位是否仍在安全区
kubectl delete pod <pod> --now
kubectl top pods | sort -k3 -rn | head
# 2) 压测：峰值流量下 P99 是否达标
wrk -t8 -c600 -d300s --latency http://lb/api/order
# 3) 账单：次月单位成本是否下降1
2
3
4
5
6
7
2
3
4
5
6
7
常见坑
用成本指标直接驱动降配
"把 CPU 水位提到 90%" 这类纯成本 KPI 会导致事故。成本目标必须写成"单位业务成本下降"，且附带 SLO 约束。
所有服务一刀切
统一要求"所有服务 3 副本"或"全部降配"都是错的。冗余应随服务等级差异化，L0 加冗余、L3 减冗余。
忽略弹性本身的成本
频繁扩缩会带来镜像拉取、冷启动、监控基数上升等隐性成本，且缩容过快会造成抖动。弹性收益要扣除这些开销再评估。
只算资源成本不算故障成本
砍冗余省下的钱看得见，故障损失看不见，于是决策天然偏向省钱。必须把故障成本显式写出来参与比较。