# 交通数据治理启动执行手册

## 手册概览

| 项目 | 说明 |
|------|------|
| **适用场景** | 交通管理机构（交通归口部门/交通管理部门/高速集团/公交集团等）首次启动系统性数据治理工作 |
| **核心理念** | 数据治理不是IT项目，是管理和组织的变革。没有高层推动、没有部门协同、没有考核运行框架，数据治理必然失败 |
| **关键成功因素** | 一把手挂帅、业务部门参与（不是IT部门唱独角戏）、选对Quick Win、制度+平台+文化三位一体 |
| **总周期** | 6-12个月（组织搭建1个月+资产盘点2个月+标准制定2个月+质量管理持续+安全合规1个月） |
| **交付成果** | 数据治理章程、数据资产目录、数据标准规范、数据质量报告、数据安全分级方案 |
| **核心团队** | 数据治理PM 1人 + 数据架构师1人 + 数据管理员2-3人 + 各业务部门数据对接人 |

---

## 第一阶段：组织搭建（第1-4周）

### 1.1 数据治理委员会成立

**为什么必须先建组织：**
交通数据分布在信号系统/电警系统/卡口系统/122接处警/养护系统/收费系统/公交调度/GPS定位/视频监控等几十个系统中，分属不同业务部门和不同厂商。没有强有力的组织推动，谁都不会主动把自己的数据"交出来"。

**数据治理三层组织架构：**

```
┌──────────────────────────────────────────────────────────┐
│          数据治理指导委员会（每季度1次）                       │
│  主任：单位一把手或分管信息化副管理者/总经理                       │
│  成员：各业务部门主要负责人 + 信息化部门负责人                    │
│  职责：决策数据战略、批准数据行业规范、解决跨部门重大争议、批预算        │
└──────────────────────────────────────────────────────────┘
                          │
┌──────────────────────────────────────────────────────────┐
│          数据治理工作组（每月1-2次）                           │
│  组长：信息化部门负责人                                       │
│  成员：各部门数据专员 + 数据治理团队 + 法务/合规             │
│  职责：制定标准、协调执行、监督质量、验收成果                    │
└──────────────────────────────────────────────────────────┘
                          │
┌──────────────────────────────────────────────────────────┐
│          数据治理执行团队（日常工作）                           │
│  数据管理员（Data Steward）× 每个业务域1人                     │
│  数据工程师 × 2-3人（ETL/数据质量/数据平台）                     │
│  数据架构师 × 1人（数据模型/标准/架构）                          │
└──────────────────────────────────────────────────────────┘
```

### 1.2 数据治理委员会章程模板

```
【XX市交通运输局数据治理委员会章程】

第一条 总则
为加强XX市交通运输数据资产管理，提升数据质量，保障数据安全，促进数据共享，
根据数据安全法规个人信息保护法规等法律法规，成立数据治理委员会（以下简称委员会）。

第二条 职责
1. 审批数据治理战略规划和年度计划
2. 审批数据管理制度和标准规范
3. 协调解决跨部门数据共享和争议
4. 审批数据安全分类分级方案
5. 考核各部门数据治理工作成效

第三条 组成
主任：[管理者/分管副管理者]
副主任：[信息化部门负责人]
委员：[各业务部门负责人 + 法规处/办公室负责人 + 下属单位负责人]

第四条 工作运行框架
1. 委员会每季度召开1次全体会议
2. 重大事项可召开临时会议
3. 决议经半数以上委员同意通过
4. 日常工作由数据治理工作组承担

第五条 考核
将数据治理成效纳入各部门年度绩效考核，权重不低于5%。

第六条 附则
本章程自发布之日起施行。
```

### 1.3 数据专员提名

**数据专员（Data Steward）画像：**

| 要求 | 说明 |
|------|------|
| 岗位要求 | 业务部门正式员工（非外包/非实习生），3年以上业务经验 |
| 能力要求 | 熟悉本部门业务数据，有一定IT素养（不要求编程能力） |
| 时间保障 | 至少投入30%工作时间在数据治理相关事务上 |
| 沟通能力 | 能在业务部门和技术团队之间做"翻译" |
| 直属关系 | 行政上归业务部门管理，数据治理工作向数据治理工作组汇报 |

