4. 业务指标与基础设施指标：关键指标分类

在灰度发布准入的门禁体系中，指标是决策的核心依据。不同维度的指标反映了系统在不同层面的健康状态，必须分类管理、分级设限。本章将指标分为业务指标与基础设施指标两大类，并深入解析每类中的关键子项及其在门禁配置中的调优要点。

4.1 指标分类总览

灰度发布准入门禁需要同时关注业务连续性和系统稳定性。业务指标直接衡量用户体验和商业价值，基础设施指标则反映底层资源的承载能力。两者缺一不可，且存在联动关系。

4.2 业务成功率：灰度准入的第一道防线

业务成功率是最直观的可用性指标。在灰度发布场景下，通常以接口级别或业务事务级别的成功率作为门禁条件。常见的配置方式包括：

• 阈值：成功率低于 99.5% 即触发阻断。
• 相对阈值：灰度版本成功率相比基线版本下降超过 1% 即触发阻断。
• 滑动窗口：统计最近 5 分钟内的请求数据，避免瞬时抖动导致误判。

# 示例：PromQL 表达式 - 业务成功率门禁
# 计算灰度分组最近5分钟的请求成功率
sum(rate(http_requests_total{status=~"2..|3..", group="gray"}[5m]))
/
sum(rate(http_requests_total{group="gray"}[5m]))
< 0.995

4.3 订单转化率：商业价值的晴雨表

订单转化率是电商、金融等业务的核心指标。灰度发布可能引入前端交互问题、支付链路故障或推荐算法偏差，导致转化率下降。由于转化率受多种因素影响，门禁配置需要更精细的策略：

• 统计显著性：使用假设检验（如 Z 检验）判断灰度组与基线组的转化率差异是否具有统计显著性，避免因样本量不足而误判。
• 分时段对比：按小时或按天对比转化率，排除业务周期性波动的影响。
• 漏斗分析：将转化过程拆解为多个步骤（如浏览→加购→下单→支付），定位具体哪个环节出现劣化。

4.4 CPU 使用率与内存使用率：资源瓶颈的预警

CPU 和内存是基础设施指标中最基础、最敏感的指标。灰度版本可能因代码效率低下、死循环或内存泄漏导致资源使用率飙升，进而影响同主机上的其他服务。

门禁配置要点：

• CPU 使用率：建议设置 80% 为警告阈值，90% 为阻断阈值。需注意多核 CPU 的平均使用率可能掩盖单核瓶颈，建议同时监控 max(rate)。
• 内存使用率：关注使用量和增长趋势。设置 85% 为警告阈值，95% 为阻断阈值。对于 Java 应用，需结合堆内存使用率一起判断。
• 持续时间：资源使用率短暂突刺（如 1 分钟内）通常可接受，持续超过 5 分钟的高负载才应触发阻断。

# 示例：PromQL 表达式 - CPU 使用率门禁
# 灰度实例 CPU 使用率超过 90% 持续 5 分钟
avg by(instance) (rate(node_cpu_seconds_total{mode!="idle", group="gray"}[5m]))
> 0.9

4.5 GC 次数与暂停时间：Java 应用的隐形杀手

对于 Java 技术栈的应用，GC（垃圾回收）指标是基础设施指标中的关键子类。频繁的 Full GC 或过长的 GC 暂停时间会导致应用卡顿、请求超时，甚至引发雪崩效应。

关键指标与门禁建议：

4.6 指标分类与门禁决策流程

下图展示了业务指标与基础设施指标在灰度发布准入门禁中的协同决策流程。不同类别的指标按照优先级和时效性进行分层评估，最终输出“通过”、“观察”或“阻断”的决策。

4.7 指标联动与门禁参数调优建议

在实际调优中，不应孤立地看待每个指标。以下是一些常见的联动场景及对应的门禁参数配置建议：

• 场景一：CPU 飙升 + 业务成功率下降
  • 可能原因：代码死循环或资源竞争导致请求超时。
  • 调优建议：将 CPU 阻断阈值从 90% 下调至 85%，并缩短持续时间窗口至 3 分钟。
• 场景二：Full GC 频繁 + 内存使用率持续高位
  • 可能原因：内存泄漏或对象分配不合理。
  • 调优建议：增加 Full GC 频率的阻断阈值（如 1 次/3 分钟），并联动堆内存使用率（>90%）一起判断。
• 场景三：订单转化率下降但基础设施指标正常
  • 可能原因：前端交互问题或业务逻辑变更导致用户流失。
  • 调优建议：降低转化率门禁的相对阈值（如从 5% 降至 3%），并增加统计显著性校验的样本量要求。