4. 上线控制基础

模型上线不是一次“把文件拷到服务器”的动作，而是一条受控的交付链路。审计视角下，上线控制的核心目标只有三个：变更可追溯、环境可复现、失败可回退。本节围绕上线前检查清单、审批流程、环境隔离、版本管理与制品库管理五个基础控制点展开，它们共同构成模型变更上线的“准入闸门”。

一、核心原理：上线控制是一组“证据链”

模型与普通代码的差异在于：它同时包含代码、参数、训练数据、推理配置四类资产。任何一类发生变化，模型行为都可能改变。因此上线控制不能只检查“程序能不能跑”，而要建立一条从训练产物到生产实例的证据链：谁训练的、用什么数据、经过哪些评估、由谁批准、部署到哪个环境、当前生产运行的是哪个版本。

这条证据链的载体就是制品（Artifact）。制品一旦生成即不可变，所有环境都从制品库拉取同一份内容，禁止在生产环境现场修改。审计时，只要制品库记录完整，就能回答“线上这个模型到底是哪一版”这一关键问题。

二、上线前检查清单：把风险挡在发布之前

检查清单是上线控制的第一道闸门。它应当覆盖模型质量、工程可用性、合规与安全三个维度，并且每一项都要有明确的通过标准和责任人，而不是模糊的“已确认”。

清单的执行应尽量自动化。例如在 CI 流水线中固化检查脚本，只有全部通过才允许生成“可发布”制品：

# 上线前自动检查示例
python check_metrics.py --baseline baseline.json --candidate candidate.json
python run_regression.py --suite critical_cases.yaml
python security_scan.py --model ./model --report security.json
# 全部返回 0 才允许打标签
if [ $? -eq 0 ]; then
  echo "PRECHECK_PASSED"
fi

三、审批流程与环境隔离：职责分离与风险分层

审批流程解决的是“谁有权决定上线”。审计上强调职责分离：模型开发者不能同时是上线批准者，评估人员不能同时是发布执行者。典型流程为：提交上线申请 → 技术评审 → 业务/风险审批 → 发布执行 → 上线后验证。高风险变更（如涉及资金、医疗、安全策略）应升级审批层级。

环境隔离则解决“在哪里验证、在哪里运行”。至少应区分开发、预发（Staging）、生产三类环境，并保证：

• 预发环境与生产环境的推理框架、依赖版本、配置结构保持一致，仅数据与规模不同；
• 生产环境禁止直接修改模型文件或配置，所有变更必须通过制品库发布；
• 环境之间的网络与权限隔离，开发人员默认无生产写权限；
• 预发验证通过是进入生产审批的前置条件。

四、版本管理与制品库：让每一版都可定位

版本管理要求模型、代码、配置、数据版本四者关联。推荐使用语义化版本或内容哈希作为制品标识，并在元数据中记录训练数据版本、代码提交号、评估报告链接。制品库则承担存储、权限、审计日志三项职责。

# 制品元数据示例（model-manifest.yaml）
model_name: risk-scoring
version: 2.4.1
artifact_hash: sha256:9f2c...ab31
code_commit: 7d1e4c9
data_version: ds-2024-11
metrics:
  auc: 0.873
  p99_latency_ms: 118
approved_by: risk-committee
created_at: 2024-11-20T10:32:00Z

制品库应设置为只追加、不可覆盖。同一版本号重复上传必须被拒绝，回滚时直接引用历史制品，而不是重新构建。这样审计人员可以通过制品哈希，把线上实例、发布记录、审批单据三者精确对应起来。

五、常见误区与复盘

误区一：把“测试通过”等同于“可以上线”。测试通过只说明功能正确，不代表性能、安全、回滚方案就绪。检查清单必须覆盖非功能项。

误区二：生产环境手工改配置。这是审计中最常见的问题。手工修改无法追溯，且与制品库记录不一致，一旦回滚会丢失现场。正确做法是修改配置模板、重新生成制品、走变更流程。

误区三：版本号复用或覆盖。同一版本号对应两份不同内容，会让审计彻底失效。制品库必须拒绝覆盖写入。

误区四：审批流于形式。审批人未看到评估报告就签字，等于没有控制。审批记录应关联制品哈希与评估结论，做到“签的是哪一版”清晰可查。

综上，上线前检查清单负责“准入”，审批流程负责“授权”，环境隔离负责“边界”，版本管理与制品库负责“定位与复现”。这五项基础控制相互支撑，构成模型变更上线与回滚控制的起点，也是后续灰度发布、监控告警与回滚演练能够有效运转的前提。