**数据专员职责清单：**
- [ ] 盘点本部门管理的数据资产（系统、数据表、字段、数据字典）
- [ ] 定义本业务域的数据标准和数据质量规则
- [ ] 对本部门数据的质量负责（数据录入规范、异常数据处理）
- [ ] 审批本部门数据的共享申请
- [ ] 参与数据治理工作组的月度会议
- [ ] 参与数据安全分级工作

### 1.4 RACI矩阵（数据治理职责分工）

| 活动/决策 | 指导委员会 | CIO/信息化负责人 | 数据治理PM | 数据架构师 | 数据管理员 | 业务部门负责人 | 数据专员 | 法务/合规 |
|------|------|------|------|------|------|------|------|------|
| 批准数据战略 | A | R | C | C | C | C | I | I |
| 制定数据标准 | I | A | R | R | C | C | C | C |
| 数据资产盘点 | I | A | R | C | R | I | C | I |
| 数据质量规则定义 | I | I | A | C | R | I | C | I |
| 数据质量监控 | I | I | A | C | R | I | R | I |
| 数据共享审批 | I | I | R | C | I | A | C | C |
| 数据安全分级 | I | A | R | C | C | C | C | C |
| 高层争议解决 | A | R | C | I | I | C | I | I |

> R=负责(Responsible), A=问责(Accountable), C=咨询(Consulted), I=知会(Informed)

---

## 第二阶段：数据资产盘点（第5-12周）

### 2.1 数据系统普查

**数据系统普查问卷（发送给每个业务系统和每类数据源的负责人）：**

| # | 问题 | 回答 |
|---|------|------|
| 1 | 系统/数据源名称 | XX市交通信号控制系统 |
| 2 | 所属部门 | 交通秩序管理处 |
| 3 | 系统供应商 | 海信网络科技 |
| 4 | 上线年份 | 2019 |
| 5 | 系统主要功能 | 信号控制、配时优化、绿波协调 |
| 6 | 数据库类型与版本 | PostgreSQL 12 |
| 7 | 数据表数量（大约） | 45张表 |
| 8 | 核心业务数据表Top 5 | signal_plan、detector_data、intersection_config、green_wave、timing_log |
| 9 | 日增数据量 | 约500MB/天 |
| 10 | 累计数据量 | 约3TB（2019年至今） |
| 11 | 主要数据字段类别 | 路口ID、方向、车道、检测器数据（流量/速度/占有率）、信号灯状态、配时方案 |
| 12 | 是否含个人信息/隐私数据 | 否（仅设备数据和交通统计数据） |
| 13 | 数据更新频率 | 检测数据：1分钟/次；配时方案：按需 |
| 14 | 数据字典是否完备？ | 部分（核心表有文档，辅助表无） |
| 15 | 数据是否已经对外共享？ | 是，通过ModBus TCP接口给指挥中心大屏 |
| 16 | 数据负责人 | 王工（tel:138xxxx） |
| 17 | 供应商技术支持联系人 | 李工（海信，tel:139xxxx） |

### 2.2 数据目录工具选型

**数据目录平台选型考量：**

| 选项 | 适用场景 | 优势 | 局限 |
|------|----------|------|------|
| 商业数据目录（Alation/Collibra/Informatica） | 大型机构、预算充足、需强大自动化能力 | 自动发现、血缘分析、AI标注 | 昂贵（百万级）、复杂、国产化适配待验证 |
| 本地化数据治理平台（阿里DataWorks/华为DataArts/腾讯Wedata） | 预算中等、国产化要求、与云平台绑定 | 与本地化云生态深度集成 | 生态锁定、不完全中立 |
| 开源方案（Apache Atlas/DataHub/Amundsen） | 技术能力强、预算有限 | 免费、可定制 | 需自行部署和运维、UI不够友好 |
| 轻量自建（飞书多维表格+Excel+爬虫脚本） | 起步阶段、数据源较少（<50） | 零成本、快速启动 | 功能弱、不具规模化能力、无血缘分析 |

