3. 数据契约生命周期：契约创建、审批、发布、执行、监控、退役全流程

数据契约不是写一份文档就完事了。它跟咱们写的代码一样，有完整的生命周期。从创建到退役，每个阶段都有坑。我做了这么多年数据治理，见过太多契约“出生即死亡”的案例——签完就没人管了。

说白了，契约的生命周期管理，就是让这份约定真正跑起来、持续生效。下面我把六个阶段拆开讲，每个阶段我都会说一些实际踩过的坑。

3.1 创建：别从零开始，用模板

创建阶段最容易犯的错是什么？让业务方或开发同学从空白文档开始写。我见过一个团队，让数据产品经理手写契约，结果写了三周，格式五花八门，关键字段全漏了。

我个人习惯的做法是：预定义契约模板。模板里把必填字段、可选字段、约束条件都定死。创建时只需要填空，或者从元数据系统自动拉取。

字段类别	必填字段	说明
基础信息	契约名称、版本号、创建人、创建日期	用于标识和追溯
数据资产	数据表名、字段列表、数据源类型	建议从元数据中心自动拉取
质量承诺	完整性阈值、准确性阈值、时效性要求	用数字说话，别写“尽量保证”
消费方信息	消费方系统、负责人、使用场景	明确谁在用、怎么用
约束条件	数据保留期限、脱敏要求、访问权限	合规红线，不能含糊

3.2 审批：三方会签，别搞一言堂

审批环节我踩过最大的坑——让一个人拍板。结果生产者签了，消费者不认；消费者签了，治理团队说不行。

我建议的审批流程是三方会签：

• 数据生产者：确认数据能按承诺的质量产出，资源够不够
• 数据消费者：确认契约满足业务需求，阈值是否合理
• 数据治理委员会：确认契约符合公司数据治理规范，不违反合规要求

审批流最好集成到工单系统里。我曾经在某个项目里，审批全靠邮件往来，结果一个契约审批了两周，邮件链长达47封。后来改成系统流转，平均审批时间压缩到2天。

3.3 发布：版本控制是底线

契约审批通过后，就要发布了。发布不是简单地把文档扔到共享文件夹里。我要求团队必须做到：

1. 版本号递增：每次修改都要升版本，不能覆盖
2. 发布到契约中心：所有消费者和生产者都能看到最新版本
3. 变更通知：发布后自动通知相关方，别等人来问

发布时还要做一件事——绑定数据资产。把契约和具体的数据表、API接口、数据文件做关联。这样后续执行和监控才能自动化。

3.4 执行：运行时校验，别等出事了再查

执行阶段是契约真正发挥作用的地方。说白了，就是在数据流转过程中实时校验。

我习惯把执行分为两个层面：

• 生产者侧：数据产出时，自动校验是否符合契约承诺。比如完整性低于95%就告警
• 消费者侧：数据消费时，校验数据格式、字段是否匹配契约定义

执行阶段最容易出问题的是断流机制。当数据严重违反契约时，要不要切断数据流？我的建议是：

违反程度	处理方式	举例
轻微	告警 + 记录，不中断	完整性92%，阈值95%
中等	告警 + 限流，通知双方协商	数据延迟超过2小时
严重	断流 + 升级处理	敏感数据未脱敏、字段结构变更

3.5 监控：别只看数字，要看趋势

监控不是简单地看“今天有没有违反契约”。我要求团队做趋势监控。

举个例子：某个契约的完整性承诺是99%。今天跌到98.5%，可能不算严重违反。但如果连续7天都在下降，从99%跌到98.5%再到97%，那就要警惕了——数据生产方可能出了系统性问题。

监控指标我建议至少包含：

• 履约率：实际质量 / 承诺质量
• 违反次数：按天/周/月统计
• 平均恢复时间：从违反到恢复花了多久
• 趋势变化：环比、同比

监控数据要可视化。我个人习惯用仪表盘，每天扫一眼。如果发现某个契约的履约率连续三天低于95%，我就会拉上相关方开会。

3.6 退役：不是删除，是归档

契约也有生命周期终点。当数据资产下线、消费方不再使用、或者契约被新版本替代时，就要走退役流程。

退役阶段我强调三点：

1. 不可删除：契约只能标记为“已退役”，不能物理删除。审计要用
2. 数据保留：契约关联的数据，按数据保留策略处理，不能因为契约退役就删数据
3. 通知相关方：退役前要通知所有关联方，确认没有依赖了再走流程

我曾经遇到过一个情况：某个契约退役了，但下游有个报表还在用那个数据源，结果报表跑出来全是空的。就是因为退役前没做依赖分析。后来我要求退役前必须做依赖扫描，确认没有消费者依赖才能退役。