2. 容量水位基础概念：什么是容量水位、水位指标的定义、水位与系统健康度的关联
2.1 容量水位的本质定义
容量水位（Capacity Water Level）是描述系统当前负载相对于其最大可承载能力的相对位置。它不是单纯的资源使用率，而是将资源消耗、排队深度、响应延迟等指标映射到一个统一的“水位标尺”上，用于判断系统是否处于安全运行区间。
核心公式：
容量水位 = 当前负载量 / 系统额定容量 × 100%
注：额定容量需通过混沌工程压测与故障注入联合标定，而非仅凭硬件规格推算。
容量水位 = 当前负载量 / 系统额定容量 × 100%
注：额定容量需通过混沌工程压测与故障注入联合标定，而非仅凭硬件规格推算。
2.2 水位指标的三层定义体系
水位指标不能仅依赖单一指标，必须从资源层、服务层、业务层三个维度联合定义，才能准确反映系统真实状态。
| 层级 | 典型指标 | 水位计算口径 | 混沌工程验证点 |
|---|---|---|---|
| 资源层 | CPU 使用率、内存占用、磁盘 IOPS、网络带宽 | 当前值 / 压测标定上限 | 突增流量下资源争抢是否导致水位跳变 |
| 服务层 | P99 延迟、吞吐量(TPS/QPS)、错误率、连接池占用 | 当前延迟 / 延迟SLO上限；当前TPS / 最大TPS | 单节点故障后剩余节点水位是否超限 |
| 业务层 | 订单成功率、支付超时率、用户登录耗时 | 当前成功率 / 业务SLO下限 | 依赖服务降级后业务水位是否触发熔断 |
实践建议： 在混沌工程实验中，优先观察“服务层水位”的突变，因为它比资源层更早反映系统瓶颈，比业务层更少受外部因素干扰。
2.3 水位与系统健康度的关联模型
系统健康度并非简单的“水位低=健康，水位高=不健康”。实际关联呈现非线性、带滞回区的特征。以下 SVG 展示了水位区间与健康状态的对应关系。
2.4 水位与健康度的量化对应关系
基于混沌工程的大量实验数据，我们总结出以下水位-健康度对照表，用于指导容量规划与自动伸缩策略。
| 水位区间 | 健康度评分 | 系统表现 | 混沌工程建议动作 |
|---|---|---|---|
| 0% – 50% | 90 – 100 | 延迟稳定，错误率接近0，资源充裕 | 可执行常规故障注入，验证冗余能力 |
| 50% – 75% | 70 – 90 | 延迟轻微上升，偶有资源争抢，但SLO仍满足 | 执行限流降级实验，观察水位是否回落到安全区 |
| 75% – 90% | 40 – 70 | P99延迟接近SLO上限，错误率开始出现，排队明显 | 触发弹性伸缩预案，同时注入单点故障验证容灾 |
| 90% – 100% | 0 – 40 | SLO被打破，错误率飙升，部分请求被拒绝 | 立即执行熔断/降级，水位恢复前禁止再注入故障 |
关键认知： 水位达到 75% 并不意味着系统即将崩溃，但它是混沌工程实验的“红线”。在红线以下，故障注入可以安全进行；越过红线，必须先执行降级或扩容，否则注入故障可能导致真实生产事故。
2.5 水位口径的混沌工程校准方法
传统水位定义依赖静态阈值，而混沌工程要求通过动态压测 + 故障注入来校准真实水位上限。以下 SVG 展示了校准流程。
2.6 水位口径优化的核心原则
- 可测量性： 每个水位指标必须能在生产环境通过混沌工程实验直接采集，不能依赖估算。
- 可复现性： 相同负载下，水位值在不同时间、不同节点上应保持稳定，波动超过 ±10% 需排查口径问题。
- 可预警性： 水位指标必须在系统健康度恶化前 30 秒以上给出明确信号，为自动化运维留出响应窗口。
- 可行动性： 每个水位区间必须绑定明确的运维动作（扩容、降级、熔断、告警），避免“只监控不处理”。
实战检查清单：
□ 是否已为每个服务定义了三层水位指标（资源/服务/业务）？
□ 水位上限是否经过混沌工程压测+故障注入双重验证？
□ 水位与健康度的对应关系是否已写入自动化伸缩策略？
□ 是否建立了水位滞回区的冷却时间机制，防止频繁抖动？
□ 是否已为每个服务定义了三层水位指标（资源/服务/业务）？
□ 水位上限是否经过混沌工程压测+故障注入双重验证？
□ 水位与健康度的对应关系是否已写入自动化伸缩策略？
□ 是否建立了水位滞回区的冷却时间机制，防止频繁抖动？