**起步建议：** 如果数据治理刚刚起步、数据源<50个、团队<5人，强烈建议先用"Excel/飞书多维表格"做数据目录——先有目录，再考虑工具。不要一上来就采购百万级数据治理平台（大概率会变成摆设）。

### 2.3 数据编目流程

**数据资产编目七步法：**

```
Step 1: 识别业务域
  └→ 按业务域切分数据资产（如：信号管控域/违法管理域/事故处理域/出行服务域/公路养护域/综合管理域）
  └→ 输出：业务域清单（通常6-12个域）

Step 2: 识别数据系统
  └→ 每个业务域下有哪些IT系统/数据源？
  └→ 输出：系统-业务域映射表

Step 3: 识别数据集
  └→ 每个系统下有哪些数据表/数据集？
  └→ 输出：数据集清单（标注核心/重要/一般）

Step 4: 识别数据字段
  └→ 每个数据集的核心字段是什么？类型/长度/枚举值/业务含义？
  └→ 输出：字段级数据字典

Step 5: 识别数据关系
  └→ 数据集之间、字段之间的血缘关系和关联关系？
  └→ 输出：数据血缘图（先做核心数据集的）

Step 6: 识别数据流
  └→ 数据从哪来、去哪、以什么方式流转？
  └→ 输出：数据流图

Step 7: 识别数据质量
  └→ 每个数据集的质量状况？（基于数据质量快速评估，见第四阶段）
  └→ 输出：数据质量标注（编目选定注质量等级）
```

**数据资产目录卡片示例：**

| 属性 | 内容 |
|------|------|
| 数据集ID | DS-SC-001 |
| 数据集名称 | 路口实时交通流检测数据 |
| 所属业务域 | 信号管控域（SC） |
| 来源系统 | 交通信号控制系统 |
| 数据描述 | 全市800个路口的线圈/雷达检测器实时交通流数据 |
| 更新频率 | 1分钟/次 |
| 核心字段 | intersection_id, direction, lane_no, volume, speed, occupancy, timestamp |
| 数据量级 | 日增800路口×4方向×3车道×1440分钟≈1400万条/天 |
| 数据质量等级 | B级（完整性90%/准确性95%/及时性优） |
| 数据安全等级 | 一般数据 |
| 数据负责人 | 赵工（秩序处） |
| 技术负责人 | 钱工（信息中心） |
| 共享状态 | 已共享（指挥中心大屏、智能交通管理平台平台） |

### 2.4 数据域定义

**交通数据典型的数据域划分：**

| 数据域 | 域编码 | 包含数据类型 | 拥有部门 |
|--------|--------|------|------|------|
| 交通流检测域 | TF | 线圈/雷达/视频流量、地磁/WiFi探针/ETC采集 | 交管/高速 |
| 交通事件域 | TE | 事故/拥堵/施工/管制/恶劣天气/大型活动 | 指挥中心 |
| 信号管控域 | SC | 信号配时方案、相位相序、绿波带、特勤路线 | 交管/秩序处 |
| 交通违法域 | TV | 电子警察抓拍、卡口过车、违法处理、记分 | 交管/科技处 |
| 基础设施域 | IN | 道路属性、路口渠化、标志标线、信号机/电警点位 | 设施处/养护处 |
| 公共交通域 | PT | 公交线路站点、到离站、客流、支付 | 公交集团 |
| 出行服务域 | MS | 导航数据、共享单车、网约车、停车诱导 | 第三方+停车 |
| 安全应急域 | EM | 应急预案、应急资源、应急演练、指挥调度记录 | 应急办/指挥中心 |
| 资产管理域 | AM | 设备台账、养护记录、资产状态、维修工单 | 养护处/运维 |
| 综合管理域 | GM | 办公OA、人事、财务、公文 | 办公室 |
| 环境气象域 | EN | 气象数据、空气质量、道路积水 | 气象局/环保局 |
| 车路协同域 | VX | V2X消息、RSU状态、OBU数据 | 科技处 |

---

## 第三阶段：标准制定（第9-16周，与第二阶段有重叠）

