3. 传统容量评估方法及其局限性
在引入故障注入与Service画像协同优化之前，有必要先厘清传统容量评估方法的核心逻辑与固有缺陷。传统方法长期依赖静态峰值与经验估算，缺乏对系统动态行为的感知能力，导致容量水位口径要么过度冗余，要么严重不足。
3.1 基于峰值的静态评估
该方法以历史监控数据中的最高流量点作为容量规划基准，通常取“过去30天/90天/1年的最大QPS或并发数”，再乘以一个安全系数（如1.5x~3x）作为部署规格。
| 评估步骤 | 典型做法 | 输出产物 |
|---|---|---|
| 1. 数据采集 | 从监控系统提取CPU、内存、QPS、连接数等时序指标 | 原始时序数据集 |
| 2. 峰值识别 | 取99.9分位或最大值作为“设计容量” | 峰值指标值 |
| 3. 冗余放大 | 乘以安全系数（如2x）得到目标容量 | 静态容量规格 |
| 4. 资源部署 | 按规格一次性采购/分配机器或容器 | 固定资源池 |
典型场景案例：某电商平台每年双11大促前，运维团队将去年峰值QPS乘以2.5倍作为容量目标，提前两个月完成机器采购与扩容。结果当年流量仅增长30%，大量服务器在非大促期间长期处于10%~20%的低负载状态，资源浪费严重。
3.2 基于经验的粗放评估
当缺乏精确的容量模型或监控数据不完整时，团队往往依赖个人经验或历史惯例进行估算。常见做法包括：
- “拍脑袋”系数法：运维负责人根据过往故障经验，主观设定“每台机器扛5000 QPS”或“每个Pod预留2核4G”等固定阈值。
- 同行业对标法：参考友商或开源社区的推荐配置，直接套用到自身业务场景，忽略业务逻辑差异（如计算密集型 vs IO密集型）。
- “加一台”应急法：线上出现容量告警后，临时增加1~2台机器，不做根因分析，导致容量水位反复波动。
经验评估的典型陷阱：某社交App的Feed流服务，运维凭经验认为“单机2000 QPS是安全水位”，但未考虑Feed推荐算法升级后CPU指令集变化。新版本上线后，单机QPS降至1200时CPU已打满，引发大规模超时雪崩。
3.3 缺乏动态弹性
传统容量评估的静态本质使其无法适应云原生环境下流量、依赖、资源的多维动态变化。具体表现为：
- 流量突发无缓冲：基于历史峰值的评估无法预测突发热点事件（如明星八卦、秒杀活动），导致容量瞬间击穿。
- 依赖关系变化：微服务拓扑调整、第三方API响应变慢、数据库连接池耗尽等间接因素，会改变服务的实际容量需求，静态评估无法感知。
- 资源争抢不可控：在混部集群中，不同服务的CPU Burst、内存回收、网络带宽竞争实时变化，静态分配的资源无法动态调整。
动态弹性的缺失代价：某在线教育平台使用固定容器规格（4C8G）部署所有微服务，未启用HPA（Horizontal Pod Autoscaler）。某次营销活动流量突增3倍，因无法快速扩容，核心服务响应时间从50ms飙升至5s，最终导致30%用户流失。
3.4 传统方法局限性的SVG对比图
下图从评估基准、决策方式、响应能力三个维度，对比传统静态评估与理想动态评估的差异：
3.5 传统方法局限性的汇总清单
| 局限性 | 具体表现 | 典型后果 | 影响范围 |
|---|---|---|---|
| 峰值静态评估 | 以历史最大值为基准，乘以固定安全系数 | 非峰值期资源闲置率高达40%~70% | 成本、资源利用率 |
| 经验粗放评估 | 依赖个人经验或行业对标，缺乏数据支撑 | 容量预估偏差可达±50%以上 | 稳定性、SLA达成率 |
| 缺乏动态弹性 | 无法感知流量突发、依赖变化、资源争抢 | 故障响应延迟，容量击穿概率增加3~5倍 | 可用性、用户体验 |
| 评估口径单一 | 仅关注QPS/并发数，忽略延迟、错误率、资源饱和度 | 容量水位与真实瓶颈脱节 | 故障定位、容量规划 |
容量规划的第一性原理：容量不是“买多少机器”，而是“系统在给定负载下，能否持续满足SLO（服务等级目标）”。传统方法忽略了负载与性能之间的非线性关系，这正是后续故障注入与Service画像要解决的核心问题。