4. 容量水位定义：概念、常见口径与局限性
容量水位（Capacity Watermark）是衡量服务资源使用程度的核心指标，它直接决定了服务是否处于健康运行区间。在 Error Budget 体系中，容量水位是触发预算消耗的“物理层”依据——当水位超过阈值，服务开始产生性能衰减或错误，进而消耗 Error Budget。
4.1 容量水位的核心概念
容量水位本质上是一个归一化比率，表示当前资源使用量相对于最大可用容量的占比。其通用公式为：
容量水位 = 当前资源使用量 / 最大可用容量 × 100%水位值域为 [0%, 100%]，但实际工程中通常保留安全余量，不会真正达到 100%。
关键区分：容量水位 ≠ 资源利用率。利用率是瞬时或平均统计，而水位通常带有时间窗口（如 P99 水位、平均水位）和业务关联性（如“高峰期水位”）。
4.2 常见容量水位口径
不同资源维度有各自的水位定义方式，以下为四种最常用的口径：
| 资源维度 | 水位口径定义 | 典型阈值 | 采集方式 |
|---|---|---|---|
| CPU | CPU 使用率（user + system + steal） / 总核数 × 100% | 80% 告警，90% 紧急 | /proc/stat, top, cgroup cpuacct |
| 内存 | 已用内存 / 总内存 × 100%（排除 buffer/cache 或按实际 RSS） | 85% 告警，95% OOM 风险 | /proc/meminfo, cgroup memory |
| 磁盘 | 已用空间 / 总空间 × 100% 或 inode 使用率 | 80% 告警，90% 紧急 | df, statfs |
| 网络 IO | 当前带宽 / 网卡最大带宽 × 100% 或 PPS 占比 | 70% 告警，85% 丢包风险 | /proc/net/dev, sar -n DEV |
实践建议：不要使用单一维度的水位做决策。CPU 空闲但内存打满，服务依然不可用。容量规划必须多维度联合评估。
4.3 各口径的局限性分析
每种口径都有其“盲区”，理解这些局限是优化水位口径的前提。
- CPU 水位的局限：
- 无法区分计算密集型与 IO 密集型负载——CPU 空闲可能只是因为线程在等待锁或 IO。
- 忽略 CPU 调度延迟（runqueue 深度）和 steal 时间（虚拟化超分）。
- 多核架构下，单核打满而其他核空闲，平均水位可能很低但服务已出现瓶颈。
- 内存水位的局限：
- Linux 内存管理中的 buffer/cache 可被回收，直接计入“已用”会虚高水位。
- OOM Killer 触发阈值与水位并非线性关系，还与内存碎片、cgroup limit 有关。
- Java/Python 等语言的内存池（heap）使用率与 OS 级水位存在偏差。
- 磁盘水位的局限：
- 空间使用率 ≠ 性能水位。磁盘 IOPS 或延迟打满时，空间可能只用了 30%。
- inode 耗尽会导致无法创建文件，但 df 显示空间仍有剩余。
- SSD 与 HDD 的写入放大、磨损均衡会影响实际可用容量。
- 网络 IO 水位的局限：
- 带宽利用率低但小包 PPS 打满，同样会造成丢包。
- 网卡 offload 特性（TSO/GRO）会使驱动层统计与真实线路流量不一致。
- 单机水位无法反映网络拓扑中的交换机/网关瓶颈。
4.4 容量水位口径优化方向
针对上述局限，业界逐步从“单一资源水位”向“服务级有效容量水位”演进。以下 SVG 展示了优化前后的口径对比：
4.5 从水位到 Error Budget 的映射
在 Error Budget 体系中，容量水位不应孤立存在，而应映射为预算消耗的触发条件。以下表格展示了映射关系：
| 容量水位区间 | 服务状态 | Error Budget 影响 | 建议动作 |
|---|---|---|---|
| 0% – 60% | 健康 | 正常消耗（基线） | 常规运维 |
| 60% – 80% | 注意 | 消耗加速（延迟开始上升） | 评估扩容窗口 |
| 80% – 90% | 警告 | 预算快速消耗（错误率升高） | 触发扩容流程 |
| 90% – 100% | 危险 | 预算可能耗尽（服务受损） | 紧急扩容或降级 |
常见误区：不要将水位阈值直接等同于 Error Budget 阈值。水位是原因，Error Budget 消耗是结果。两者之间应建立延迟、错误率等中介指标，形成“水位 → 性能指标 → Error Budget”的因果链。
4.6 小结：优化后的水位口径原则
- 多维度联合：至少同时评估 CPU、内存、磁盘 IO 延迟三个维度。
- 关联业务指标：水位必须与延迟、错误率、吞吐量等 SLO 指标联动。
- 动态基线：根据时间窗口（日/周/月）和业务高峰自动调整阈值。
- 预留安全余量：任何单一维度不应超过 85%，为突发流量留出缓冲。
- 可归因：每个水位告警必须能追溯到具体的服务、实例和资源维度。