### 3.1 数据标准框架

**数据标准体系四大组成部分：**

| 标准类型 | 内容 | 示例 |
|----------|------|------|
| **基础标准** | 数据元标准、编码标准、命名规范 | 路口ID编码规则、设备类型码表 |
| **模型标准** | 概念数据模型、逻辑数据模型、物理数据模型 | 交通流事实表+维度表设计 |
| **质量标准** | 数据质量维度定义、质量规则、质量KPI | 完整性>95%、及时性延迟<5分钟 |
| **安全标准** | 数据分类分级、脱敏规则、访问控制策略 | 车牌号脱敏规则、个人信息保护 |

### 3.2 命名规范设计

**数据库对象命名规范：**

| 对象 | 规范 | 示例 | 说明 |
|------|------|------|------|
| 数据库 | `db_<域>_<环境>` | `db_sc_prod` | 信号管控域-生产环境 |
| Schema | `<域>_<子域>` | `sc_detection` | 信号管控域-检测子域 |
| 表 | `<层级>_<域>_<内容>_<粒度>` | `dwd_sc_detector_1min` | DWD层-信号管控域-检测器数据-1分钟粒度 |
| 字段 | `<修饰词>_<主体>_<属性>` 或 `<主体>_<属性>` | `avg_speed` `lane_volume` | 蛇形命名（全小写+下划线） |
| 索引 | `idx_<表名简称>_<字段>` | `idx_detector_1min_ts` | 前缀idx+表简称+字段 |
| 视图 | `v_<域>_<内容>` | `v_sc_intersection_status` | 前缀v_ |
| 存储过程 | `sp_<功能>_<对象>` | `sp_agg_daily_traffic` | 前缀sp_ |

**层级命名规范（数据仓库分层）：**

| 层级 | 前缀 | 说明 |
|------|------|------|
| ODS 操作数据层 | `ods_` | 原始数据，与源系统保持一致 |
| DWD 明细数据层 | `dwd_` | 清洗后的明细数据 |
| DWS 汇总数据层 | `dws_` | 按维度汇总的数据 |
| ADS 应用数据层 | `ads_` | 面向应用的数据产品 |
| DIM 维度层 | `dim_` | 维度表 |

### 3.3 编码标准设计

**交通实体编码规范示例：**

| 实体 | 编码格式 | 示例 | 说明 |
|------|----------|------|------|
| 路口/节点 | 6位行政区划+5位序列号 | 33010200101 | 浙江省杭州市上城区第101号路口 |
| 路段 | 路口ID+"-"+路口ID | 33010200101-33010200105 | 路口101→路口105路段 |
| 信号机 | SC+行政区划4位+序列号4位 | SC33010001 | 杭州市第001号信号机 |
| 电子警察 | EP+行政区划4位+序列号4位 | EP33010512 | 杭州市第0512号电警 |
| 公交站点 | BS+行政区划4位+序列号5位 | BS330100001 | |
| 高速公路 | G+2位编号 | G60 | 沪昆高速 |
| 国省道 | G/S/X/Y+编号 | G104 | 104国道 |
| 区/县 | 行政区划6位 | 330102 | 上城区 |

### 3.4 数据模型设计

**交通数据通用星型模型示例：**

```
事实表：FACT_TRAFFIC_FLOW
├── 维度：DIM_TIME（时间维度）
│   ├── time_key, minute, hour, day, week, month, year
│   ├── is_peak_hour, is_holiday, is_weekend
├── 维度：DIM_INTERSECTION（路口维度）
│   ├── intersection_id, intersection_name, district
│   ├── road_class, lanes_count, signal_controller_type
├── 维度：DIM_DIRECTION（方向维度）
│   ├── direction_id, direction_name（东/南/西/北）
├── 维度：DIM_LANE（车道维度）
│   ├── lane_id, lane_type（直行/左转/右转/掉头）
├── 度量：
│   ├── volume（流量/辆）
│   ├── avg_speed（平均速度/km/h）
│   ├── occupancy（占有率/%）
│   ├── queue_length（排队长度/米）
│   ├── headway（车头时距/秒）
```

---

