4. 工单生命周期设计
数据问题工单不是一张“待办便签”，而是一条有明确入口、责任转移、质量门禁和知识沉淀的生命周期。如果只定义“谁提、谁改”，工单很容易在“已处理”和“其实没修好”之间反复漂移。本节把工单抽象为六个标准阶段——创建、分派、处理、验证、关闭、复盘，并用状态机约束每个阶段允许的迁移，使工单的每一次流转都可追溯、可判定、可度量。
一、六个标准阶段的职责边界
创建（Created）解决“问题被准确描述”的问题。创建时必须固化四类信息：问题对象（库表、字段、指标、报表或接口）、现象与期望（例如“订单表 order_id 空值率 0.7%，期望为 0”）、影响范围（下游报表、模型、业务方）、发现方式（监控告警、对账差异、人工反馈）。缺少可判定的期望值，工单在验证阶段就无法收敛。
分派（Assigned）解决“责任落到具体的人和系统”的问题。分派依据是问题域归属：源系统采集问题归数据接入负责人，加工逻辑问题归数仓开发，指标口径问题归指标 owner，权限与展示问题归应用侧。分派应记录处理人、协作人、优先级和 SLA 截止时间。
处理（Processing）是真正发生数据变更的阶段。处理人需要给出根因分类（采集延迟、上游变更、逻辑缺陷、脏数据、配置错误等）、修复动作和影响行数。若修复涉及历史数据回刷，必须写明回刷范围与幂等策略，避免“修了增量、漏了存量”。
验证（Verifying）是独立于处理人的质量门禁。验证人按创建时约定的期望值执行校验：空值率、唯一性、枚举分布、对账差额、指标同比环比合理性。验证不通过则退回处理，而不是直接关闭。
关闭（Closed）表示问题已消除且验证通过。关闭时应记录实际修复时间、是否超 SLA、是否触发下游重跑。
复盘（Reviewed）是闭环的最后一环，回答“同类问题如何不再发生”：是否需要新增监控规则、是否要补充字段级约束、是否要更新口径文档。复盘不是追责会，而是把个案转化为规则。
二、状态机：用迁移条件替代口头约定
把上述阶段建模为状态机，关键不在状态名称，而在迁移条件。下面这张状态机图给出了每个状态允许的去向与触发条件，其中“验证不通过”回到处理、“复盘完成”才真正终结工单，是两条最容易被忽略却最重要的边。
三、迁移条件与门禁规则
状态机的价值在于把“能不能往下走”变成可检查的条件。以下规则可直接作为工单系统的校验逻辑：
| 迁移 | 触发条件 | 不满足时的处理 |
|---|---|---|
| 创建 → 分派 | 问题对象、现象、期望值、影响范围四项齐全 | 保持创建态，退回补充信息 |
| 分派 → 处理 | 处理人已认领，SLA 截止时间已写入 | 超时未认领则升级至上级 owner |
| 处理 → 验证 | 已填写根因分类、修复动作、影响行数 | 缺少根因则不允许提交验证 |
| 验证 → 关闭 | 按创建时期望值校验通过，且下游重跑完成 | 退回处理，记录退回次数 |
| 关闭 → 复盘 | 关闭后 3 个工作日内发起复盘 | 超期进入复盘逾期清单 |
四、一个可执行的状态迁移示例
假设监控发现“订单表 order_id 空值率 0.7%”，工单按如下轨迹流转：
状态: Created
问题对象: dwd_order.order_id
现象: 空值率 0.7%（基线 0%）
期望: 空值率 = 0，且历史 7 天数据回刷
影响: 下游 ads_order_daily 指标偏低约 0.6%
状态: Assigned → 处理人: 数仓开发A SLA: 24h
状态: Processing
根因分类: 上游变更（源表字段改名未同步）
修复动作: 修正采集映射 + 回刷 2024-06-01 ~ 2024-06-07
影响行数: 128,430
状态: Verifying
校验: 空值率 = 0 ✔ 唯一性 = 100% ✔ 对账差额 = 0 ✔
状态: Closed → 实际耗时 6h，未超 SLA
状态: Reviewed
产出: 新增 order_id 非空监控规则；更新采集映射文档
注意示例中的“期望值”在创建时就已写死，验证阶段只是执行比对，而不是重新讨论标准。这是状态机能收敛的根本原因。
五、状态机落地时的三个关键约束
- 状态不可跳跃：禁止从“处理”直接跳到“关闭”，所有关闭必须经过验证态，保证每次修复都有独立校验记录。
- 退回必须留痕：每次退回记录退回原因与退回人，用于后续根因统计，而不是简单覆盖状态。
- 复盘是终态而非可选：将“复盘”设为工单的最终状态，未完成复盘的工单不计入闭环率，从机制上保证知识沉淀不被省略。
当六个阶段与迁移条件被固化进工单系统后，数据治理就从“靠人盯”转向“靠状态驱动”：每个工单的当前位置、责任人和下一步动作都清晰可查，闭环率、平均修复时长、退回率等指标也自然成为可运营的治理数据。