金融行业数据云平台
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了金融行业数据云平台相关的知识，希望对你有一定的参考价值。
当前，数据成为新的生产要素，数字科技成为新的发展引擎，数字经济浪潮已势不可挡。金融行业各大机构纷纷加大金融科技投入力度，全面提升数字化运营能力，进一步加速了自身数据生态的演进，打造“客户+科技”、“流量经营”、“场景+生态”和“数字化平台”等数字化经营模式，已成为金融行业的发展战略趋势。
在这一背景下，金融行业的发展迫切需要打造统一的数据赋能型云平台，集成数据整合、数据开发、建模分析、质量管控、可视交互等功能，支持同时处理离线数据和在线数据，具备数据化服务能力，提供实时的数据服务，通过数据分析来推进数字化线上/线下经营，促进业务发展，助力金融行业的数字化转型发展。
一、金融行业痛点分析
数据是金融运行的“血液”，金融机构经营也是经营数据。数字化转型本质上是利用数字化的思想、理论、方法和技术实现业务数据化和数据业务化的过程。在数据驱动模式下，数据中台体系能力建设是金融机构强化数据能力较为常见的选择。尽管当前金融行业数据能力建设取得重大进展，但全面数字化转型仍面临较多难题：
1、缺乏统一的数据开发服务平台
传统的大数据建设通过拼接不同厂商的产品和工具来完成，需要花费大量时间来做异构产品的集成适配，费时费力，运维成本高。同时，随着金融机构的发展壮大，各级分支机构、部门之间无法调用数据，进一步阻碍金融机构的发展。
2、数据治理分散，没有形成闭环管理
缺乏数据治理与管理方法论，无法通过工具实施数据标准，缺乏可衡量、可管控的数据质量，难以形成可见、可控、可用、可信的数据资产服务能力。难以定位数据，对有价值数据未能实现充分利用。
3、数据等待时间长，强依赖IT
受制于传统数据库/数据仓库发展的技术路线的制约，在新的互联网背景下，存量客户的优化、激活、流失预警，增量客户的获客、提升、传播的体系仍欠缺，产品、权益丰富但同质化程度比较高，难以针对客户寻求差异化的营销方案触达。
4、数据安全合规挑战大
在数字化过程，数据的全生命周期包括数据收集、存储、使用、加工、传输、提供、公开等过程，数据安全问题也与之伴随而来。在高标准、严法律、强监督等外部因素驱动下，以及数据安全的复杂性、广泛性、共生性，“安全用数“成为金融机构当前业务稳定运行和创新发展的迫切需要。
二、金融行业数据云平台总体规划
云和大数据技术的普及和演变，数据湖和数据仓库的边界正在慢慢模糊，数据湖自身的治理能力、数据仓库延伸到外部存储的能力都在加强，湖仓一体的出现让数据管理的灵活性与成长性得到了统一。同时，企业数字化转型促使更多业务型数据消费角色的出现，数据管理要求从传统模式演变为开发管控一体化模式。
针对金融机构的数据云平台建设将从“平台” 、“数据”、“应用” 三方面考虑规划实施，以平台建设是支撑，数据治理是基础，应用是效益打造具有大数据能力基础，实现从数据到资产，提供可视化、智能化的湖仓一体数据云平台。
相信大数据平台、数据中台、算法中台这些名词，大家都耳熟能详了。那什么是数据云平台？
“数据云平台”是新一代的敏捷数据管理平台，以跨平台、云原生、自主可控为技术内核，提供敏捷的一站式数据开发、数据治理和数据交付能力，实现企业数据资产化，数据业务化，支撑企业的数智化、场景化和个性化的应用，最终帮助企业有效应对大规模、强敏态、高时效、智能化等愈发明显的数字化趋势。
数据云平台架构
- 平台：大数据能力的基础
通过构建数据集成开发平台实现数据快速加工，打通包括客户、产品、销售、风险管理在内的各类数据，并快速生成数据平台类目体系。
- 数据：从数据到资产
基于人、物、场景打通数据链接，建设有扩展能力与服务能力的统一数据中心，让数据可流动、可计量、可管控、可增值，挖掘数据价值使数据以服务化的方式实现业务增值及创造新的数据业务。
- 应用：数据能力的表现
基于内部数据汇集加工而成标签对客户、直销员、产品建立画像模型，为客户关怀、精准营销、风控模型等数据应用服务提供数据以及应用的支撑。
三、金融行业数据云平台建设方案
针对数据云平台建设，将通过四个阶段先后实施满足数据工程、数据治理、数据服务、数据规范等功能，助力金融行业数字化驱动业务发展。
第一阶段 数据工程-离线开发
数据集成：表集成、数据复制、数据源
实现从关系型数据库及Teradata数据集成到Hive；从HDFS到Hive以及Hive到HDFS的数据集成，支持更多的关系型数据库以及非关系型数据库数据源连接。
批量数据开发：任务开发、工作流编排、调度配置
实现HiveSQL、Shell、Pyhton等脚本的IDE模式开发；实现编排工作流，配置任务依赖以及工作流依赖功能；实现配置cron表达式定时执行工作流功能。
调度监控：触发调度、任务配置、监控告警
实现工作流定时周期调度或手动触发调度功能；实现配置任务并发度、失败重试以及超时失败功能；实现工作流监控并且失败告警功能。
建设关键点01：数据权限设计
- 权限分配到部门或项目；
- 隶属某个部门的用户获得该部门的所有数据权限；
- 作为成员加入到某个项目的用户获得该项目的所有数据权限；
- 部门和项目对应LDAP用户组；
- 将部门和项目对应的LDAP用户组添加到用户的用户组列表里
建设关键点02：开发管控一体化
（1）从开发角度看管控，通过数据建模来统一指标和模型，并通过模型生成开发代码，保障了设计态和生产态的一致性。
（2）从管控角度看开发，实现数据从开发到上线的全流程自动无感管控和治理，保障数据开发的效率和质量。
第二阶段数据治理
元数据管理：元模型管理、元模型采集、数据/任务地图、数据血缘、元数据差异分析
实现可自定义配置元模型属性的元模型管理；实现定时采集分行项目、工作流以及库表元数据功能；实现数据/任务地图进行快速找数功能；实现查看表血缘关系，支持去除操作节点、查看上游\\下游功能；实现表差异化管理，并分析表当前版本与上一个版本的差异化对比功能。
数据安全：数据权限、数据脱敏、数据全生命周期、资产概览
实现通过数据地图申请表数据的读写权限，并生成对应的审批流程；实现配置表的脱敏字段以及对应的脱敏函数功能；实现配置表生命周期，并根据配置对表数据进行归档或删除功能；实现统计平台项目、工作流、任务、库、表以及字段等资产信息。
建设关键点03：全域数据资产管理
统一元数据体系建设，保障了底层保持唯一性，丰富字段说明；中间层提供元数据控制中心；顶层提供标准统一的数据应用出口。敏捷数据云平台能够发现企业全域的数据资产信息，并将其按照一定的分类进行组织和描述，让数据消费者能够通过智能检索找到分析所需的数据，并清晰地理解数据背后的完整含义。
第三阶段数据服务、数据工程
数据API：API开发、API发布、API监控、API管理、API集市
实现基于Impala\\Mysql连接的SQL语言API功能开发；实现将DataToAPI/URLAPI发布到k8s功能；实现监控已发布的API状态，并实现失败告警功能；实现API加密，需要申请获取对应的API应用才能有权限进行API调用；实现API集市共享API，用户通过API集市查找需要的API并申请使用。
数据探索：统一查询界面、 安全集成、 统一查询引擎
实现Hive、Impala、Mysql以及Moonbox等数据源的统一数据查询功能；实现权限隔离，根据不同的用户分配不同的权限进行查询功能；实现统一查询引擎功能。
数据科学：实现集成Notebook、Spark以及Kubernetes功能
建设关键点04：从数据到API
支持在线对API的开发，在项目空间内通过SQL对数据表的适配，实现API的开发；
可实现SQL数据预览，并自动解析SQL获取API的入参和出参，定义参数属性；
完善服务基本信息，包括服务名称、服务有效时间、服务简介、内容详情；
每个API是一个pod（易管理、可针对高使用频率的API独立横向拓展、调用无需查询数据库获取SQL语句【共同pod存在该问题】）。
第四阶段数据工程、数据规范
实时数据开发：实现基于IDE模式的FlinkSQL作业开发功能；实现支持Kafka、Hbase、JDBC等多种数据源的虚拟表构建功能；实现对实时作业运行结果集采样功能；实现将实时作业结果通过查询过滤发布成API功能；实现用户编写FlinkJar，并通过实时平台统一运行监控功能。
模型设计：实现基于维度建模的维度逻辑表、事实逻辑表以及汇总逻辑表的创建功能；实现将逻辑表批量物理化到44家分行的功能；实现规范化主题域管理，并且主题域支持不同的类型分组维护。
建设关键点05：数据实施开发计
传统统数据整合方法受制于各类开发工具、数据开发人员、ETL 研发流程与数据架构设计等因素，少则几天，多则数周才能获得结果，而数造科技数据开发管理技术可以实时响应数据需求。对于数据及时性要求较高，有实时计算的场景，例如精准推荐、实时风控、安全生产监控等应用的，可以提供实时数据开发平台满足实时数据、指标的开发。
四、金融数据云平台建设优势
随着方案的逐步落地与推广，数造科技帮助金融行业客户实现统一、自助、智能的数据云平台管理模式，提供了数据自助开发能力、数据自助分析能力、数据治理能力，为未来数字化转型发展与数据管理务实了基础。
1、统一的数据开发管控平台
一站式数据开发平台具有强大的数据集成能力，支持大规模混合结构数据集成，统一的数据探索能力，多种数据探索方式和工具结合，并且解决了以往数据开发过程复杂、协作困难的问题。分别从管理域、开发域、流程域，结合金融机构不同场景积累成熟的数据能力解决方案，提供数据全生命周期的全流程服务。
2、提升数据治理能力
围绕金融行业的标准进行数据治理的延伸；提供分支机构的数据服务接口，简化数据资产共享机制。同时，以维度建模为理论基础进行体系化建模，以事前治理的理念驱动，让元数据贯穿其中的建模流程，上承指标、维度的定义，下接实际的数据生产，提前对数据进行规范约束，减少后期的数据治理的复杂度。
3、快速响应数据需求
数据地图让企业告别取数低效的烦恼，快速搜数据、查数据，取数和开发效率提升可达100%。BI服务支持上万个仪表盘、近十万个工作表上线，实现通过数据分析工具，让数据转换为知识，提升行内数字化精细化经营的洞察能力，从数据相关性到业务因果分析，促进高价值数据使用。
4、满足数据安全合规
在统一的数据云平台中，金融机构的数据开发任务从设计态到运营态，且跨开发环境、测试环境和生产环境的任务发布流程保障在统一的平台中闭环完成，使数据开发过程更标准化、协作性更强、安全性更高。同时，通过数据地图申请表数据的读写权限，对敏感数据进行脱敏，满足金融行业的数据安全合规。
某大型金融机构新一代云运营平台的架构设计和实施经验分享
【导读】本文以金融行业数字化转型为背景，对金融行业私有云建设中云运营平台建设的实践进行总结，探索出适合金融行业的新一代云管平台设计路线：从业务需求和使用者角度出发，解耦云运营平台和管理平台，解决行业中云管规划混乱的问题，降低运营成本，提高资源利用率，赋能业务持续创新发展。
【作者】李彪朋，某大型金融单位数据中心产品经理，云运营平台规划、建设负责人，擅长云计算领域产品设计与系统整合。
随着现代金融数据中心的建设，金融机构通过大规模的私有云建设，不断推进云计算在金融行业的落地。在私有云部署建设的推进中，企业对云的诉求也越来越高，从初期的IaaS层资源管理需求，逐步发展到PaaS、SaaS及现有工具平台的一体化运营整合需求。云运营应运而生，以云资源管理为出发点，整合云产品、云服务，满足企业对云基础设施能力的需求，从而进一步保障、提速企业业务的发展。
一、云运营平台建设的需求及痛点
在大型金融行业中，对于综合性云运营平台的持续建设，通常有以下几点需求：
1、多云管理、混合云弹性部署需求
金融企业数据中心存在多种应用环境及区域，包括测试环境、预生产环境、生产环境，各个环境下又包括核心区、非核心区、互联网隔离区等，单一云平台存在规模上限，因此需要建设多套云平台满足业务需求。另外，在营销高峰时期，系统对计算、存储、网络资源的需求呈现井喷式增长，但随着营销的结束，资源的需求量随即下降。
因此，云运营平台需要具备多种云环境的管理能力，在资源的需求高峰时期，具备对行业金融云（混合云）的快速调度能力，支持应用的混合云弹性部署。
2、现有平台的集成整合及数据开放需求
大型金融企业的应用运维部门在数十年的发展过程中，其内部的流程管理体系、监控告警体系、配置管理体系已然成形，并渗透到企业IT管理的方方面面。云运营平台的设计和建设需要全盘考虑，向下对接和纳管不同类型的IT基础设施平台，横向对接现有流程、监控体系，通过周边系统的有效融合，实现IT信息的互通、共享和交互，实现企业内部信息的数据开放及收敛。
3、产品及服务标准自动化需求
云产品及云服务大规模上线，后台需要具备强大的云产品及服务模型的支撑能力，模型需要根据业务场景的变化进行快速迭代，包括数据结构的变化及数据字典的调整，需要构造灵活的云产品及服务模型，以减少大量的重复开发工作；同时，云产品及服务在标准化之后，需要具备自动化实施的能力，实施包括执行、检查、输入/输出参数，因此在定义模型的过程中，同样需要具备自动化任务编排、调度能力。
4、应用部署生命周期需求
部署生命周期包括上线、调整、下线三大核心场景，三大场景囊括了所有云产品及云服务，平台需要支撑需求方在任意时段提出的系统部署需求，且具备快速的自动化响应落地能力。同时，系统部署信息对系统的长期运维至关重要，需要将部署的应用基本信息、云资源信息、业务开发运维人员信息、架构信息、安全信息、监控信息等沉淀在平台进行维护（相当于企业CMDB+），在新旧运维人员交替及部署信息变化的过程中，通过平台可以实时且真实地反映系统部署的现状及过去。
5、虚拟计费及SLA管理需求
在数据中心应用的长期运维过程中，容量和成本管理至关重要。公有云通过资源收费推动企业对云资源成本进行核算，在私有云领域，一般项目得到批复后，资源便是长期性的占用，即使系统已经没人使用和维护，也很少有应用主动下线。因此，在云运营建设体系里，有必要通过虚拟计费进行成本核算，以满足系统立项批复后的资源配额下发、资源计量统计需求，以推进业务的良性发展。同时大量的云产品及服务的落地，需要有效的SLA管理，以保证云服务的交付质量，确保云上的各项服务能够实现高可用、高可靠的特性。
云平台的建设在数据中心中是持续迭代的过程。稍具规模的数据中心本身就具备各类成熟的运维管理平台，如CMDB、监控、云资源管理平台、云数据库管理平台、日志平台等。由于专业分工不同，这些平台散落在不同室、团队，各自分散管理维护。随着数据中心的规模化建设，由于平台分散而引发的资源管理标准、应用部署管理、数据开放与治理问题层出不穷。如何在架构设计上将运营服务与管理服务解耦，突出云管的运营和服务特性，成为亟待解决的痛点。
如果把数据中心看作一个人体，云运营就是数据中心的“骨架”和“血脉”。以引入业界成熟的云管产品为基础，对接和驱动已有的各类运维和管理平台，建设统一云运营平台，实现数据中心云运营架构升级及一体化管理迫在眉睫。
二、云管的技术方案选型
基于企业自身的业务需求及参考云计算行业发展的趋势，高效上云已是金融行业的普遍诉求，各类云运营（云管）平台也是遍地开花，提供此类产品及服务的厂商层出不穷。大趋势之下，金融行业需要尽早、尽快地响应社区技术发展潮流，推进自身运维、运营的转型升级，以持续支撑业务发展。
基于自身云运营建设背景及业界技术发展趋势，云运营基础技术产品选型需具备以下基本条件：
1、运营自助化：云资源服务自助化，按需获取资源；掌握云资源使用情况，资源和服务运营管理统一化；
2、资源管理能力整合：对多种云平台基础资源统一和完备生命周期监测、管理与部署调度，构建覆盖IaaS、PaaS、SaaS的云服务治理体系；
3、运维自动化：提供对云和非云资源统一监控管理、自动化运维管理、全生命周期管理、流程管理，自动化完成云端资源部署，提供物理装机、软件一键式部署、资源批量部署等运维自动化管理。
4、结构一体化：具备灵活开放的API适配连接周边平台，统一的运营管理和计费计量能力。
通过对业界云管产品的充分调研和相关测试，我们最终选择了博云的云管产品BeyondCMP，该产品符合以上基本条件，并具备灵活的定制化本地开发能力，可以响应和适配企业现有基础平台。因此，我们以博云的云管产品为原型进行方案设计与整合，通过二次开发来建设满足生产实际需求的云运营平台。
三、建设目标、原则与思路
1、建设目标
建设统一化云运营平台，覆盖并打通传统运维与云运维，对下整合各类运维管理工具，对上提供统一的云服务能力；在云资源之上提供以应用为中心的场景化工具的同时，提供精细化的度量运营分析与运行保障能力。
2、建设思路
基于需求痛点及技术方案选型特点，总体建设思路需要围绕“六个化”：管理统一化、工具场景化、业务流程化、服务自助化、运营计量化、响应自动化进行展开。
统一化管理：统一化管理物理机、网络、云平台、应用、服务等对象，维护全局的对象关系与基础运行数据。
自助化服务：提供各类云资源或云服务通过产品形式对外发布，需求方可以自助式进行资源申请，提高IT运营效率。
计量化运营：围绕云资源、云服务、应用、需求方等管理对象，实现运营过程可计量，能够从资源统计、应用上、下线效率分析等多个场景提供数据支撑。
应用场景化工具：聚焦部署上线、调整、下线三大核心业务场景，满足统一运营技术要求。
流程化业务：梳理关键资源或部署服务申请流程，形成覆盖资源申请、网络开通、业务上线、配置变更等过程的流程化，支持可自定义流程。
自动化响应：针对常态响应式运维场景，提供覆盖应用用户创建、启动项管理、定时任务管理、路由添加等工具支持，覆盖应用运营的全场景。
3、建设原则
统一性原则：统一规划、统一标准、统一设计、统一建设、统一管理。
先进性原则：采用业界先进、成熟的技术作为整个系统的技术架构，同时借鉴同领域的先进实践经验，做到可用性高，信息及时、运行高效，界面友好，升级和扩展性强的基础环境平台。
业务驱动原则：系统建设需求来自应用实际业务需求，充分考虑运营部署管理痛点，构建满足业务运营部署管理的平台。
科学规划原则：根据业务发展和技术发展的趋势，对平台功能范围进行科学合理的分析与规划，确保在投入产出和未来业务发展支撑两个维度获得平衡。
安全性原则：构建多级安全体系，统一安全管理，多级授权、数据访问安全控制，考虑容灾容错；从系统结构、设计方案、技术保障等方面综合考虑。
可拓展性原则：充分考虑业务未来发展的需要，尽可能设计简明，降低各功能模块耦合度，并充分考虑兼容性。
四、方案设计
参照博云云管的产品设计架构，以及公有云通用的方案设计，云运营平台往下定义两个子平台、五个功能域。一方面，聚焦应用部署集中控制台建设；另一方面，聚焦云产品标准自动化建设，实现集团内统一云运营门户体系。
1、功能定位及与周边系统关系
云运营平台功能定位：
云运营平台与周边系统关系：
在设计和建设的同时，通过API通道、数据库通道、命令行通道和这些已经稳定运行的系统进行交互，有效融合周边系统，实现IT信息的互通、共享和交互，实现企业内部信息的数据开放及收敛。
2、平台管理
数据中心云化是大势所趋。云上规划越来越宏大、功能点越来越多，各类极具专业特色的运营平台层出不穷。按照通俗定义，所谓“云”即是“平台”，云运营是对专业平台的运营，因此云运营是横向的，是统一数据中心所有平台、所有能力的高度集成化平台。
云运营核心是规划和打造“两把剑”。“一把剑”给租户，通过自服务平台运用云产品及应用管理能力；“一把剑”给专业领域管理员，通过管控平台管控数据中心内容建设及资源运营。“两把剑”统一在云运营下进行整体规划、打磨，实现将离散的专业平台形成合力，基于云运营实现数据中心能力的统一。
2.1 自服务平台
面向用户侧的自服务平台，由需求方查看云产品、云服务信息，提交应用部署需求、查看应用部署信息。
随着企业规模扩大，业务快速发展，应用部署需求爆发式增长，系统、安全、网络和应用运维等领域均出现不同程度的交付瓶颈。云运营上线之前，需求的提交和交付是通过传统服务单的形式进行，服务单下分派各种服务工单，由各专业团队分别手工实施、汇总传递交付数据。
在规模化云时代，传统交付模式难以应付快速增长的应用需求，不同专业领域产品的用户体验、交付形式和标准各有特点难以统一，手工传递需求信息的过程也容易信息失真误差，存在返工风险。因此在设计自服务平台时，我们着重将自助化、统一化、自动化、一体化作为平台设计的基本条件。
自服务平台产品门户集中所有云产品和云服务，各个专业领域产品统一模型结构和用户体验，用户所有操作起于此、终于此。产品通过订单的形式进行管理，实现快捷、自助和标准交付。自助化的云产品和云服务设计，不仅大大提升运营效率，加快需求交付周期，同时大幅降低运营成本，释放生产力。原有人力可以将更多时间、精力投入到更多专业领域云产品和云服务的标准化能力建设，实现数据中心自动化、智能化运营的正反馈。
控制台在应用管理运营上，打破现有专业平台系统间的数据墙和作业墙。通过数据同步的方式将数据集中在云运营应用管理控制页面，包括系统信息、资源信息、监控信息、安全信息等各领域融合数据，具备高度的综合信息管理和查询能力。同时将CMDB天然融合到云运营的建设过程中，实质上同步实现了CMDB可视化。通过标准API封装，在执行层面将应用作业能力和作业工具进行插件化集成，快速扩展应用在线维护、扩缩容等能力，相当于应用集中作业台。
2.2 管控平台
面向管理侧的云产品、云服务综合管理平台，支持对云产品、云属性配置，对平台数据进行综合运营管理。
从大型互联网IT企业的演进和发展来看，随着企业IT设施膨胀，大多都会向云计算集成服务商方向进化，因为云实现了数据中心的统一以及运维能力的富余输出。集团对云运营本身的定位与公有云目标类似，不仅需要租户侧统一，也需要管控侧统一企业所有专业管理平台，将其能力与数据集成，形成数据中心的统一管理端。管控端主要侧重产品运营和平台运营。
产品运营是面向租户侧提供的云产品和云服务的运营管理。在产品运营里对各类云产品和云服务的参数进行维护，包括数据和模型维护、已有实例维护、容量维护、订单审批和执行维护、任务执行逻辑控制和异常业务维护等。产品运营集中能够极大地提升产品运营效率，一个界面即可掌握整个数据中心的所有需求、实例现状。
平台运营主要为支撑云的功能、数据和内容扩展。平台发展过程中，需要不断接入云产品和云服务，对接纳管新的专业平台。平台运营功能上需要灵活可扩展以不断适应新的应用运营部署场景，数据上需要将逐步积累的企业运维数据和应用部署数据进行全局管理，包括自动标签化、手动标签化等站在平台维度进行分级分类、画像等，再辅以虚拟计费，对各个层面应用进行成本考核，统筹数据中心运营和管理。
3、功能域设计
自服务平台和管控平台向下细分五大功能域，分别为产品门户、控制台、产品运营、平台运营和平台管理，下面对五大功能域的设计结构和集成内容进行概要介绍。
3.1 产品门户
产品介绍
通过统一的产品门户，为使用者提供资源或运维类产品的介绍与展示。
产品申请
基于产品运营的统一产品模型配置，灵活定义产品申请的可视化界面，为使用者提供简单、便捷地交互体验。
产品购物车
提供使用者类似公有云产品的申请体验，支持多种产品一次申请，提升产品申请效率。
产品文档
提供使用者平台使用、产品申请、申请审批、问题排查等各类产品及运维类在线文档，提升平台帮助体系。
3.2 控制台
我的应用
提供应用系统操作及运维的统一入口，方便使用者统一管理自有应用，构建应用为核心的交互体系。
代办工单
提供运维评审、实施方工单处理工作台，提升资源或运维操作工单的处理效率。
我的资源
提供申请后资源的统一展示、统一管理。
我的需求
提供申请后需求展示、处理、实施、统计等全生命周期管理。
3.3 产品运营
产品模型
构建产品资源模型，为产品门户提供统一模型配置及配置展示。
资源列表
统一管理产品资源清单，维护、展示每类产品内的资源列表，方便产品运营方对资源的统一管理。
产品配置
为产品门户内产品申请所依赖的各类配置或规格信息提供统一配置与管理功能，灵活定义规格、区域等产品资源依赖信息。
产品任务
为资源运维方提供产品自动化实施任务的统一配置与统一管理，方便运维人员针对产品自动化实施任务的问题分析与排查。
3.4 平台运营
内容发布
提供方便、灵活、可扩展的产品介绍、展示内容的定义及发布。
方案管理
建立在部署方案基础上，提供面向应用的资源、人员、架构、安全的统一管理。
任务编排
提供基于脚本、API接口等混合调用编排的能力，利用编排能力，构建产品资源自动化实施与运维场景，提升平台可扩展能力。
采集检查
提供面向各类资源、环境的采集能力，提升资源采集效率，增强采集后以应用为中心的核验、检查能力。
3.5 平台管理
用户与权限
对接银联自有SSO用户、组织架构体系，统一管理用户的操作系统、数据权限。
系统设置
提供平台级的通用配置、数据字典项、系统级参数的统一管理与配置。
审计日志
提供平台内的各类操作日志的查看、检索、统计功能，用于审计跟踪。
账号信息
提供使用者自身账号信息的维护与管理。
五、实施经验及注意事项
云运营平台除了作为云产品、云服务的统一入口，还包括应用部署全生命周期管理，是运维部门的核心引擎。作为周边系统的数据源及交汇点，也是多种信息汇聚的可视化平台。
在平台的设计和落地过程中，涉及数据中心的各个职能团队，需要主动与现有IT管理模式、组织结构等多领域进行适配和调整。既需要能快速地整合周边平台，又需要依赖周边平台提供的能力来稳定可靠地输出云产品云服务。另外，运维职责及边界逐渐产生了交叉和模糊，很多问题的定位和处理同样前置到平台整合方，对维护者的综合专业能力有了更高要求，以下几点经验和大家分享：
数据中心核心：云运营的建设除了云资源标准化、自动化实施，重点需要围绕CMDB进行数据一致性建设，准确、靠谱的数据是平台的根基。
形成标准API规范：内部专业平台对接时，运维管理平台之间松耦合，集中的API监控管理，有助于对接的快速落地及问题排查。
形成一致目标：将专业团队平台收归到统一的云运营门户下，需要打破内部团队、平台间数据壁垒，一致的目标有助于工作快速推进。
尽早调研明确职责：随着自动化、自助化产品建设，很多专业团队的内容可能整合到一个云产品中。因此在设计时，资源的调度和生命周期管理过程需要细致调研、谨慎设计，尽可能地推动当前已有的流程和团队分工，向未来标准化、统一化方向进行演进。短期内应避免在构建平台的同时对现有流程和团队职责产生较大冲击和改变。
私有云资源申请与应用部署结合：公有云重点偏向于资源申请落地，私有云在资源申请的基础上，需要关注解决应用运维问题，包括编排应用运营需求，如监控、日志、配置项等。
数据租户间逻辑隔离+部分物理隔离：一套平台满足多环境、多部门应用部署，不同部门、环境间需要有效的数据隔离；除了常规逻辑隔离，金融系统在部分场景下需要同时满足物理隔离，因此实施时同样需要重点关注数据安全的有效性。
六、效果总结
通过新一代云运营（云管）平台建设，云运营平台和管理平台实现分离。运营平台面向资源使用者，主要提供资源运营和自服务能力，实现了提升服务化水平和降低运营成本的目标。管理平台面向各个管理者，针对各个资源建设独立、深度的管理平台，提高底层资源使用效率。这就解决了行业中云管规划混乱，运营和管理服务耦合，以及与数据中心管理分工不匹配、专业性要求不匹配的问题。
云计算分Iaas、Paas、Saas三种服务模式，从企业用户角度出发，三种服务模式层层递进，用户的学习和使用成本逐渐降低，包括云服务后端的专业知识门槛要求越来越低，通过更多的开箱即用式服务，将传统系统、安全、网络等专业团队下沉，使其能力通过Paas、Saas平台进行输出，使得以往人肉服务转向云平台服务。由此带来的边际效应，现阶段已经明显显现，如降低和释放人力成本投入，推动现有人力向DevOps型、AIOps型人才升级。
参考业界数据中心发展趋势，从传统数据中心走向新型数据中心，绕不开“云”的建设；通过构建新一代云运营平台，应用运维一致向云看、向标准看、向自动化看，最终推动数据中心的转型升级，实现多云系统对接与数据开放治理，形成资源管理与应用部署管理结合的一体化云运营数据中心管理体系。
七、未来规划思路
软件设计是持续迭代的过程，云运营平台就是数据中心的软件载体。紧跟行业及社区技术发展趋势，通过合理地设计和实现，以标准化、自动化、智能化为方向，持续地推进云运营平台作为数据中心操作系统的形式迭代升级。在此过程中，不断激活组织活力，释放后台部门技术能力，组织结构向DevOps、AIops转型升级，以充分发挥云运营各项服务能力。
如有任何问题，可点击文末阅读原文，到社区原文下评论交流 觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到
https://www.talkwithtrend.com/Topic/4141
下载 twt 社区客户端 APP
或到应用商店搜索“twt”
以上是关于金融行业数据云平台的主要内容，如果未能解决你的问题，请参考以下文章