## 第四阶段：质量管理（第8周开始，持续进行）

### 4.1 数据质量规则设计

**交通数据六大质量维度的规则示例：**

**1. 完整性规则：**
| 规则编号 | 规则描述 | 适用数据集 | 期望值 | 触发条件 |
|----------|----------|------------|--------|----------|
| COMP-001 | 路口ID不能为空 | 交通流检测数据 | 100% | 空值率>0.1%触发告警 |
| COMP-002 | 流量/速度/占有率三个字段至少有一个有值 | 交通流检测数据 | >99% | 三字段全空率>1% |
| COMP-003 | 每条记录必须包含时间戳 | 全部实时数据 | 100% | 时间戳缺失即告警 |

**2. 准确性规则：**
| 规则编号 | 规则描述 | 适用数据集 | 验证方法 | 期望值 |
|----------|----------|------------|----------|--------|
| ACC-001 | 速度值在合理范围内 | 检测器数据 | 0≤speed≤120km/h(城市)或150km/h(高速) | 越界率<0.1% |
| ACC-002 | 占有率在0-100%之间 | 检测器数据 | 0≤occupancy≤100 | 越界率=0 |
| ACC-003 | 路口ID在标准编码库中存在 | 全部路口数据 | 关联DIM_INTERSECTION表 | 匹配率>99% |

**3. 一致性规则：**
| 规则编号 | 规则描述 | 适用数据集 | 验证方法 |
|----------|----------|------------|----------|
| CON-001 | 同一路口来自不同检测器的流量应大致一致(偏差<15%) | 线圈 vs 雷达 vs 视频 | 交叉验证 |
| CON-002 | 一个路口的总进入流量≈总离开流量(误差<10%) | 路口进出流量 | 流入流出平衡检测 |
| CON-003 | 设备状态在信号系统和资产管理系统中的记录应一致 | 信号系统 vs 资产系统 | 定期对账 |

**4. 及时性规则：**
| 规则编号 | 规则描述 | 期望值 | 触发条件 |
|----------|----------|--------|----------|
| TIME-001 | 交通流数据从采集到入湖的延迟 | <1分钟 | 延迟>5分钟告警 |
| TIME-002 | 交通事件从发生到系统记录的延迟 | <30秒 | 延迟>2分钟告警 |
| TIME-003 | 视频AI事件分析延迟 | <3秒 | 延迟>10秒告警 |

**5. 唯一性规则：**
| 规则编号 | 规则描述 | 验证方法 |
|----------|----------|----------|
| UNIQ-001 | (路口ID + 时间戳 + 方向 + 车道)组合应唯一 | GROUP BY 组合, HAVING COUNT(*) > 1 |

**6. 规范性规则：**
| 规则编号 | 规则描述 | 验证方法 |
|----------|----------|----------|
| NORM-001 | 日期格式应符合YYYY-MM-DD HH:MM:SS | 正则表达式验证 |
| NORM-002 | 车牌号码应符合中国车牌标准（含新能源） | 正则表达式验证 |

### 4.2 质量监控仪表板设计

**数据质量仪表板关键指标（给数据治理工作组看）：**

| 仪表板区域 | 展示内容 | 可视化方式 |
|------------|----------|------------|
| 总览 | 全局数据质量得分（加权平均）、变化趋势 | 大数字+趋势图 |
| 按数据域 | 各业务域数据质量得分排名 | 柱状图 |
| 按质量维度 | 完整性/准确性/一致性/及时性/唯一性各维得分 | 雷达图 |
| 按数据源 | 各数据源的质量排名（找出"问题户"） | 热力图 |
| 质量问题趋势 | 新增问题数/解决问题数的周趋势 | 折线图 |
| 问题清单 | 未关闭的质量问题排行（按严重度和时间） | 表格 |

### 4.3 数据质量问题管理流程

```
发现质量问题 → 记录问题工单 → 根因分析 → 制定修复方案
                                        ↓
                              短期修复（数据改错）
                              长期修复（源头系统改造/流程优化）
                                        ↓
                              验证修复效果 → 关闭工单 → 更新质量规则
```

