25. 分阶段上线
完整版章节。内容按 2026.10 主线代码与运行环境界面核对；具体入口以当前许可、账号权限和交付环境为准。
本章内容：本章面向负责推广平台的租户管理员与系统管理员，给出从「跑通一次调用」到「全员可用」的推荐步骤。平台把「谁能用」与「请求怎么走」拆成两件事：前者由可用范围决定，后者由流量规则决定；分阶段上线就是先分别收窄这两件事，再逐步放开。
| 阶段 | 主要手段 | 进入下一阶段的条件 |
|---|---|---|
| :-- | :-- | :-- |
| 一、准备 | 授权许可、成员与部门、默认模型、通知渠道 | 26.1 的检查清单全部通过 |
| 二、圈定试点 | 可用范围只授权试点对象，配额从紧 | 试点调用的成功率与耗时符合预期 |
| 三、观察策略 | 内容检测命中后选「仅记录」，保存前用「验证规则」核对 | 命中记录中的误报可接受 |
| 四、灰度切换 | 灰度 Cookie、请求头染色、加权分流 | 灰度与对照请求的结果、耗时无明显差异 |
| 五、逐步推广 | 逐次追加可用范围，观察策略改为拦截 | 每次扩大后观察一个完整业务周期 |
| 六、稳定运行 | 告警、操作审计、定期巡检 | 按第 26 章执行 |
25.1 阶段一：准备
适用场景：平台已部署完成、成员能登录，但还没有人真正使用模型。
- 进入「管理后台 › 系统设置 › 全局设置 ›「授权许可」页签」，确认本次上线涉及的模块已开通。「高级模块」区列出模型护栏、动态路由、全链路审计、用量与成本四项。
- 在「组织与权限 › 成员与部门」确认部门与成员归属，跨部门授权用职能组；三个管理角色按三员分立指定不同人员（第 3 章）。
- 在「全局设置 › 默认模型」为内容判断、敏感信息识别等能力指定模型并确认「正常」；在「告警规则 › 通知渠道」建立已验证渠道（第 22 章）。
你会看到：「许可来源」区显示当前为社区版（未导入许可）或已导入许可的来源与到期时间，并说明社区版不设到期时间。同页给出升级商业授权的三步：导出授权请求（.json）、换取签名许可、导入 .lic。
注意：许可与部署绑定，开发、测试、生产各一套部署需各自的许可文件，不能互导。
25.2 阶段二：用可用范围圈定试点
适用场景：准备让一小批人先在真实业务上使用。可用范围决定谁能看到并使用某个模型分组、MCP 服务或 API 服务。
前提：已接入模型供应商，并建好至少一个面向明确用途的模型分组（第 4～6 章）。
- 先在分组内模型的「试用」页签发送一条消息，确认回复正常、耗时与 Token 有数值。
- 打开服务详情「可用范围与配额」，点「编辑可用范围」，选择授权对象类型（所有用户、部门、职能组、工作空间或逐个成员）。试点期按部门或职能组授权，人员变动时只调组织即可。
- 「下一步」进入「配置目标有效期」，选带结束时间的有效期；保存后为试点对象设置从紧的配额（第 7 章）。
你会看到：可用范围表按对象逐行列出名称、类型与配额。范围外的成员在广场与密钥归属下拉中都看不到该服务，直接打开管理端详情地址会被重定向回设置页。
注意：新建的模型分组默认没有可用范围。授权变更下发通常在几分钟内完成；把成员移出范围后，其已签发的密钥不会立刻失效，之后返回 401 invalid_api_key。需要立即断权时改用禁用密钥或把成员移至已离职（3.9）。
25.3 阶段三：用观察方式验证安全策略
适用场景：第一次为真实业务启用敏感信息、模型判断或工具调用检测。这类策略初期容易误报，直接拦截会打断业务。
- 在「护栏 › 护栏规则 › 敏感数据」点「试运行」，选择要检测的类型并粘贴典型业务文本，核对识别结果与脱敏后的文本。试运行不写调用记录，也不真的请求模型。
- 在流量规则中添加「内容检测 · 对话内容」或「内容检测 · 工具调用」动作，命中后的处置先设为「仅记录」；关键词的「字符插桩命中后」与「解码后命中」同样可选此项。
- 使用模型判断时，确认节点中「判断模型不可用时」的处置。新建规则默认为「拒绝」，确有业务连续性要求时才改为「放行」（第 14.9 节）。保存前用画布右栏的「验证规则」核对典型样本（第 14.12 节）。
- 保存并「确认并应用」，运行一个完整业务周期后在「运行总览 › 请求」核对命中规则与结果类别；误报可接受后把处置改为「脱敏」或「拦截」并再次确认。
你会看到：试运行结果形如「已脱敏 · 手机号 1 处」并给出耗时。拦截生效后返回 403 CONTENT_POLICY_BLOCKED，message 为配置的回复话术；调用记录中结果为「已拦截」。
注意：「仅记录」的命中同样出现在调用记录与规则详情的流量视图中，可配合告警指标「策略命中」「策略拦截」观察误报是否收敛。改为拦截后调用方看到的是回复话术，上线前须通知业务方。
25.4 阶段四：用灰度规则切换一部分请求
适用场景：需要更换模型、更换上游或调整流量规则，但不能一次切掉全部流量。
| 方式 | 适用场景 | 配置方法 |
|---|---|---|
| :-- | :-- | :-- |
| 灰度 Cookie | 浏览器类客户端按会话染色 | 条件「灰度 Cookie」，名称从 zenova_canary、zenova_rollout、zenova_variant 中选一个并填取值 |
| 请求头 | 业务系统自行控制哪些请求走新路径 | 条件「请求头」，例如 x-release-channel 等于 gray |
| 加权分流 | 按比例切换流量 | 动作「转发到」，目标选择策略选「加权轮询」，为新旧目标设权重 |
| 影子分派 | 新目标先旁路试跑 | 动作中添加「影子分派」，按比例复制请求到候选目标 |
操作步骤（以加权分流为例）
- 进入「流量 › 流量规则」，点「新建规则」。条件：模型分组属于试点分组、调用类型为「模型调用」；限定人员时追加「调用方」条件。
- 动作选「转发到」，目标选择策略选「加权轮询」，原目标权重 90%、新目标权重 10%；需要回退时添加备用档位并开启故障转移。
- 在右侧「验证规则」页签中确认本规则命中，再「保存规则」，在「确认变更」中核对命中顺序后点「确认并应用」。
- 在「实时流量」查看各目标的实际占比与耗时，在「运行总览 › 请求」核对真实落点；确认无异常后逐步调整权重直到 100%。
你会看到：「确认变更」列出字段差异、关联对象与命中顺序，页脚提示「确认后，命中的请求会按新规则走。发布前请先看命中顺序。」保存后配置下发到网关节点需十几秒到二十秒；「实时流量」按目标给出配置权重、实际占比与耗时分位。
注意：规则按优先级从上到下匹配，设置了「结束匹配」的前序规则会截住请求；新规则保存后先用「验证规则」模拟一次，确认确实被求值并命中。加权轮询在小样本下比例会偏差，判断比例以足够多的请求为准。
快速回退：在规则清单中关闭该规则的状态开关，后续请求立即不再匹配，进行中的请求不受影响。回到历史配置时，在「修改记录」中查看各次变更，按差异手工改回并重新保存。
25.5 阶段五：逐步推广与阶段确认
- 每次只扩大一个维度：增加部门、增加模型分组、增加 MCP 服务，或把一项观察策略改为拦截。
- 扩大后用范围外账号验证仍被拒绝；随后按真实用量调整配额，在「运行总览」关注费用与成功率。
- 在「使用洞察」处理试点期暴露的问题；需通知成员的变化用「通知横幅」发布。
阶段结束前逐项确认
- [ ] 「运行总览 › 请求」中本阶段的调用全部可查，路由结论与命中规则符合预期
- [ ] 策略命中记录的对象与次数符合预期，没有明显误报；「告警」中没有未处理的严重告警
- [ ] 范围外账号、未授权密钥的调用被正确拒绝；操作审计中变更记录完整
- [ ] 已写下回退方式：停用哪条规则、恢复哪个范围、把哪项策略改回观察
能力说明
| 不提供的能力 | 替代做法 |
|---|---|
| :-- | :-- |
| 多套环境在同一部署内隔离并同步配置 | 按环境各部署一套，各自导入许可与配置；流量规则可导出 YAML 后在目标环境导入（2.7） |
| 灰度 Cookie 使用自定义名称 | 改用「请求头」条件做染色（25.4） |
| 规则的「观察模式」（整条规则只记录不执行） | 内容检测动作选「仅记录」；路由类变更先用「验证规则」模拟，再用极小权重放量（25.4） |
| 按健康指标自动放量、异常时自动回退 | 手动调整权重；配置故障转移切到备用档位；发现异常后停用规则（25.4） |
---