# 数据运营平台功能完善计划 > 版本:V1.0 > > 日期:2026-07-29 > > 规划基线:[《DataOps Platform 企业级完整产品功能模块台账》](./FUNCTION_MODULE_CENSUS_20260726.md)第 12 章 > > 适用范围:数据运营与数据治理平台,不扩展为分析开发平台 > > 首期约束:1–5 人团队、单一示范企业、企业内网、Linux + Docker Compose ## 1. 计划定位 本计划不是重新设计产品功能,而是把现有 264 项功能台账转化为可执行的分阶段完善路线。 功能台账继续承担“完整功能基线”的作用;本计划承担“先做什么、后做什么、做到什么程度才算完成”的作用。原台账第 13 章的三个月示范版清单作为早期范围参考,本计划中的“第一阶段”取代它成为后续执行依据。 本次调整的核心是: 1. 三个月内不建设企业 OIDC 单点登录,不把 SSO 作为示范版验收前置条件。 2. 先收口已有、部分建设、工程完成待门禁和隔离分支待合入的能力,再大规模新增功能。 3. 首期围绕设备台账与设备运行维护,优先形成资产、语义、质量、责任、整改、知识和审计的完整闭环。 4. 第二阶段再将设备域能力抽象为可复用的平台能力。 5. 企业统一身份、高可用、多环境、数据市场、插件生态和 SaaS 运营按客户复制与商业化节奏逐步建设。 ## 2. 当前功能基线 截至 2026-07-29,完整台账共 264 项: | 成熟度 | 数量 | 在本计划中的处理方式 | |---|---:|---| | 已建设 | 41 | 持续维护,不重复立项;补齐验收、文档和回归测试 | | 部分建设 | 52 | 优先收口,是前两个阶段的主要投入对象 | | 工程完成,受门禁 | 17 | 优先完成真实环境验证、启用条件和回滚门禁 | | 隔离分支完成,待合入 | 11 | 按业务闭环选择性合入,完成发布副本和接口契约核验 | | 规划中 | 135 | 按业务价值、依赖关系和企业复制需求分期建设 | | 能力预留 | 5 | 暂不进入固定排期,保留架构接口 | | 兼容保留/退役中 | 1 | 维持兼容,满足替代门禁后退役 | | 明确不扩展 | 2 | 不进入产品建设计划 | 当前的主要问题不是完全没有功能,而是四类能力同时存在: - 已有能力分散,用户完成一项治理工作需要跨多个模块。 - 部分功能只有页面、接口或单点能力,还没有形成端到端闭环。 - 一批功能工程上已经完成,但尚未通过生产门禁,不能视为正式可用。 - 规划项数量很大,如果同时推进,会稀释 1–5 人团队的交付能力。 ## 3. 排期原则 ### 3.1 先闭环,后铺开 优先完成“接入—建账—治理—发现问题—整改—复核—追溯”的完整链路,不以完成页面数量作为阶段成果。 ### 3.2 先收口已有能力,后新增大模块 建设优先级依次为: 1. 工程完成但受门禁的能力; 2. 隔离分支完成、与首期闭环直接相关的能力; 3. 已部分建设、补齐后可形成业务闭环的能力; 4. 首期业务闭环不可缺少的规划功能; 5. 企业复制、规模化和生态类规划功能。 ### 3.3 领域验证后再平台化 先在设备域证明设备 UID、实体映射、故障分类、质量闭环和知识问答可用,再抽象为通用主数据、代码集、质量运营和治理知识能力。 ### 3.4 门禁先于完成声明 “代码存在”不等于“功能就绪”。每一阶段都必须同时具备: - 用户可以完成真实业务任务; - 权限、审计和数据边界生效; - 失败可以诊断,关键变更可以回滚; - 部署、升级、备份和恢复经过验证; - 有明确验收记录,不用演示数据替代真实验收。 ### 3.5 企业单点登录不作为首期前置 首期复用本地认证和现有 RBAC。OIDC SSO、Claims 映射、组织同步和生态扫码登录放到企业复制阶段;只有客户明确提出统一认证是上线前置条件时,才提前插入排期。 ## 4. 总体阶段路线 | 阶段 | 时间 | 核心目标 | 主要结果 | |---|---|---|---| | 第一阶段 | 0–3 个月 | 形成设备域可用闭环 | 能接入、能建账、能治理、能整改、能追溯、能交付 | | 第二阶段 | 4–6 个月 | 从设备示范版演进为可复用数据运营平台 | 主动元数据、通用质量运营、统一待办和第二业务域复用 | | 第三阶段 | 7–12 个月 | 达到企业复制和正式试点条件 | SSO、多环境、企业连接器、授权交付、平台可观测和安全集成 | | 第四阶段 | 12–18 个月及以后 | 面向规模化、生态化和商业化 | 高可用、Kubernetes、插件平台、信创、SaaS 与成本治理 | 各阶段采取“阶段目标固定、具体功能可滚动调整”的方式。没有通过上一阶段验收门禁的能力,不因为日历时间到期而自动进入下一阶段。 ## 5. 第一阶段:0–3 个月设备域可用闭环 ### 5.1 阶段目标 在单一示范企业内,使用本地账号和现有 RBAC,接入设备台账、维修和必要的运行信息,形成以下业务闭环: 1. 可以识别并登记设备、部件、位置、组织、责任人和源系统编码。 2. 可以发现跨系统重复设备并进行映射、审核和回滚。 3. 可以统一故障、原因和措施代码,并保留来源和审批记录。 4. 可以执行台账完整性与故障数据质量检查。 5. 可以把质量问题分派给责任人,完成整改、复核和关闭。 6. 可以通过资产搜索、关系图和有证据的知识问答定位设备问题。 7. 可以在企业内网完成部署、备份、恢复、审计和演示验收。 ### 5.2 三个月重新排期 #### 第 1 个月:收口底座,打通接入与建账 | 工作包 | 关联模块 | 交付内容 | 月末门禁 | |---|---|---|---| | 现有能力收口 | CON-14~16、SEM-08~13、DQA-01、DQA-03、DFY-03~12、DFY-14 | 合入首期必需的采集、本体和规则能力;完成接口契约、发布副本和回归核验 | 功能不再依赖隔离分支;工程门禁状态有明确结论 | | 本地身份与设备责任 | IAM-01~05、IAM-11、IAM-17、GOV-03、GOV-04、GOV-14 | 复用本地登录和 RBAC;配置设备资产管理员、治理人员和查看者 | 三类用户只能看到和操作授权范围内的数据 | | 数据源接入 | CON-01~05、CON-09 | 接入设备台账库和维修库;MES/SCADA/IoT 首期只通过数据库或现有 API 采集元数据和必要事件 | 两类核心数据源可重复采集,失败可诊断、可重试 | | 设备资产目录 | CAT-01、CAT-04、CAT-09、CAT-10、CAT-13、CAT-14、CAT-25 | 建立设备、部件、测点、告警和维修记录目录,保留来源与更新时间 | 示例范围内资产有稳定来源、可搜索、可追溯 | | 企业内数据边界 | SEC-08、SEC-10、SEC-11、PLT-05 | 原始数据保留在企业内网,凭据加密,关键操作进入审计 | 不通过接口返回明文凭据;关键操作可按用户追溯 | 第 1 个月不追求完整工业协议接入,不建设统一身份平台,不开展大数据、流平台和 BI 连接器建设。 #### 第 2 个月:完成设备语义和质量整改闭环 | 工作包 | 关联模块 | 交付内容 | 月末门禁 | |---|---|---|---| | 设备统一模型 | SEM-03、SEM-06、SEM-18~21、CAT-14 | 建立设备、部件、位置、组织、责任人和故障代码模型 | 模型可发布、可版本化,关键对象有责任人 | | 实体匹配与回滚 | SEM-15~17 | 规则与 AI 生成匹配候选;高置信度自动映射,其余人工审核;支持撤销 | 每次合并有证据、置信度、审批记录和回滚点 | | 本体工作台 | SEM-08~13、SEM-22 | 合入并收口本体编辑、校验、建议评审、发布和知识同步 | 可完成一次设备本体从草稿到发布的完整流程 | | 台账与故障质量 | DQA-02、DQA-04、DQA-07、OBS-07、OBS-08 | 建立台账完整性、编码一致性、故障原因和维修闭环检查 | 质量结果能够定位到资产、字段和来源 | | 质量问题闭环 | DQA-10、DQA-11、DQA-12、GOV-09、GOV-11、WFC-01 | 问题创建、责任分派、整改、复核、关闭、重开和逾期统计 | 至少完成一批真实问题的端到端整改 | 第 2 个月只建设首期需要的设备领域模型和质量规则,不扩展为通用建模开发平台或无代码开发平台。 #### 第 3 个月:形成运营视图并完成企业内验收 | 工作包 | 关联模块 | 交付内容 | 月末门禁 | |---|---|---|---| | 设备关系与根因 | CAT-16、DQA-13~15、OBS-09、OBS-10 | 建立设备—部件—告警—故障—维修—停机影响关系,输出有证据的根因建议 | 根因结论必须返回来源;无法确认时明确表示证据不足 | | 搜索与知识问答 | CAT-11、KAI-03、KAI-04、KAI-08、KAI-22 | 支持按设备、源 ID、位置、责任人和故障搜索;完成真实模型和设备问答集门禁 | 授权过滤有效,问答引用率达到 100% | | 治理运营看板 | GOV-10、GOV-11、PLT-03、PLT-04 | 展示台账完整率、责任覆盖率、映射率、问题闭环率和复发情况 | 指标可追溯到明细,不使用手工填报结果替代 | | 运行证据与审计 | OBS-01、OBS-02、DFY-22、SEC-11、SEC-12 | 记录采集、规则、发布、合并、审批、整改和问答运行证据 | 失败有日志和状态;关键证据可验证未被篡改 | | 离线交付与恢复 | PLT-01、PLT-02、PLT-05、PLT-09、PLT-10、PLT-17、PLT-25、PLT-26 | 完成安装检查、备份、恢复、升级前检查、数据库迁移和回滚说明 | 在干净环境重装成功,并完成一次恢复演练 | ### 5.3 第一阶段明确不建设 - IAM-06~10、IAM-12、IAM-16:OIDC SSO、IdP 配置、Claims 映射、组织同步、应急 SSO 账号和生态扫码登录。 - 通用企业通讯录同步、完整账号入转调离流程。 - Oracle、SQL Server、大数据、消息流、BI 和企业应用连接器全集。 - 完整数据市场、统一查询网关、行列权限、动态脱敏和自动授权下发。 - Kubernetes、99.95% 高可用、完整容灾、信创认证、多租户 SaaS 和商业许可证。 - NL2SQL、在线分析、BI 开发、无代码开发、移动 App。 - 预测性维护、剩余寿命预测和完整工业时序数据平台。 - n8n 全面退役;首期只保证设备治理和质量执行链路不依赖新增 n8n 能力。 ### 5.4 第一阶段建议验收指标 最终阈值应在项目启动时结合实际数据固化。建议首期采用: | 指标 | 建议验收值 | |---|---:| | 示范范围内核心设备资产入账率 | ≥ 95% | | 设备责任人覆盖率 | ≥ 95% | | 设备源系统编码保留率 | 100% | | 已确认实体映射可回滚率 | 100% | | 台账完整性规则可定位到来源的比例 | 100% | | 首批真实质量问题按流程闭环率 | ≥ 80% | | 设备问答返回来源引用的比例 | 100% | | 关键治理操作审计覆盖率 | 100% | | 备份恢复演练 | 至少成功 1 次 | ### 5.5 第一阶段容量不足时的裁剪线 首期范围不能因为功能台账完整而全部视为同等优先级。团队容量不足时按以下顺序取舍: | 优先级 | 必须保留的结果 | 代表能力 | |---|---|---| | P0:必须完成 | 接入、设备建账、稳定 UID、责任绑定、台账质量、问题整改、审计、部署和恢复 | 没有这些能力就不能形成数据运营闭环 | | P1:应当完成 | 设备本体、故障代码统一、实体审核、资产搜索和有证据问答 | 用于证明跨系统语义治理和知识应用价值 | | P2:容量允许时完成 | 高置信度自动合并、AI 根因建议、复杂关系图和个性化工作台 | 可以提高演示效果,但不能挤占 P0/P1 | P2 未完成不阻塞首期上线;必须保留接口、数据模型和后续接入位置,并记录到第二阶段待办。 ## 6. 第二阶段:4–6 个月平台化与第二业务域复用 ### 6.1 阶段目标 把设备示范版中的领域定制能力抽象为通用平台能力,并选择第二个业务域进行复用验证。重点不再是增加展示页面,而是降低新增业务域的接入和治理成本。 ### 6.2 建设范围 | 能力方向 | 重点模块 | 主要完善内容 | |---|---|---| | 主动元数据 | CAT-03、CAT-05、CAT-09、CAT-10、CAT-17、CAT-22~24、CAT-26 | 自动发现、增量采集、字段血缘、使用热度、健康信号和用户纠错 | | 通用术语与标准 | SEM-02、SEM-04、SEM-07、SEM-14 | 标准版本、业务术语、指标口径和交换格式 | | 通用质量运营 | DQA-05、DQA-06、DQA-08、DQA-09、DQA-12、DQA-13、DQA-15 | 质量趋势、异常、新鲜度、SLA、复发和根因建议 | | 数据可观测 | OBS-03~06 | 数据 SLA、事故、告警治理和业务影响 | | 治理责任体系 | GOV-05~08、GOV-12 | 责任继承、委派、跨域协同、中央策略和排名看板 | | 统一待办与通知 | WFC-03~12、WFC-15 | 通用审批、统一待办、治理工单、站内消息、邮件和运营看板 | | 基础数据产品治理 | MKT-06~08、MKT-14、MKT-15、MKT-23、MKT-24 | 推荐、申请、审批、数据合同和可信交付证明 | | Agent 基础治理 | KAI-11~15、KAI-18~20 | Agent 注册、自治等级、工具授权、风险策略、审计和提示注入防护 | | 通用安全底座 | SEC-02、SEC-03、SEC-05~07、SEC-13、SEC-15、SEC-16 | 分类分级、敏感识别、访问与出域策略、证据保留、SIEM 输出和中国通用合规基线 | | 产品工程收口 | PLT-11~18、PLT-22~26 | 平台监控、容量、多环境基础、发布副本、OpenAPI、迁移和升级 | ### 6.3 阶段门禁 - 第二业务域不修改核心代码即可完成接入、责任配置、质量规则和运营看板。 - 新增数据源、资产类型、质量规则和通知渠道有清晰扩展方式。 - 统一待办覆盖质量、治理、审批和发布任务。 - 数据质量趋势、事故和业务影响能够关联到资产和责任人。 - 形成一套可重复使用的实施模板、初始化数据模板和验收模板。 ## 7. 第三阶段:7–12 个月企业复制与正式试点 ### 7.1 阶段目标 满足第二家企业或集团型客户的正式试点条件。此阶段开始补齐统一身份、多环境、企业连接器、授权交付和生产级运维能力。 ### 7.2 建设范围 | 能力方向 | 重点模块 | 主要完善内容 | |---|---|---| | 企业统一身份 | IAM-06~10、IAM-12、IAM-16、IAM-17 | OIDC、租户 IdP、Claims 映射、组织同步、账号生命周期、应急访问和生态登录 | | 企业连接器 | CON-06、CON-08~13、CON-17~22 | 企业关系库、应用、大数据、流、API、BI、边缘网关、网络边界和连接器 SDK | | 授权与可信交付 | MKT-09~18 | 自动授权、访问网关、行列权限、动态脱敏、订阅、到期回收和用途限制 | | 跨环境发布 | DFY-20、DFY-21、PLT-13~15 | n8n 退役门禁、开发/测试/预生产/生产晋级、差异、审批和回滚 | | 企业协作 | WFC-13、WFC-14 | 企业微信、飞书、钉钉、Webhook、ServiceNow 和 Jira | | 高级 Agent 治理 | KAI-16、KAI-17、KAI-19、KAI-21 | 预算、沙箱、异常处置和受治理插件/MCP | | 企业安全集成 | SEC-14~21 | 法务保全、行业合规、供应链和漏洞治理 | | 企业级运维 | PLT-06~10、PLT-19~21 | Kubernetes、HA、容灾、插件 SDK/仓库/隔离和恢复演练 | ### 7.3 SSO 启动条件 企业单点登录在满足以下条件后启动,不按日期强行开工: 1. 已有明确试点客户将统一认证列为上线前置条件; 2. 客户提供可联调的 IdP 测试环境和管理员; 3. 组织、用户组、角色和数据范围映射规则已经确认; 4. 本地应急管理员、IdP 故障降级和认证审计方案已确定; 5. SSO 工作不会挤占第一阶段设备治理闭环的交付。 ### 7.4 阶段门禁 - 至少两个企业环境可使用同一产品版本并通过配置完成差异化接入。 - SSO 故障时可受控降级,权限和审计不失效。 - 开发到生产的发布、差异、审批、回滚流程经过演练。 - 关键服务具备监控、备份、恢复和容量基线。 - 数据申请、授权、使用、到期回收和审计形成闭环。 ## 8. 第四阶段:12–18 个月及以后规模化建设 第四阶段只在客户数量、部署规模或商业模式明确后启动。 | 能力方向 | 重点模块 | 启动条件 | |---|---|---| | 多租户 SaaS | IAM-14、IAM-15、PLT-30 | 出现 SaaS 交付模式和明确租户隔离需求 | | 商业授权 | PLT-29 | 商业版本、功能包和离线授权模式确定 | | 成本治理 | MKT-19~22 | 平台计算、存储、交付和模型成本达到需要内部核算的规模 | | 信创适配 | PLT-31 | 政务、国企或金融客户给出明确适配清单 | | 白标与国际化 | PLT-27、PLT-28、SEM-05 | 出现多品牌交付或英文用户群 | | 深度安全集成 | SEC-22 | 客户已有 KMS/HSM、堡垒机、DLP 等平台并要求联动 | | 治理成熟度 | GOV-13 | 已完成两个以上业务域并形成稳定运营数据 | | 自动修复 | DQA-16 | 规则准确率、回滚和风险分级达到受控自动执行条件 | 第四阶段仍不改变产品边界:平台专注数据运营与治理,不建设 NL2SQL 分析平台、BI 开发平台、无代码应用开发平台或独立移动 App。 ## 9. 十二个一级模块的分期重点 | 一级模块 | 第一阶段 | 第二阶段 | 第三阶段 | 第四阶段 | |---|---|---|---|---| | 租户、组织与统一身份 | 本地认证、RBAC、责任绑定、认证审计 | 账号生命周期基础完善 | OIDC、Claims、组织同步、应急访问 | 多租户 SaaS 与混合身份边界 | | 治理组织与责任体系 | 设备责任人、治理任务和首期指标 | 责任继承、委派、中央策略和跨域协同 | 集团型治理运营 | 成熟度评估 | | 数据连接与企业侧执行 | 关系库和受限工业元数据接入 | 通用采集和第二业务域适配 | 企业连接器、边缘网关和连接器 SDK | 按行业扩展连接器生态 | | 数据资产目录与主动元数据 | 设备资产、UID、搜索、来源和版本 | 主动元数据、字段血缘、热度和健康信号 | 全类型资产与企业级影响分析 | 大规模资产性能优化 | | 数据标准、语义与本体 | 设备模型、实体映射、故障代码和本体发布 | 通用术语、指标、标准和交换格式 | 跨域语义服务 | 双语语义和规模化本体运营 | | 数据质量与可观测性 | 台账和故障质量、整改、根因关系 | 质量趋势、SLA、事故和业务影响 | 企业级告警、值班和生产 SLA | 受控自动修复 | | 数据市场、授权与可信交付 | 维持现有产品和订单能力 | 申请、合同和合格证 | 网关、授权、脱敏、订阅和回收 | 计量、成本和预算 | | 数据规则、生产线与数据工厂 | 收口质量规则执行门禁 | 通用规则运营和运行监控 | 多环境晋级和 n8n 退役 | 规模化执行和容量优化 | | 治理知识库与 AI Agent | 有证据设备问答和根因解释 | Agent 注册、只读/建议级治理 | 沙箱、预算、异常处置和插件 | 多 Agent 规模化治理 | | 审批、任务与协同运营 | 设备审核和质量整改最小流程 | 通用审批、待办、通知和运营看板 | 企业协作与 ITSM 集成 | 大规模流程运营优化 | | 数据安全、合规与审计 | 凭据保护、基础安全和统一审计 | 分类分级、敏感识别、出域和通用合规 | 行业合规、安全运营和漏洞治理 | KMS/HSM/DLP 深度集成 | | 平台工程与企业交付 | Compose、安装、备份、恢复和升级 | 多环境基础、OpenAPI、迁移和监控 | Kubernetes、HA、容灾和插件平台 | SaaS、许可证、信创、白标和国际化 | ## 10. 持续性工程工作 以下工作不单独作为产品功能展示,但每个阶段都必须持续推进: - 保持业务源码、发布副本和部署产物一致。 - 保持前后端接口与 OpenAPI 契约一致。 - 对权限、审计、数据边界、回滚和失败路径执行回归测试。 - 建立真实环境验收证据,不用单元测试代替部署验收。 - 对数据库迁移、备份、恢复和升级执行可重复演练。 - 对知识问答、实体匹配、根因分析和修复建议维护黄金评测集。 - 每月复核功能成熟度,只有通过验收门禁才允许更新为“已建设”。 ## 11. 团队投入建议 在 1–5 人约束下,建议按能力兼任而不是按模块拆团队: | 角色 | 建议投入 | 主要职责 | |---|---:|---| | 产品与领域负责人 | 0.5–1 人 | 范围、设备领域规则、验收指标和客户协同 | | 后端与数据工程 | 1–2 人 | 连接器、资产、语义、质量、工作流和接口 | | 前端工程 | 0.5–1 人 | 资产目录、本体、质量整改和运营工作台 | | 测试与交付 | 0.5–1 人 | 自动化验证、部署、备份恢复和验收证据 | 如果只有 1–2 人,必须进一步缩小首期范围:保留关系库接入、设备 UID、台账完整性、整改闭环、搜索和审计,AI 实体匹配、根因图谱和复杂工作台顺延。 ## 12. 计划治理与变更规则 ### 12.1 月度复核 每月依据完整功能台账复核一次: - 成熟度是否有证据支持; - 本阶段功能是否仍服务于业务闭环; - 是否存在因为客户要求需要提前的功能; - 是否有低价值功能占用核心团队; - 下一月是否需要调整范围或验收标准。 ### 12.2 功能提前条件 规划功能只有满足以下任一条件才允许提前: - 阻塞当前阶段业务闭环; - 是客户合同或正式上线的明确前置条件; - 是安全、合规或数据边界的强制要求; - 可以较低成本收口现有部分建设能力,并显著降低后续返工。 ### 12.3 功能顺延条件 出现以下情况时应主动顺延: - 依赖数据、领域规则或责任人尚未准备; - 只能形成页面演示,无法形成真实业务闭环; - 验收标准无法定义或无法获得真实数据; - 会挤占当前阶段关键路径; - 属于规模化、生态化或商业化能力,但尚无实际客户需求。 ## 13. 第一阶段最终交付清单 第一阶段完成时,应交付的不只是软件页面,而是一套可复用的示范企业成果: 1. 可部署的软件版本和离线安装说明; 2. 设备域资产模型、数据字典、本体和故障代码集; 3. 数据源接入配置、采集任务和来源证据; 4. 设备 UID 与源系统编码映射台账; 5. 质量规则、质量结果和整改工单; 6. 设备资产搜索、关系图和有证据知识问答; 7. 治理责任、审批记录、运营指标和审计记录; 8. 备份、恢复、升级和回滚验证报告; 9. 首期验收用例、真实问题闭环记录和遗留问题清单; 10. 第二业务域复制所需的模板、配置说明和实施清单。