**数据质量问题工单模板：**

| 字段 | 内容 |
|------|------|
| 问题编号 | DQ-2026-0158 |
| 发现时间 | 2026.7.5 14:30 |
| 发现途径 | 自动监控告警/人工发现/用户反馈 |
| 数据集 | 雷达检测器交通流数据 |
| 问题描述 | 路口33010200101（延安路-西湖大道）北方向数据持续3天为0 |
| 质量维度 | 准确性 |
| 严重等级 | 高（影响AI信控模型训练） |
| 影响范围 | 该路口北方向的信控方案推荐 |
| 根因分析 | 该方向雷达传感器故障（已于7.5 15:00确认） |
| 修复方案 | 短期：告警标注该方向数据不可用；长期：更换雷达传感器 |
| 修复责任人 | 钱工（信息中心）/ 海康售后（硬件） |
| 目标修复日期 | 短期7.5 17:00 / 长期7.12 |
| 验证方法 | 数据恢复后连续观察3天 |
| 状态 | 处理中 |

### 4.4 数据质量SLA

**建议的数据质量服务水平协议：**

| 数据等级 | 完整性 | 准确性 | 及时性 | 响应时间 | 修复SLA |
|----------|--------|--------|--------|----------|----------|
| 核心数据（影响安全和核心业务） | ≥99.5% | ≥99% | 实时 | 1小时内响应 | P0:4h, P1:24h |
| 重要数据（影响管理决策） | ≥98% | ≥95% | T+1h内 | 4小时响应 | P1:3d, P2:1w |
| 一般数据（辅助/统计） | ≥95% | ≥90% | T+1d内 | 24小时响应 | P2:2w |

---

## 第五阶段：安全与合规（第12-16周）

### 5.1 数据分类分级

**交通数据三级分类框架：**

| 安全等级 | 定义 | 数据示例 | 保护要求 |
|----------|------|----------|----------|
| **核心数据** | 泄露后可能危及关键交通基础设施与运行安全 | 全市交通信号控制系统控制逻辑与参数、重要桥梁隧道结构监测原始数据、紧急交通管制方案、无人机禁飞区数据 | 最高级别保护：物理隔离或专网、全程加密、操作双人复核、评估审查 |
| **重要数据** | 泄露后可能影响公共利益、交通运行秩序或公民隐私 | 车辆轨迹数据（>50辆车）、高清卡口图片、交通流量全量数据、信号配时方案、ETC交易记录、BRT/地铁客流数据、交通应急预案 | 强保护：加密传输和存储、访问评估审查、脱敏后方可分析 |
| **一般数据** | 泄露后影响有限，但仍有数据管理价值 | 道路静态属性数据、公交线路站点信息、交通统计数据（不含个人/车辆信息）、设备台账、天气数据 | 基本保护：访问控制、日志记录 |

**分类分级工作步骤：**
1. 盘点全部数据资产（利用第二阶段成果）
2. 对每个数据集标注初步安全等级
3. 数据治理工作组审议（特别是"核心/重要 vs 一般"的边界争议）
4. 法务/合规部门审核（确保符合数据安全法规和行业规定）
5. 数据治理指导委员会审批
6. 形成正式《数据分类分级清单》作为制度文件发布

### 5.2 访问控制策略

**最小权限原则的实现：**

| 角色 | 权限范围 | 权限类型 | 确认流程 |
|------|----------|----------|----------|
| 数据分析师 | 一般数据+已脱敏的重要数据（本部门） | 只读 | 部门负责人审批 |
| 数据工程师 | 全部数据（含原始重要数据，不含核心数据） | 读写 | 信息中心负责人审批 |
| 数据管理员 | 所负责业务域的全部数据 | 读写+管理 | 信息中心+业务部门双审批 |
| AI建模工程师 | 已脱敏的训练数据 | 只读 | 信息中心负责人+数据治理PM |
| 外部合作方 | 仅开放数据API中的一般数据 | 只读+限流 | 信息中心负责人+法务 |
| 上级归口部门 | 按数据共享协议约定 | 按协议 | 按数据共享管理办法 |

### 5.3 数据脱敏规则

