13-容量规划与故障注入检查清单¶
目标：把“我觉得系统扛得住”变成有容量余量、有故障注入、有退化预案的工程判断。
图源：Wikimedia Commons - Demingcycle.svg，Public domain。当前主图用于解释容量规划、故障注入、结果验证与持续改进的闭环。
一、容量规划前至少要问清楚 5 个问题¶
- 平峰和峰值流量分别是多少
- 哪个组件最先成为瓶颈
- 需要多少安全余量
- 缓存失效或降级失效时还能不能扛住
- 哪类故障会直接触发回滚
如果这些问题说不清，后面的“我们可以横向扩容”通常也站不住。
二、AI 系统的容量规划，不能只看 QPS¶
AI 服务里经常还要同时看：
- 并发数
- 平均输入长度与输出长度
- Token 峰值
- GPU 显存与 batch 大小
- 队列深度
- 缓存命中率
- 模型路由比例
同样是 100 QPS，短请求和长上下文 Agent 请求的资源消耗可能完全不是一个量级。
三、一份最小容量规划表¶
| 维度 | 当前值 | 峰值目标 | 安全余量 | 备注 |
|---|---|---|---|---|
| QPS | ||||
| 并发 | ||||
| 平均 token / 请求 | ||||
| GPU / CPU | ||||
| 显存 | ||||
| 队列深度 | ||||
| 缓存命中率 | ||||
| 单请求成本 |
如果你在面试里能主动补一张这样的表，可信度会高很多。
四、故障注入应该覆盖哪些场景¶
| 故障类型 | 注入方式 | 预期保护动作 | 重点观察指标 |
|---|---|---|---|
| 上游超时 | 人为拉长依赖延迟 | 超时保护、降级回答、快速失败 | P99、失败率 |
| 缓存失效 | 清空缓存或命中率打穿 | 限流、热点保护、成本告警 | 成本、P99、命中率 |
| 单节点失效 | 摘除推理节点或向量库节点 | 自动摘流、重试、扩容或回滚 | 可用性、队列深度 |
| GPU OOM | 构造长上下文或大 batch | 路由降级、限流、回滚参数 | OOM 率、首 token 延迟 |
| 索引积压 | 延迟 embedding / index 更新 | 旧索引兜底、告警、停止放量 | 新鲜度、召回质量 |
故障注入不是为了“证明系统很强”，而是为了知道：
- 哪些保护动作真的会触发
- 哪些保护动作其实只是写在设计图上
五、最低合格线是什么¶
一套能拿得出手的容量规划与故障注入，最低至少满足：
- 有平峰和峰值估算
- 有安全余量假设
- 有至少 3 类故障注入记录
- 有降级、熔断或回滚动作定义
- 有实验结论，而不是“理论上应该没问题”
一句话：
六、面试里怎么回答¶
推荐结构：
- 先说你会估哪些量：QPS、并发、token、GPU、缓存
- 再说瓶颈在哪：模型、向量库、队列、网络还是缓存
- 补安全余量和高峰策略
- 最后说你会注入哪些故障，如何验证保护动作
可以直接这样讲：
Text Only
我做容量规划时，不会只看 QPS，还会看并发、token 长度、模型路由比例、
GPU 显存、队列深度和缓存命中率，因为这些在 AI 服务里直接决定成本和尾延迟。
做完容量估算以后，我会对上游超时、缓存失效、单节点故障和 GPU OOM 做故障注入，
验证限流、降级、熔断和回滚是否真的生效。
七、自检清单¶
- 我能给出一张最小容量规划表
- 我知道 AI 服务里为什么必须看 token、GPU 和缓存
- 我能列出至少 3 类值得做的故障注入
- 我知道注入后要看哪些指标来判断保护动作是否生效
- 我能把容量规划、故障注入、回滚策略连成闭环
结论¶
容量规划和故障注入，决定了你是在“猜系统大概扛得住”，还是在“用实验验证系统真的扛得住”。
对 AI 系统设计题来说，后者的说服力会高得多。
⚠️ 核验说明（2026-03-29）：本页已修复图片来源异常并重写检查清单。若你所在团队使用固定压测模型或 chaos engineering 平台，可将本页模板映射到团队工具链。
最后更新日期： 2026-03-29