4. 资源利用率监控与右调优
右调优（Rightsizing）是 FinOps 中把"账单数字"翻译成"技术动作"的关键环节。它的核心逻辑并不复杂：持续采集 CPU、内存、网络、存储等利用率指标，找出长期低于合理水位的资源，把实例规格下调到与真实负载匹配的档位，再验证性能没有受到不可接受的损害。难点在于——利用率低不等于可以缩容，缩容之后也不等于任务完成，必须闭环到性能验证。
一、先明确"低利用率"的判定口径
右调优最容易出错的地方，是把瞬时低利用率当成长期低利用率。一台实例在凌晨 3 点 CPU 只有 3%，不代表它白天不需要 8 核。因此判定必须建立在统计口径上，而不是采样点。
工程上常用的判定维度包括：
- 统计窗口：至少覆盖一个完整业务周期，通常取 14～30 天，包含工作日与周末、大促或月末结算等峰值场景。
- 分位值而非均值：CPU 用 P95 或 P99 判断峰值压力，用 P50 判断常态水位。均值会掩盖尖峰。
- 内存看水位而非均值：内存是"高水位"型资源，应关注窗口内的最大值（Max）与常驻使用量，因为内存不足会直接触发 OOM Kill。
- 网络与存储看吞吐与 IOPS：网络关注带宽峰值与连接数，存储关注 IOPS、吞吐量和队列深度，而不是简单的"使用率"。
一个可参考的判定阈值（示例口径，需按业务调整）：CPU P95 < 20% 且内存 Max < 40%，视为"明显低配需求"；CPU P95 在 20%～40% 之间，视为"可观察候选"；CPU P95 > 60% 或内存 Max > 80%，则不应缩容，反而要考虑扩容。
二、指标采集：从哪来、采什么、存多久
采集层通常由三类数据源构成。第一类是云厂商原生监控，如 CloudWatch、云监控、Azure Monitor，提供 CPU 使用率、内存（需装 Agent）、网络进出带宽、磁盘读写等基础指标，优点是零改造、覆盖全，缺点是粒度粗（常见 1 分钟或 5 分钟）、维度有限。第二类是主机与容器 Agent，如 node_exporter、cAdvisor、云厂商 Agent，可拿到更细的 CPU steal、内存 cache/buffer、磁盘 await、容器级 limit/request 等。第三类是应用层埋点，如 JVM GC 时间、连接池占用、请求 QPS 与延迟，用于解释"为什么 CPU 不高但延迟高"。
采集频率建议：基础资源指标 1 分钟一次，应用指标 15～60 秒一次。存储周期上，原始精度数据保留 15～30 天用于右调优分析，降采样后的 5 分钟或 1 小时聚合数据保留 13 个月用于趋势与容量规划。
下面这张图展示了从指标采集、低利用率识别、规格右调优到性能验证的完整信号链，以及每一步的关键判断条件。
三、右调优的执行方法
识别出候选实例后，不能直接改规格，而要按"计算目标规格 → 评估兼容性 → 灰度变更 → 观察验证"的顺序推进。
目标规格计算。以 CPU 为例，若某实例 30 天窗口内 CPU P95 为 12%，当前 8 vCPU，则实际峰值消耗约 0.96 vCPU。考虑安全系数 1.5，目标 vCPU ≈ 0.96 × 1.5 ≈ 1.44，向上取整到 2 vCPU。但实际工程中很少直接降到 2 vCPU，因为还要考虑突发流量、启动预热、GC 线程数等。更稳妥的做法是逐级下调：8 → 4 → 2，每级观察一个完整业务周期。
内存则不同。内存不能按 P95 算，要按窗口内 Max 值再留 20%～30% 余量。若 Max 为 9.6 GB，目标内存至少 12 GB，因此选择 16 GB 档位而非 8 GB。这就是为什么 CPU 和内存往往不能同时降到最低档——实例族通常按固定配比提供规格。
兼容性检查。缩容前必须确认：新规格是否在同一可用区有库存；是否支持所需的增强网络、GPU、本地 NVMe 等特性；是否影响已绑定的弹性 IP、ENI 数量上限；容器场景下是否满足 Pod 的 request/limit 调度约束。这些检查不做，变更后可能出现实例起不来或调度失败。
灰度与回滚。生产环境不要一次性全量变更。建议按 10% → 30% → 100% 分批，每批观察至少 24 小时。变更方式优先选择"先建新实例、加入负载均衡、再摘除旧实例"的滚动替换，而不是原地停机改规格，这样可以把不可用时间压到接近零。同时必须准备好回滚脚本或镜像，一旦验证不通过能在分钟级恢复。
四、性能影响验证：看什么、看多久
验证不是"看服务还活着"，而是对比变更前后的关键指标。建议至少覆盖以下四类：
| 验证维度 | 关键指标 | 可接受标准（示例） |
|---|---|---|
| 延迟 | P50 / P95 / P99 响应时间 | P99 增幅 ≤ 10%，且不超过 SLO 上限 |
| 错误 | 5xx 比例、超时率、连接拒绝数 | 错误率无显著上升，绝对值 < 0.1% |
| 资源 | CPU steal、内存 swap、磁盘 await | 无持续 swap，await < 20 ms |
| 应用 | GC 暂停时间、线程池队列深度 | GC 时间增幅 ≤ 20%，队列无持续积压 |
观察期建议不少于 7 天，且必须覆盖至少一个业务峰值日。如果业务有周期性（如每周一上午高峰），观察期要包含该峰值。验证期间保持监控告警阈值不变，一旦触发立即回滚。
五、把右调优变成持续机制
右调优不是一次性项目，而是持续运营。建议建立月度节奏：每月初跑一次低利用率扫描，输出候选清单；月中完成变更与验证；月末复盘节省金额与回滚率。同时把右调优结果反哺到容量规划——如果某类实例连续三个月都被判定为低利用率，说明初始选型标准偏保守，应调整新实例的默认规格模板。
需要强调的是，右调优的目标不是"把利用率拉到最高"，而是在满足性能与可靠性约束的前提下消除浪费。利用率 15% 的实例如果承载的是核心交易链路，缩容带来的风险可能远大于节省的成本。判断标准始终是业务 SLO，而不是一个漂亮的利用率数字。