3. 制品供应链概述：从代码提交到生产部署的制品流转链路，关键节点与制品元数据
制品供应链（Artifact Supply Chain）是软件交付的核心骨架，它定义了从代码提交到生产部署之间，制品（Artifact）所经历的所有构建、存储、扫描、签名、部署环节。理解这条链路上的每个关键节点及其对应的制品元数据，是构建误差预算台账与异常检测模型的基础。
3.1 制品供应链全景链路
一个典型的制品供应链包含以下六个核心阶段，每个阶段都会产生或变更制品的元数据状态：
- 代码提交（Commit）：开发者将代码变更推送至版本控制系统（Git），触发 CI 流水线。
- 持续集成（CI Build）：编译代码、运行单元测试，生成原始构建产物（如 JAR、WAR、Docker Image）。
- 制品仓库（Artifact Repository）：存储构建产物，进行版本管理、元数据索引。
- 安全扫描与签名（Scan & Sign）：对制品进行漏洞扫描、许可证合规检查、数字签名。
- 持续部署（CD Deploy）：将经过审批的制品部署至测试、预发、生产环境。
- 运行时验证（Runtime Verification）：确认部署后的服务健康状态，回滚或继续推进。
关键洞察： 误差预算的“误差”往往在供应链节点间传递并放大。例如，构建阶段的编译警告可能被忽略，但在部署阶段转化为运行时错误，最终消耗服务的误差预算。
3.2 关键节点与制品元数据
每个供应链节点都会产生特定的制品元数据。这些元数据是误差预算台账的核心数据源，也是异常检测模型的输入特征。下表列出了各节点的关键元数据字段：
| 供应链节点 | 关键元数据字段 | 数据来源 | 异常检测价值 |
|---|---|---|---|
| 代码提交 | commit_sha, author, timestamp, branch, changed_files, commit_message | Git API / Webhook | 检测提交频率异常、大变更提交、非工作时间提交 |
| CI 构建 | build_id, status, duration, test_pass_rate, coverage, compiler_warnings | CI 平台（Jenkins/GitLab CI） | 构建时长突增、测试通过率下降、警告数激增 |
| 制品仓库 | artifact_uri, version, size, checksum, upload_time, storage_class | Nexus / Artifactory / S3 | 制品大小异常、版本号跳跃、重复上传 |
| 安全扫描 | scan_id, vuln_count, severity, cve_list, license_type, scan_duration | Trivy / Snyk / SonarQube | 高危漏洞数量突增、扫描超时、许可证冲突 |
| CD 部署 | deploy_id, environment, status, rollout_strategy, canary_percentage, duration | Spinnaker / ArgoCD / 自研平台 | 部署失败率上升、金丝雀异常、回滚频率增加 |
| 运行时验证 | health_check_status, error_rate, latency_p99, cpu_usage, memory_leak | Prometheus / Datadog / 自研监控 | 错误率突破 SLO、延迟飙升、资源泄漏 |
元数据血缘： 每个制品的元数据并非孤立存在。例如，
build_id 可以关联到 commit_sha，而 deploy_id 又可以关联到 artifact_uri。建立完整的元数据血缘图，是进行根因分析的前提。
3.3 制品元数据与误差预算的映射关系
误差预算（Error Budget）通常定义为 SLO 目标与 100% 之间的差值。供应链中的异常元数据会直接或间接地消耗误差预算。以下映射关系是模型设计的核心：
- 构建失败 → 部署延迟 → 功能交付延期 → 间接消耗误差预算（用户等待新功能的时间成本）。
- 高危漏洞未修复 → 强制回滚 → 服务中断 → 直接消耗误差预算（可用性下降）。
- 部署金丝雀异常 → 暂停发布 → 版本积压 → 累积技术债务 → 长期消耗误差预算。
- 运行时错误率突增 → 触发告警 → 紧急修复 → 消耗维护窗口的误差预算。
3.4 供应链元数据的质量要求
异常检测模型的准确性高度依赖元数据的质量。在构建台账之前，必须对供应链元数据进行以下维度的评估：
| 质量维度 | 要求 | 常见问题 | 治理手段 |
|---|---|---|---|
| 完整性 | 每个制品必须包含所有关键节点的元数据 | 缺少安全扫描记录、部署环境标签缺失 | 强制元数据 Schema、CI/CD 门禁 |
| 一致性 | 同一制品的元数据在不同系统间保持一致 | Git commit SHA 与构建产物中的版本号不匹配 | 统一 ID 生成策略、元数据同步校验 |
| 时效性 | 元数据应在制品流转的 1 分钟内完成更新 | 部署完成 10 分钟后元数据才入库 | 事件驱动架构、实时消息队列 |
| 可追溯性 | 从生产制品可反向追溯到原始代码提交 | 无法定位某个 Docker 镜像对应的 Git commit | 构建时注入版本信息、SBOM 生成 |
注意： 元数据质量问题是误差预算台账异常检测的最大噪声源。如果元数据本身存在缺失或错误，模型将产生大量误报。建议在数据接入层增加元数据质量校验步骤，对不合格数据打标或拒绝入库。
3.5 供应链元数据的采集架构
为了实现实时、可靠的元数据采集，推荐采用事件驱动 + 日志聚合的混合架构：
- 事件驱动：每个供应链节点在状态变更时（如构建完成、部署开始）发布事件到消息队列（Kafka / Pulsar）。消费者服务将事件转换为标准化的元数据记录，写入时序数据库或数据湖。
- 日志聚合：对于无法直接发布事件的遗留系统，通过采集系统日志（如 CI 日志、部署日志），使用正则或 NLP 提取元数据字段。
- 元数据湖：所有元数据统一存储在 Delta Lake / Iceberg 中，支持历史回溯和批量分析，为异常检测模型提供训练数据。