3、容量水位概念：容量规划基础、水位定义（CPU/内存/磁盘/网络）、饱和度与利用率
容量水位是GameDay演练中验证系统弹性与瓶颈的核心口径。理解容量规划的基础逻辑，并准确区分利用率与饱和度，是构建有效仪表盘的前提。本节将系统性地定义CPU、内存、磁盘、网络四大资源的水位指标，并建立统一的度量口径。
3.1 容量规划基础：从需求到水位
容量规划并非简单的“资源够不够”，而是围绕业务负载与系统承载之间的动态平衡。其核心流程包括：
- 需求预测：基于历史趋势、业务增长计划、营销活动等预估未来负载峰值。
- 资源建模：将业务请求（如QPS、并发用户数）映射到底层资源消耗（CPU时间片、内存页、磁盘IOPS、网络带宽）。
- 水位设定：定义资源使用的安全阈值与告警线，即“水位线”。
- 持续验证：通过GameDay演练注入压力，验证水位线是否合理，是否存在隐性瓶颈。
关键原则： 容量规划的目标不是“无限资源”，而是“在成本可控下，确保系统在极端负载下仍能维持可接受的性能降级”。
3.2 四大资源水位定义
在可观测性体系中，我们通常监控以下四类核心资源。每个资源都有其独特的利用率与饱和度指标，混淆两者会导致误判。
| 资源类型 | 利用率指标（Utilization） | 饱和度指标（Saturation） | 典型水位线（参考） |
|---|---|---|---|
| CPU | CPU使用率（%）：进程占用CPU时间片比例 | CPU运行队列长度（Load Average / run-queue） | 利用率 < 80%；饱和度：run-queue < 2×vCPU |
| 内存 | 内存使用率（%）：已用内存 / 总内存 | Swap使用量 / OOM Killer事件 / 内存回收压力（PSI） | 利用率 < 85%；饱和度：Swap > 0 即告警 |
| 磁盘 | 磁盘使用率（%）：已用空间 / 总空间；IOPS使用率 | 磁盘IO等待时间（await / svctm）；IO队列深度 | 空间利用率 < 80%；IO饱和度：await > 20ms |
| 网络 | 带宽使用率（%）：当前流量 / 接口带宽 | 网络丢包率（drop / overrun）；TCP重传率 | 带宽利用率 < 70%；饱和度：丢包率 > 0.1% |
实战提示： 在GameDay演练中，饱和度指标往往比利用率指标更早暴露问题。例如，CPU利用率可能只有60%，但运行队列已经堆积，此时系统响应时间已开始劣化。
3.3 饱和度与利用率：核心区别
这是容量水位中最容易混淆的概念。简单来说：
- 利用率：资源“正在被使用”的比例，是一个存量指标。
- 饱和度：资源“已经无法及时处理请求”的程度，是一个排队/等待指标。
一个经典的类比是高速公路：
- 利用率 = 当前有多少车道被车辆占用（例如 70% 的车道有车）。
- 饱和度 = 车辆是否开始排队缓行，或者入口匝道是否关闭（例如车速降至20km/h）。
在Grafana仪表盘设计中，我们通常将利用率作为“水位线”的横轴，将饱和度作为“风险指示器”的纵轴，形成容量热力图。
3.4 容量水位关系图
下图展示了从业务负载到资源水位，再到饱和度与利用率之间的逻辑关系，帮助理解GameDay演练中应关注的指标层级。
3.5 水位口径验证清单
在GameDay演练中，针对每个资源，我们需要验证以下口径是否准确反映真实容量风险：
- CPU：是否同时监控了
利用率（%）和运行队列长度？仅看利用率会遗漏“CPU饥饿”场景。 - 内存：是否监控了
PSI（Pressure Stall Information）？内存回收压力比简单的使用率更能反映饱和度。 - 磁盘：是否区分了
空间利用率和IO饱和度？磁盘空间剩余50%但IO延迟已超100ms，系统依然不可用。 - 网络：是否监控了
TCP重传率？重传率升高是网络饱和度的早期信号，比带宽利用率更敏感。
常见误区： 很多团队只设置“CPU > 90%”告警，却忽略了“CPU运行队列 > 10”的饱和度告警。在GameDay演练中，我们应优先验证饱和度指标的告警有效性，因为它们直接关联用户体验。
3.6 饱和度与利用率对比图
为了更直观地理解两者在监控仪表盘上的不同表现，下图展示了同一时间段内，CPU利用率与饱和度指标的典型曲线差异。
通过上述对比可以清晰看到：饱和度指标对负载突增的响应更敏感、更及时。在GameDay演练中，我们应同时展示利用率的“水位线”和饱和度的“风险线”，避免单一指标带来的盲区。