3、变更发起阶段：变更申请单填写、变更类型分类、影响范围评估
变更发起，是整个审批流程的起点。这一步要是走偏了，后面全是白忙活。我见过太多团队，申请单写得像流水账，类型分类全靠拍脑袋，影响范围评估更是直接跳过——结果呢？上线前才发现数据对不上，回滚成本高得吓人。
说白了，发起阶段的核心就三件事：把申请单填清楚、把变更类型分对、把影响范围评估到位。这三件事做好了，后面的审批、执行、验证环节才能顺畅跑起来。
3.1 变更申请单：别让它变成“填空题”
很多公司的变更申请单，就是个简单的表格，填上“变更名称”、“变更原因”、“变更内容”就完事了。我个人习惯，申请单至少要包含以下字段，才能支撑后续的评估和审批：
| 字段 | 说明 | 示例 |
|---|---|---|
| 变更编号 | 系统自动生成，唯一标识 | CHG-2024-00123 |
| 变更标题 | 一句话概括变更内容 | 用户订单表新增“优惠券ID”字段 |
| 变更类型 | 按分类标准选择（见3.2节） | 结构变更 |
| 变更原因 | 业务或技术背景，为什么必须变 | 支持新营销活动，需记录优惠券使用情况 |
| 变更内容 | 详细描述改了什么，怎么改的 | 在order表新增coupon_id字段，类型bigint，允许为空 |
| 变更前契约 | 当前数据契约的版本或快照 | v2.3.1 |
| 变更后契约 | 预期变更后的契约定义 | v2.4.0（草案） |
| 影响范围 | 初步评估的受影响方（见3.3节） | 下游订单服务、报表系统、数据仓库 |
| 发起人 | 谁提的变更 | 张三（订单团队） |
| 期望完成时间 | 业务要求的deadline | 2024-03-15 |
3.2 变更类型分类：分对了，流程才能走对
变更类型决定了后续的审批路径和风险等级。分错了，要么流程过于繁琐，要么风险失控。我一般把数据契约变更分为以下四类：
- 结构变更：新增/删除/修改字段、表、索引等。这是最常见的变更，影响面通常较大。
- 语义变更：字段含义、枚举值、业务规则发生变化。比如“状态”字段的枚举值从“0/1”改成“A/B/C”。这种变更最容易被忽略，但坑最深。
- 约束变更：非空、唯一、外键等约束条件变化。比如某个字段从“允许为空”改成“必填”。
- 兼容性变更：只增加可选字段、扩展枚举值等，不影响现有消费者。这类变更可以走简化流程。
为什么会这样分类？因为不同类型的变更，对下游的影响是完全不同的。结构变更可能导致下游SQL报错，语义变更可能导致业务逻辑错误，约束变更可能导致数据写入失败。你想想看，如果分错了类，把“语义变更”当成“兼容性变更”来处理，那上线后就是一场灾难。
3.3 影响范围评估：别只盯着自己的“一亩三分地”
影响范围评估，说白了就是回答一个问题：这个变更，会影响到谁？ 很多人只评估了直接下游，忽略了间接下游和离线系统。我个人的评估框架是这样的：
- 直接消费者：所有订阅了该数据契约的实时服务、API、消息队列消费者。
- 间接消费者：通过ETL、数据同步、数据湖等间接使用该数据的系统。
- 离线消费者：数据仓库、报表系统、机器学习模型训练任务等。
- 历史数据：变更是否影响已有数据的解析？比如新增字段对历史数据是安全的，但修改字段类型就可能有问题。
评估的时候，我建议用一张表格来记录：
| 影响维度 | 评估内容 | 风险等级 |
|---|---|---|
| 直接消费者 | 订单服务、支付服务、通知服务 | 高 |
| 间接消费者 | 数据同步任务（MySQL -> ClickHouse） | 中 |
| 离线消费者 | 日报表、月报表、用户画像模型 | 低 |
| 历史数据 | 新增字段不影响历史数据，但需注意默认值 | 低 |
嗯，这里要注意：风险等级不是拍脑袋定的。我一般会结合“影响范围大小”和“变更类型”来综合判断。比如，一个“结构变更”影响了“直接消费者”，那风险等级就是“高”；如果只是“兼容性变更”影响了“离线消费者”，那风险等级就是“低”。
最后，我把变更发起阶段的整体流程画了张图，方便你理解：
这张图把发起阶段的四个步骤串起来了。你可能会问：为什么“评估影响范围”之后才“提交审批”？因为评估结果会直接影响审批路径——高风险变更可能需要更高级别的审批人，甚至需要召开变更评审会。所以，评估不是走形式，而是为后续决策提供依据。
好了，变更发起阶段的内容就这些。记住：申请单是基础，分类是方向，评估是保障。这三步走扎实了，后面的路就好走了。