4、数据契约的治理流程

数据契约不是写完了就完事的。我见过太多团队，契约文档写得漂漂亮亮，往 Wiki 上一扔，半年后再也没人看过。说白了，契约的价值在于「用」，而不在于「写」。

那怎么让契约真正跑起来？需要一套完整的治理流程。我个人习惯把它拆成四个阶段：创建与审批、注册与发现、合规性检查、变更管理。这四个环节串起来，才是一条完整的契约生命周期。

4.1 契约创建与审批

这是契约的「出生证明」。创建阶段如果马虎了，后面全是坑。

4.1.1 谁来创建？

我建议由数据提供方发起。谁生产数据，谁负责写契约。但注意，这不代表消费者可以当甩手掌柜。消费者必须参与需求对齐，否则契约写出来没人用。

4.1.2 创建流程

1. 需求对齐：提供方和消费者坐在一起，明确数据字段、格式、SLA。
2. 模板填充：使用标准化模板，避免自由发挥。模板包含字段定义、约束条件、变更策略等。
3. 内部评审：提供方团队内部过一遍，检查技术可行性。
4. 跨团队审批：涉及敏感数据时，需要数据治理委员会或安全团队签字。

4.1.3 审批矩阵

契约类型	审批人	审批时限	备注
普通业务数据	提供方负责人	1 个工作日	标准流程
敏感数据（PII）	提供方负责人 + 安全团队	3 个工作日	需脱敏方案
跨域数据	数据治理委员会	5 个工作日	需架构评审

4.2 契约注册与发现

契约审批通过后，不能躺在邮件里。必须注册到统一的契约中心，让所有人都能找到。

4.2.1 注册什么？

• 契约元数据：名称、版本、提供方、消费者、创建时间
• 契约内容：字段定义、约束、SLA
• 契约状态：草稿、已审批、已发布、已废弃

4.2.2 发现机制

我推荐两种方式：

• 主动搜索：提供关键词、标签、数据域等检索入口。
• 订阅推送：消费者订阅感兴趣的数据域，契约变更时自动通知。

4.2.3 注册示例

{
  "contractId": "CT-2024-001",
  "name": "用户订单数据契约",
  "version": "1.0.0",
  "provider": "订单服务团队",
  "consumer": "数据分析团队",
  "status": "PUBLISHED",
  "tags": ["电商", "订单", "实时"],
  "createdAt": "2024-01-15T10:00:00Z"
}

4.3 契约合规性检查

契约注册了，不代表它一直有效。数据会变，业务会变，契约也得跟着变。合规性检查就是定期给契约做「体检」。

4.3.1 检查什么？

检查项	检查频率	检查方式
字段一致性	每日	自动比对实际数据与契约定义
SLA 达标率	每周	监控系统拉取指标
安全合规	每月	扫描敏感字段脱敏情况
版本过期	每季度	检查是否有超期未更新的契约

4.3.2 检查结果处理

• 通过：标记为「合规」，更新检查时间戳。
• 警告：轻微偏差，通知提供方限期整改。
• 违规：严重偏差，暂停契约使用，进入变更流程。

4.4 契约变更管理

这是最容易被忽视的环节。很多人觉得契约写好了就不能改，其实恰恰相反——不变更的契约才是死契约。

4.4.1 变更类型

变更类型	示例	影响范围	审批要求
兼容性变更	新增可选字段	小	无需审批，通知即可
非兼容性变更	删除字段、修改类型	大	需消费者确认 + 审批
废弃	下线数据接口	极大	需治理委员会批准

4.4.2 变更流程

1. 发起变更请求：说明变更原因、影响范围、回滚方案。
2. 影响评估：自动扫描所有依赖该契约的消费者。
3. 审批：根据变更类型走不同审批路径。
4. 灰度发布：先在小范围验证，确认无误后全量生效。
5. 通知：所有消费者收到变更通知，附带新版本契约。

4.4.3 版本管理

契约版本号建议遵循 SemVer 规范：

• 主版本：非兼容性变更，如删除字段
• 次版本：兼容性变更，如新增可选字段
• 补丁版本：文档修正、描述优化

# 版本号示例
v1.0.0 → 初始版本
v1.1.0 → 新增可选字段「coupon_id」
v2.0.0 → 删除字段「old_status」，消费者需适配