多云基础设施资源编排工程 - 第1节

1. 容量规划基础

容量规划(Capacity Planning)是确保 IT 基础设施在满足当前业务负载的同时,能够以可预测的成本和性能水平支撑未来增长的系统性工程。在 SRE 实践中,容量规划不是一次性的“估算”,而是一个持续循环的闭环过程。

1.1.1 核心定义

容量规划的本质是回答三个问题:

  • 当前状态:系统在典型负载和峰值负载下消耗了多少资源?
  • 未来需求:根据业务增长曲线,未来 N 个月需要多少资源?
  • 供应策略:何时、以何种方式补充资源,才能在不浪费成本的前提下避免性能退化或服务中断?

1.1.2 容量规划的目标

目标维度 说明 典型度量
性能保障 确保资源供给始终满足 SLO/SLA 定义的响应时间与吞吐量 P99 延迟、错误率、队列深度
成本效率 避免过度配置导致的资源浪费,也避免欠配置引发的故障 资源利用率、单位请求成本
风险控制 为突发流量、故障转移、容量耗尽预留安全缓冲 冗余度、故障域容量、扩容时间
自动化驱动 通过指标驱动告警与策略引擎(如 OPA)实现自动扩缩容或资源调度 告警响应时间、策略命中率
SRE 视角: 容量规划不是“预测未来”,而是“管理不确定性”。通过 Prometheus 的实时指标与 OPA 的策略规则,我们可以将容量决策从人工判断升级为数据驱动的自动化闭环。

1.2 四大核心资源指标

在容量规划中,我们通常关注四个基础资源维度:CPU、内存、磁盘 和 网络。每个维度都有其独特的容量瓶颈特征和关键指标。

1.2.1 CPU

CPU 是计算能力的核心,其容量瓶颈通常表现为 高负载 或 上下文切换过频。

  • 核心指标:CPU 使用率(%)、Load Average、CPU 饱和度(run queue 长度)、节流时间(throttled time)。
  • 容量规划要点:关注 利用率 vs 饱和度 的差异。利用率高不一定饱和,但 run queue 持续大于 vCPU 数量则意味着容量不足。
  • 典型告警阈值:持续 5 分钟 CPU 使用率 > 80% 触发预警,> 95% 触发紧急。

1.2.2 内存

内存容量不足会导致 OOM Killer 或频繁的 Swap 交换,严重降低性能。

  • 核心指标:内存使用率(%)、可用内存(bytes)、Swap 使用率、Page Fault 速率。
  • 容量规划要点:区分 文件缓存 与 匿名页。文件缓存可被回收,而匿名页的持续增长才是真正的内存压力信号。
  • 典型告警阈值:可用内存低于总内存 10% 且 Swap 使用率 > 0 时触发。

1.2.3 磁盘

磁盘容量规划需同时关注 空间 和 IO 性能 两个维度。

  • 核心指标:磁盘使用率(%)、IOPS、吞吐量(MB/s)、IO 等待时间(await)、队列深度(avgqu-sz)。
  • 容量规划要点:空间耗尽导致写失败,IO 性能瓶颈导致应用延迟飙升。对于数据库类负载,IO 延迟比空间更敏感。
  • 典型告警阈值:磁盘使用率 > 85% 预警,> 95% 紧急;IO 等待时间 > 50ms 预警。

1.2.4 网络

网络容量瓶颈表现为带宽饱和、丢包或连接数耗尽。

  • 核心指标:带宽使用率(bps)、丢包率(%)、TCP 重传率、连接数(ESTABLISHED、TIME_WAIT)。
  • 容量规划要点:区分 入向 与 出向 流量。微服务架构中,东西向流量往往比南北向流量更容易成为瓶颈。
  • 典型告警阈值:带宽使用率 > 80% 预警;TCP 重传率 > 2% 预警。

1.3 容量规划核心指标全景图

下图展示了四大资源维度的关键指标及其在容量规划中的关联关系:

容量规划核心指标全景图 CPU • 使用率 (%) • Load Average • Run Queue 长度 • 节流时间 • 上下文切换 内存 • 使用率 (%) • 可用内存 (bytes) • Swap 使用率 • Page Fault 速率 • OOM 事件计数 磁盘 • 使用率 (%) • IOPS • 吞吐量 (MB/s) • IO 等待时间 • 队列深度 网络 • 带宽使用率 • 丢包率 (%) • TCP 重传率 • 连接数 • 网络延迟 容量决策引擎(Prometheus 指标 + OPA 策略) 利用率监控 → 趋势预测 → 阈值告警 → 策略执行 输出动作:告警触发 / 自动扩缩容 / 资源预留 / 成本优化建议 说明:每个资源维度的指标通过 Prometheus 采集,由 OPA 策略引擎评估容量状态并驱动自动化动作

1.4 容量规划的关键原则

  1. 利用率 ≠ 容量:高利用率不一定意味着容量不足,需要结合饱和度指标(如 run queue、IO 等待)综合判断。
  2. 趋势比值更重要:单点阈值告警容易误报,基于时间序列的增长率预测(如 PromQL 的 predict_linear)才是容量规划的核心。
  3. 预留缓冲:始终为突发流量和故障转移保留 20%~30% 的冗余容量,避免“满负荷运行”。
  4. 分层规划:基础设施层(物理机/VM)、平台层(容器/PaaS)、应用层(服务/API)的容量规划视角不同,指标粒度也不同。
常见误区: 只关注 CPU 和内存,忽略磁盘 IO 和网络带宽。在 I/O 密集型或网络密集型系统中,磁盘和网络往往是真正的瓶颈。容量规划必须覆盖全部四个维度。

1.5 容量规划与告警、策略的联动关系

在后续章节中,我们将深入讲解如何利用 Prometheus 的告警规则和 OPA 的策略引擎,将上述容量指标转化为自动化的容量管理动作。下图展示了三者之间的联动架构:

容量规划 · 告警 · 策略联动架构 基础设施指标 CPU / 内存 / 磁盘 / 网络 Prometheus 指标采集 + 告警规则 OPA 策略引擎 容量策略评估 自动化动作 告警通知 / 自动扩缩容 / 资源调度 / 成本优化 反馈闭环:容量调整后指标变化再次进入 Prometheus 说明:Prometheus 负责指标采集与告警,OPA 负责策略决策,两者联动形成容量规划的自动化闭环

1.6 本章小结

容量规划是 SRE 体系的基础能力,其核心在于通过 CPU、内存、磁盘、网络 四个维度的关键指标,准确评估系统当前状态并预测未来需求。Prometheus 提供了强大的指标采集与告警能力,而 OPA 则能将容量策略固化为可自动执行的规则。在接下来的章节中,我们将逐一深入每个资源维度的告警规则设计、OPA 策略编写以及实际联动案例。