2、灰度放量基础：灰度策略定义、放量比例模型、渐进式发布原则

灰度放量是节点升级窗口中最核心的风险控制手段。它通过将新版本逐步暴露给部分节点或流量，在真实生产环境中验证稳定性，避免全量发布带来的爆炸半径。本节从策略定义、比例模型和发布原则三个维度建立灰度放量的理论基础。

2.1 灰度策略定义

灰度策略决定了“哪些节点先升级、以什么条件升级、何时扩大范围”。在 Policy as Code 框架下，策略被编码为可版本化、可审计的规则文件，而非人工操作清单。

2.2 放量比例模型

放量比例模型定义了灰度范围从 0% 到 100% 的数学映射关系。不同的模型适用于不同的风险场景和业务容忍度。

2.2.1 常见放量模型对比

2.2.2 放量比例模型 SVG 示意图

2.3 渐进式发布原则

渐进式发布不是简单的“分批升级”，而是一套包含观察、评估、决策的闭环流程。以下六条原则构成了渐进式发布的骨架：

1. 最小爆炸半径原则：首批灰度节点数不超过集群总数的 5%，且必须分布在不同的故障域（AZ/机架）。
2. 可观测性原则：每个灰度批次必须暴露完整的监控指标（错误率、延迟、资源使用率、日志异常率），否则暂停放量。
3. 健康门禁原则：只有当前批次所有节点通过健康检查（含合成探测和真实流量探测），才允许进入下一批次。
4. 自动回滚原则：当错误率超过预设阈值（如 1%）或延迟 P99 恶化超过 20% 时，自动触发回滚至上一稳定版本。
5. 人工闸门原则：在关键放量节点（如 10%、50%、100%）设置人工确认步骤，防止自动化误判。
6. 不可变基础设施原则：灰度过程中不修改已有节点配置，新版本通过替换实例或原地升级方式部署，保留回滚能力。

2.4 灰度放量流程 SVG 架构图

2.5 灰度策略的 Policy as Code 示例

以下是一个基于 Rego 语言的灰度放量策略片段，展示了如何将放量比例模型和健康门禁编码为可执行规则：

# grayscale_policy.rego
package node_upgrade.grayscale

# 定义放量比例模型（指数模型）
allowed_ratio := {
    "round_0": 0.01,   # 首批 1%
    "round_1": 0.02,   # 第二批 2%
    "round_2": 0.04,   # 第三批 4%
    "round_3": 0.08,   # 第四批 8%
    "round_4": 0.16,   # 第五批 16%
    "round_5": 0.32,   # 第六批 32%
    "round_6": 0.64,   # 第七批 64%
    "round_7": 1.00    # 全量 100%
}

# 健康门禁规则
default health_gate_passed := false

health_gate_passed {
    input.error_rate < 0.01          # 错误率 < 1%
    input.p99_latency_ms < 200       # P99 延迟 < 200ms
    input.cpu_usage_pct < 80         # CPU 使用率 < 80%
    input.memory_usage_pct < 85      # 内存使用率 < 85%
    input.health_check_success       # 合成探测通过
}

# 放量决策
allow_scale_up {
    health_gate_passed
    input.current_round in allowed_ratio
    input.proposed_ratio == allowed_ratio[input.current_round]
}

# 回滚触发条件
trigger_rollback {
    input.error_rate >= 0.05         # 错误率 ≥ 5%
    or input.p99_latency_ms >= 500   # P99 延迟 ≥ 500ms
    or input.consecutive_failures >= 3  # 连续 3 次健康检查失败
}

2.6 灰度放量参数调优清单

在实际调优过程中，以下参数是 Policy as Code 灰度策略的核心调节点：