5.3 治理落地：打标、术语表与所有权

5.3 治理落地：打标、术语表与所有权

本节摘要：治理最容易变成"发文件、贴标签、无人执行"的形式主义，本节反其道而行，只讲三件能自动产生回报的治理武器：标签让分级与合规检查可机器执行，术语表让口径争议有唯一裁判，所有权让每个实体出事时有主。三件武器按"先所有权、再标签、后术语"的顺序落地，每件都给出最小可行做法与常见失败形态。本节承接 5.2 的血缘应用，为 5.4 的质量体系与 5.5 的推广运营提供秩序底座。

从一场失败的"治理专项"说起

某公司的数据治理专项维持了四个月：发了管理办法、组织了培训、动员各团队填报字段分级表。收上来的表格沉睡在共享盘里，平台上的标签寥寥。复盘会上一线工程师说了实话："我在平台外填一遍表、平台内打一遍标，同一件事干两遍，对不起，我只干平台外那遍——那是考核要交的。"

失败的结构性原因：治理动作被设计成平台之外的负担，平台内的状态反而是"副本"。翻盘的关键就一句话——让治理动作只在平台内做一次，且做完立刻有回报。打完标，合规检查自动跑；认领所有权，异常告警自动找你；术语挂接，搜索与血缘自动引用。本节三件武器全部按这个标准设计。

所有权：先让每个实体有主

所有权是三件武器里最该先做的一件，因为它是其余一切治理动作的收件地址：标签没人打是因为没人负责，术语没人维护是因为没有归属。落地用"批量预挂加个人认领"两步走。

批量预挂：按血缘反推——某张表的上游任务全由 A 团队维护，表的所有权就预挂给 A 团队；按命名规律兜底——库前缀、分层前缀都有归属线索。预挂解决"从无到有"，让每个实体至少有组织层面的责任人。个人认领：预挂团队内部指派到人，平台记录认领人与时间。认领要轻量：界面上一次点击完成，别搞审批流——治理认领不是权限申请，别用流程把意愿磨没。

所有权的回报设计是关键：告警路由到认领人、权限申请找到人、质量工单派发到人。当"认领"意味着"会被告警打扰"时，会有工程师抗拒认领；配套的做法是同时让认领意味着话语权——认领人对该实体的口径定义、变更评审有一票参与权。让认领有利可图，比强制摊派可持续得多。

标签：两级体系加默认规则

标签设计的头号错误是只有一级、随手新增。三个月后你会拥有几百个"只有一个实体在用"的孤儿标签，打标彻底失去信息价值。正确做法是两级体系：第一级是受控的固定分类（如敏感级别：公开、内部、敏感、高敏；如数据状态：活跃、疑似废弃、已废弃），第二级是受模板约束的业务标签（如合规主题下的"含个人信息""需脱敏"）。新增标签走小评审，宁缺毋滥。

打标的工程化路径是默认规则批量打标，人工只处理例外：字段名命中手机号、身份证号的正则，自动打"含个人信息"；表在核心域清单里，自动打"核心"；连续多个月无访问且无下游的表，自动打"疑似废弃"。规则本体保持声明式，一条典型的自动打标规则长这样：

rule: auto_tag_personal_info
when:
  field_name_regex: "(?i)(mobile|phone|id_card|身份证|手机号)"
then:
  add_tags: ["含个人信息"]
  add_tag_scope: field
  notify: "governance-stewards"
​

when 声明命中条件，then 声明动作与通知对象——命中即打标并知会治理专员复核。人工只做两件事：复核自动打标的高风险例外，为规则覆盖不了的业务语义补标。回报在 5.1 已经预演过——搜索过滤、合规导出、废弃清理全部吃标签；5.4 的质量策略与 6.3 的访问控制也以标签为输入。一个标签体系撑起四个场景，这是它值得先做两级设计的理由。

一个认领冲刺的实操记录

所有权落地最容易卡在"指派到人"这一步——团队预挂容易，落实到个人会拖成无期。某数据组的做法值得抄：他们把认领做成了双周冲刺。第一周，按领域出认领清单，每张核心表给出建议认领人（按血缘反推的维护者），在数据组例会上现场过一遍，有异议当场改派；第二周，对未认领的实体收口——连续两次出现在未认领清单上的表，直接标记为"疑似无主"，进入废弃评估视野。两个冲刺之后，核心域认领率从三成不到拉到九成以上。

冲刺有效的机理值得说透：它把"治理待办"从无限期的背景任务，变成了有截止时间的具体清单；把认领结果从管理员的后台账本，变成了例会上的公开进度。挂在公开场合的待办，比任何催办消息都有力。

认领动作本身走接口即可批量完成，一次认领请求的最小结构如下，运维脚本按清单循环调用即可：

{
  "proposalType": "PATCH",
  "entityType": "dataset",
  "entityUrn": "urn:li:dataset:urn:li:dataPlatform:hive,dwd.orders,PROD",
  "aspectName": "ownership",
  "patchDetails": {
    "addOwners": [
      { "owner": "urn:li:corpuser:zhang.san", "type": "TECHNICAL_OWNER" }
    ]
  }
}
​

注意这里用的是合并语义而非覆盖——按 3.2 的口诀，人工认领是典型的局部修改，绝不能用整包覆盖把别人认领的条目冲掉。批量脚本跑完后，到界面上抽查十张表核对归属，冲刺就完成了闭环。

术语表：只收有争议的口径

术语表失败的头号方式是贪多：启动就收几百个词条，每个都写得像法条，没人读。有效的做法是从争议开始：把组织里真实发生过口径扯皮的词收进来——"活跃用户"算没算未登录会话、"下单金额"含不含取消单——每个词条写三样东西：定义（一句话说清统计规则）、负责人（口径争议的最终裁判）、挂接实体（这个口径落在哪些指标与表上）。

挂接是术语表区别于共享文档的关键：术语挂到指标实体与表实体上后，5.1 的搜索会把术语作为入口（搜术语直达实体清单），5.2 的血缘解读有了口径依据（改"实付金额"的定义，血缘图直接列出受此口径影响的下游）。术语不再被引用，就会退化成又一份共享盘文档。

💡 术语表的验收标准不是收了多少词条，而是"最近一次口径争议是否通过查术语表而非开会解决"。后者才是它存在的理由。

治理动作的编排：一个季度节奏

三件武器的落地节奏建议：第一个月做所有权（预挂加认领，覆盖核心域），第二个月上标签（先敏感级与状态两级，配默认规则），第三个月收首批术语（十到二十个高争议词）。每月固定展示一次治理回报——自动合规导出省了多少工时、告警路由命中率、术语裁判了几场争议。治理是长跑，每月可见的回报是让长跑不被腰斩的唯一燃料。

本节要点回顾

• 翻盘原则：治理动作只在平台内做一次，且做完立刻产生自动回报。
• 所有权先行：血缘反推预挂加一键认领；让认领同时意味着话语权，而非只是被打扰。
• 标签两级制：固定分类加受控业务标签，默认规则批量打、人工只处理例外。
• 术语从争议出发：只收真实扯过皮的词，定义加负责人加挂接实体三件套，挂接决定生死。
• 季度节奏：所有权、标签、术语依次铺开，每月展示回报，用燃料维持长跑。

秩序立起来了，还差最后一环：让使用者知道"这份数据健不健康"。下一节把质量信息接进地图，取数之前先看体检报告。