3、契约生命周期管理：契约的创建、版本控制、审批流程、废弃与归档策略
数据契约不是写一次就完事的。它跟代码一样，有创建、有迭代、有评审、最后还有退役。我见过不少团队，一开始热情高涨地定义了几十个契约，半年后没人维护，变成了一堆「僵尸契约」——没人敢删，也没人敢改。
说白了，契约的生命周期管理，就是让每个契约从生到死都有章可循。这一章，我把这些年踩过的坑和沉淀下来的方法，跟你好好聊聊。
3.1 契约的创建：从「拍脑袋」到「有模板」
创建契约是第一步，也是最容易出问题的一步。我早期带团队时，大家各自写各自的，格式五花八门。有的用 Excel，有的写 Word，还有的直接在 Wiki 上贴一段 Markdown。结果呢？数据消费者根本找不到正确的版本。
我的建议是：统一模板 + 元数据自动填充。
一个标准的契约创建流程，至少包含以下要素：
- 契约标识符：全局唯一，比如
DC-ORDER-001，方便检索和关联。 - 数据实体与字段：明确描述这张契约约束的是哪个表、哪些字段。
- 生产者与消费者：谁负责产出数据，谁在使用数据。
- SLA 承诺：比如「延迟不超过 5 分钟」、「日分区数据必须在 08:00 前就绪」。
- 质量规则：非空率、唯一性、取值范围等。
核心原则：创建契约时，生产者与消费者必须「面对面」确认一次。哪怕只是线上会议，也要双方都在场。我见过太多因为「我以为你知道」而导致的线上事故。
嗯，这里要注意：不要试图在创建阶段就把所有细节写死。契约是活的，初期可以只约定核心字段和关键 SLA，后续逐步完善。
3.2 版本控制：契约即代码
契约的版本管理，我强烈建议跟代码走。为什么？因为数据契约本质上就是一份「配置化的代码」。你想想看，数据表结构会变，业务逻辑会变，SLA 也会调整。没有版本控制，你根本不知道线上跑的是哪个版本的契约。
我个人习惯的做法：
- 契约文件存储在 Git 仓库中，与数据管道代码同库或独立库均可。
- 采用语义化版本号：
MAJOR.MINOR.PATCH。MAJOR：不兼容的变更，比如删除了某个必填字段。MINOR：向后兼容的新增，比如增加了一个可选字段。PATCH：内部修正，比如修正了某个质量规则的阈值。
- 每个版本必须包含变更日志（CHANGELOG），说明谁在什么时间改了什么东西。
避坑指南：我曾经遇到过一个团队，契约版本号直接用「V1」「V2」「V3」这种递增数字。结果 V2 和 V3 之间隔了三个月，没人记得 V2 改了啥。后来我强制要求每次提交必须附带 CHANGELOG，才把这个问题解决掉。
下面是一个简单的契约版本控制示例（YAML 格式）：
# contract-order.yaml
apiVersion: v1
kind: DataContract
metadata:
name: order_created
version: 1.2.0
changelog: |
- 1.2.0: 新增 payment_method 字段 (可选)
- 1.1.0: 将 delivery_time 的 SLA 从 10min 调整为 5min
- 1.0.0: 初始版本
spec:
producer: order-service
consumers:
- analytics-platform
- recommendation-engine
schema:
fields:
- name: order_id
type: string
required: true
- name: user_id
type: string
required: true
- name: payment_method
type: string
required: false
sla:
max_latency: 5m
min_completeness: 0.999
3.3 审批流程：谁说了算？
契约不是一个人能拍板的。生产者要确认「我能产得出来」，消费者要确认「这数据我能用」，平台方要确认「这契约符合规范」。所以，审批流程必须清晰。
我推荐的三级审批模型：
| 审批角色 | 职责 | 关注点 |
|---|---|---|
| 生产者负责人 | 确认数据能按契约产出 | 字段是否存在、SLA 是否可达、质量规则是否合理 |
| 消费者负责人 | 确认契约满足消费需求 | 字段是否够用、SLA 是否满足业务要求 |
| 数据平台管理员 | 确认契约符合平台规范 | 命名规范、版本号合规、元数据完整性 |
审批流程可以嵌入到 Git 的 Pull Request 中。生产者提交契约变更 -> 自动触发质量检查（比如格式校验、字段存在性校验）-> 依次通知三级审批人 -> 全部通过后合并到主分支。
注意：审批流程不要搞成「走过场」。我见过有的团队，审批人连契约内容都没看就直接点「通过」。后来我们加了一条硬性规定：审批人必须在 PR 中留下至少一条评论，说明自己审了什么、有没有问题。这才把审批质量提上来。
3.4 废弃与归档策略：好聚好散
契约也有「退休」的时候。比如某个微服务下线了，或者数据表被重构了。这时候，契约不能直接删掉——万一有消费者还在用呢？
我总结的「三步走」废弃流程：
- 标记为「已废弃」(deprecated)：在契约元数据中标记，并注明废弃原因和替代契约（如果有）。此时契约仍然可用，但会向消费者发出警告。
- 设置冷却期：比如 30 天或 2 个发布周期。给消费者足够的时间迁移到新契约。
- 归档：冷却期结束后，将契约从活跃仓库移入归档仓库。归档后的契约不再生效，但保留历史记录，方便日后审计或回溯。
避坑指南：我曾经处理过一个线上事故，就是因为直接删除了一个「看起来没人用」的契约，结果某个离线报表任务第二天跑不出来。后来我们强制要求：废弃契约必须通知到所有已注册的消费者，并且冷却期内每天发一次提醒邮件。
下面这张图，把整个契约生命周期串起来了：
你看，从创建到归档，每个阶段都有明确的操作和责任人。这样一套流程走下来，契约就不会变成「烂尾楼」。
3.5 小结：生命周期管理的三个关键点
- 创建要规范：统一模板，避免各自为政。
- 版本要可控：用 Git 管理，语义化版本号，附带变更日志。
- 废弃要温柔：给消费者留足迁移时间，归档保留历史。