**交通数据常见脱敏规则表：**

| 数据类型 | 原始数据示例 | 脱敏方式 | 脱敏后示例 |
|----------|------|------|------|
| 车牌号码 | 浙A12345 | 部分掩码（前1后1保留） | 浙A***5 |
| 人脸图片 | (人脸图像) | 高斯模糊/像素化 | (模糊后图像) |
| 身份证号 | 330102199001011234 | 中间10位掩码 | 330***********1234 |
| 手机号 | 13812345678 | 中间4位掩码 | 138****5678 |
| 精确经纬度 | 120.155070, 30.274150 | 精度降低 | 120.155, 30.274（精确到毫分） |
| 车辆VIN码 | LGBH52E05LY123456 | 后6位掩码 | LGBH52E05LY****** |
| ETC卡号 | 6217001234567890123 | 中间掩码 | 6217***********0123 |
| 家庭住址 | 上城区延安路128号3栋502 | 仅保留区级 | 浙江省杭州市上城区**路 |

**脱敏规则实施建议：**
- 生产库中保存原始数据（强访问控制+评估审查）
- 开发/测试/分析环境中使用脱敏数据
- 数据API对外输出默认脱敏（除非有特殊审批）
- 脱敏规则做成自动化引擎，嵌入数据服务层（而非人工操作）

### 5.4 合规检查清单

**数据安全法规合规检查清单：**

- [ ] 是否建立了数据安全管理制度？
- [ ] 是否对数据进行了分类分级？
- [ ] 是否明确了数据安全负责人和管理机构？
- [ ] 是否对数据活动进行了风险评估？（特别是重要数据处理活动）
- [ ] 是否建立了数据安全事件应急预案？
- [ ] 是否对员工进行了数据安全教育培训？
- [ ] 数据出境（如有）是否通过了安全评估？
- [ ] 是否建立了数据安全评估审查运行框架？

**个人信息保护法规合规检查（如果处理个人信息）：**

- [ ] 是否取得个人信息主体的同意（或满足其他合法性基础）？
- [ ] 是否制定了个人信息保护行业规范和告知书？
- [ ] 是否为个人信息主体提供了查询/更正/删除的权利通道？
- [ ] 是否进行了个人信息保护影响评估（PIA）？
- [ ] 是否指定了个人信息保护负责人？
- [ ] 敏感个人信息是否增强了保护措施？
- [ ] 是否建立了个人信息泄露事件的报告运行框架？

**关基保护合规检查（如适用）：**

- [ ] 是否认定了CII（如交通信号控制/交通指挥系统）？
- [ ] 是否设立了专门的安全管理机构？
- [ ] 是否进行了安全检测和风险评估（至少每年1次）？
- [ ] 是否进行了应急演练（至少每年1次）？
- [ ] 安全事件的报告时限是否满足（重大事件30分钟内报告）？
- [ ] 采购的网络产品和服务是否通过了安全审查？

---

## 附A：数据治理成熟度自评表

| 维度 | 初始级(L1) | 部门级(L2) | 组织级(L3) | 量化级(L4) | 引领级(L5) | 当前等级 |
|------|------|------|------|------|------|------|
| 组织与制度 | 无专职数据管理 | 有数据管理兼职人员 | 成立数据治理委员会、有专职数据管理员 | 数据治理纳入绩效考核、定期评估审查 | 数据驱动型组织文化 | |
| 数据资产管理 | 无数据目录 | 个别系统有文档 | 全量数据资产目录、数据字典覆盖核心系统 | 数据目录自动化+血缘分析 | AI驱动的主动元数据管理 | |
| 数据标准 | 无统一标准 | 个别系统的命名规范 | 全组织统一数据标准发布 | 标准落地率监控>90% | 行业标准制定参与者 | |
| 数据质量 | 质量问题靠投诉发现 | 个别系统有质量检查 | 全组织统一的质量规则和监控平台 | 质量自动监控+主动修复 | 质量预测（AI预测数据质量风险） | |
| 数据安全 | 无分类分级 | 有基础的访问控制 | 正式数据分类分级+访问确认流程 | 自动化脱敏+行为评估审查 | 零信任+数据安全AI | |

