11.1 治理职责与决策权：每条规则都要有人解释、执行和例外审批

数据平台已经有上百条管道。mission_status 在任务系统中表示“任务已结束”，在库存系统中却表示“库存已结算”；两边都自称权威。数据出错后，平台团队说自己只负责运行，业务团队说表不是自己建的，最后没有人能决定哪一种定义应该保留。

数据治理先确定决策权，而不是急着“建一个目录”：谁定义、谁生产、谁执行控制、谁承担影响，发生冲突时由谁裁决。

本课目标

• 区分数据 owner、steward、custodian 与 consumer 的职责；
• 识别关键数据元素并规定权威来源；
• 把原则写成可执行控制、例外和证据；
• 设计数据变更、冲突和退役的治理流程。

1. 治理不是审批数量

治理要让正确使用更容易、错误使用更早暴露。它至少回答：

哪些数据对关键决策重要
业务定义由谁批准
生产质量由谁负责
平台控制由谁实现
谁能访问并用于哪些目的
变更会影响谁、怎样通知
规则冲突和例外由谁裁决
何时保留、归档或删除

如果规则只有 PDF，没有系统控制、负责人和运行证据，它只是愿望。反过来，把所有请求送入中央委员会，会制造排队和影子数据。

2. 四类职责不能含糊

组织名称不同，但角色需要覆盖以下责任：

Data owner

对业务含义、允许用途、质量目标和风险接受负责，拥有最终决策权。owner 应是能调动资源和承担影响的业务负责人，不是默认填一个工程师名字。

Data steward

维护术语、规则、分类和问题队列，协调生产者与消费者。steward 推动日常治理，但不应独自承担所有修复。

Data custodian / platform owner

实现存储、备份、访问控制、加密、日志和平台可靠性。它负责控制的工程实现，不自动拥有业务定义。

Producer 与 consumer

producer 维护生成逻辑和契约；consumer 说明使用场景、验证输出，并在发现问题时反馈。消费者不能因为“只是读取”就不承担误用责任。

一人可以兼任多个角色，但每项决定只能有明确的 accountable owner。

这里的四类是职责分组，producer 与 consumer 仍是不同角色。RACI 中 R 负责执行，A 对决定最终负责，C 提供咨询，I 接收结果。例子可这样分配：

决定或工作	R	A	C	I
定义任务结束状态	任务 steward	任务业务 owner	结算 owner、消费者	平台团队
实现并验证状态映射	producer	任务业务 owner	steward、消费者	平台团队
部署字段访问控制	custodian	平台控制负责人	数据 owner、安全负责人	producer、消费者

这是一份示例职责安排，不是角色名称的统一标准。同一个决定不应靠多个 A 相互等待；涉及不同权威事实的冲突则需要事先指定共同裁决渠道。

3. 从关键数据元素开始

不必第一天治理所有字段。先找 Critical Data Elements（CDE）：它们直接影响财务、运营、安全、合规或关键客户决策。

为每个 CDE 记录：

业务名称与定义
计算口径、单位和粒度
允许值与空值含义
权威来源与派生副本
owner、steward、producer
使用目的和敏感分类
质量 SLO 与控制
下游关键决策
变更和退役流程

“关键”要有理由和复审日期。若所有字段都被标为最高级，治理资源会失去优先级。

4. 权威来源不是“最大那张表”

System of Record 表示某类事实的权威维护边界。例如人员合同由人事系统维护，任务遥测由事件平台记录。分析宽表可以更方便，却不应在没有回写规则时成为身份事实来源。

同一个实体可能有多个权威维度：身份、状态、财务结算分别由不同系统负责。需要定义：

• 主键和身份解析规则；
• 更新顺序与冲突优先级；
• 迟到、更正和撤销怎样传播；
• 权威系统不可用时的临时来源；
• 恢复后怎样对账。

“单一真相源”要求每个事实都有明确的写入权和冲突规则，不要求把所有数据复制到一处。

开头的冲突不一定要选一张表胜出。任务结束与库存结算本来就是两个事实，可分别命名 execution_status 与 settlement_status，维护各自状态机，再明确定义组合出的业务可用状态。把两者塞进同一个布尔字段，只是让争议藏进 schema。

5. 规则必须连接控制与证据

一条治理政策可拆成：

目的：为什么需要这条规则
范围：哪些数据、系统和用途
要求：必须/禁止发生什么
控制：代码、配置或人工步骤怎样执行
证据：日志、检查结果、审批记录保留在哪里
负责人：谁监控和修复
例外：谁能批准、有效多久、补偿控制是什么
复审：何时因环境变化重新评估

例如“敏感字段只供授权用途”需要字段分类、策略执行点、访问日志、定期复核和紧急访问流程，而不是一句口号。

例外应同时记录范围、批准依据、补偿控制与到期动作。例如临时分析权限在截止时间撤销，并验证缓存凭据和派生导出是否也受控；只在工单上写到期日不会让权限自动消失。业务 owner 的内部风险接受也不能覆盖外部法律或合同限制。

6. 联邦执行与中央底线

中央团队适合维护跨域底线：身份、分类、审计格式、互操作标准和重大风险门槛。领域团队更接近数据语义，适合维护定义、质量规则和产品承诺。

联邦治理不是各做各的。它需要：

• 少量不可协商的全局标准；
• 可扩展的领域规则；
• 机器可检查的共同接口；
• 跨域争议裁决机制；
• 对例外、债务和到期时间的可见记录。

7. 数据变更也需要兼容策略

新增可空列通常风险较低，重命名、改单位、改变枚举含义或回填历史则可能破坏下游。

“新增可空列”也要检查消费者约束：按位置读取 CSV、严格校验 schema 或使用 SELECT * 的下游仍可能受影响。把秒改成毫秒却保持同一数值类型，更会绕过纯 schema 检查。兼容性既包括格式，也包括单位、缺失含义和业务解释。

变更流程至少包括：

1. 提案说明语义、技术和隐私影响；
2. 通过血缘识别消费者；
3. 选择兼容窗口、双写或新版本；
4. 发布样例与迁移说明；
5. 监控旧/新口径差异；
6. 消费者确认迁移后退役旧版本；
7. 保留决定与验证证据。

紧急修复可以走快通道，但不能省略事后记录和影响复核。

8. 治理会议要围绕决策

有效治理节奏可包括：

• 每周处理定义冲突和高优先级质量事件；
• 每月审查例外、逾期修复和关键数据 SLO；
• 每季度复核 CDE、用途、保留和 owner；
• 重大变更前进行影响和风险评审。

会议输出必须是决定、负责人、截止时间和证据位置。只汇报仪表盘而不分配行动，会让治理成为观赏性流程。

常见误区

• 平台团队天然是所有数据 owner：平台控制存储，不一定能决定业务语义。
• 建了委员会就有治理：决策权和执行控制仍可能空缺。
• 所有字段同级管理最公平：关键风险反而得不到资源。
• System of Record 必须是一套中央数据库：权威边界可以按事实类型分布。

练习

1. 为 mission_status 写 RACI，并指定最终定义裁决者。
2. 从一个业务流程选出五个 CDE，说明为什么关键。
3. 把“数据必须安全”改写成范围、控制、证据、例外和复审。
4. 为枚举含义变化设计兼容、通知与退役流程。

小结

治理最终要形成可执行的决策系统，而不是继续增加表格。定义、生产、平台和使用责任分开后，冲突才有裁决者，规则才有控制，例外也不会永久化。

下一课把责任落到数据质量运行：哪些指标构成服务承诺，问题发生时是阻断、隔离、降级还是告警。