---

## 附B：干系人沟通模板

**第一次向决策者汇报数据治理的5分钟话术：**
> "管理者好，我们想启动数据治理工作。说简单一点就是——我们单位下面有XX个IT系统，来自XX个厂商，数据互相不互通、质量参差不齐。现在要做智能交通管理平台/AI信控，如果数据基础不牢，上层应用做得再好也是空中楼阁。我建议用半年时间，先做三件事：第一建组织（找专人管数据），第二盘家底（到底有多少数据、哪些好哪些差），第三定标准（统一编码和命名规范）。不需要大预算，关键是需要各部门配合。"

**向业务部门负责人沟通的3分钟话术：**
> "数据治理不是IT部门的事，是帮助你们业务部门用好自己的数据。比如你们每天报的交通运行报告，如果数据自动汇总生成，至少省2个人力。你们遇到的"这个系统数据不准"的问题，数据治理就是要解决这个。需要你们做的很简单：指定一个懂业务的人当数据对接人，每周大概花半天时间。"

**向一线人员沟通的1分钟话术：**
> "大家平时也烦数据重复录入、对不上吧？我们做数据治理，就是想把这些乱源头理清楚，以后你们少手工填表、少打电话问数、少做excel搬运工。"

---

## 附C：Quick Win识别

**数据治理的Quick Win（3个月见效）：**

| Quick Win | 效果 | 投入 | 影响力 |
|-----------|------|------|--------|
| 建立统一路口编码标准 | 多系统路口数据终于能对上号 | 低（只需协调和发文） | 高（解决长期"数据孤岛"的基础问题） |
| 发布第一批数据目录 | 决策者终于知道"我到底有什么数据" | 低（Excel即可） | 高（体现数据治理可视化成果） |
| 修复Top 3数据质量问题 | 最痛的几个数据bug被系统修复 | 中（需协调供应商） | 高（立竿见影，建立信任） |
| 建设数据质量监控大屏 | 决策者能看到"数据质量是什么水平" | 中（需开发资源） | 高（可视化推动持续改进） |
| 交通事故数据自动汇总 | 原来需要3天人工汇总，现在实时出 | 中（需对接122系统） | 高（立竿见影的省人力效果） |

---

## 附D：阻力管理

**常见阻力与应对策略：**

| 阻力 | 来源 | 应对方法 |
|------|------|----------|
| "数据是我们的" | 业务部门不愿共享数据 | 建立"数据共享责任清单"（由指导委员会发文件，明确各部门必须共享的数据）；区分"数据所有权"和"数据共享义务" |
| "没时间配合" | 业务部门日常工作已经很忙 | 纳入绩效考核；先让数据专员只占30%工作——而不是100% |
| "我们系统太老，没法改" | 遗留系统技术债务 | 先不改源系统——建数据治理平台在数据出口做质量校验和清洗 |
| "改了之后出了问题谁负责" | 供应商担心数据共享影响系统稳定性 | 采用旁路/镜像方式获取数据——不侵入源系统（至少初期如此） |
| "搞数据治理钱从哪里来" | 财务部门 | 算一笔账：数据质量问题每年导致多少人力浪费和决策失误 |
| "这又是IT部门搞的，跟我们没关系" | 业务部门 | 联合业务部门定义数据质量规则——不是IT定义规则，是业务部门说"我要求这样的数据" |
| "数据治理没完没了，什么时候是个头" | 决策者 | 分阶段交付：第一期3个月出"数据目录+Top 3质量问题修复"，第二期6个月出"标准体系+质量监控"，持续推进 |

---

> **法律声明**：本手册受著作权相关法律法规保护，未经作者书面授权，禁止任何商业用途（包括但不限于转售、捆绑销售、商业培训、SaaS化服务）。
> **免责声明**：本手册提供的方法论仅供学习参考，不构成任何形式的专业意见。数据安全合规应咨询持牌法律专业人士。
> **作者信息**：yinjianheng（殷健恒）| yinjianheng@foxmail.com | 微信：YJH-yinjianheng
