科技运营数据管理实践

01引言

随着“十四五”规划提出发展数字经济，推动数字产业化和产业数字化转型，各商业银行正处于数字化转型的深水区，在加速金融科技数字化、智能化、服务化的过程中，各领域都有原始的数据积累。以银行金融科技运维为例，配置管理建立后数据使用价值不高，数据问题也愈积愈多，其核心问题是要同步做好数据管理，数据管理区别于上层的数据治理，更侧重于具体方法、流程、机制和措施等。这里结合运维领域，具体说明进行数据管理的方法和实践。

02运维数据管理面临的问题

首先说明下对数据治理的理解，数据治理是专注于将数据作为商业资产进行应用和管理的一套机制，能消除数据的不一致性，建立规范的数据应用标准，提高组织的数据质量，实现广泛应用和共享，发挥数据的商业价值。那么其具体的数据管理要解决什么问题呢？结合我们实际问题，总结有四个字“堵”，“独”，“滞”，“漏”。这里以G行运维配置数据作为管理对象，对其他银行科技领域数据管理有一定代表性。

图1 数据管理面临的问题

03数据管理的“道”,“法”,“术”,“器”

大家可能有疑问，解决以上问题建立数据中台不是最好的解决方案吗？有不少企业在数字化转型过程中，数据管理完全依赖数据中台建设，没有搞清数据管理基础要做什么，导致中台也建成了空中楼阁。正如阿里的onedata方法论体系，是先建立一套数据标准，用统一建模的方法梳理整合数据，再利用数据中台工具对数据进行汇总加工，因为有统一标准和建模，数据才能在中台只实现一次顺畅加工流转。所以这里不谈中台建设，只说数据管理的具体思考和实践。基于以上问题，我们结合DAMA的数据治理框架及方法论，制定了具体的数据管理方法，也引用数据治理专家们总结的数据管理的经验，按“道”，“法”，“术”， “器”结合具体实践工作，对运维数据管理遇到的问题有一定指导作用。

图2 数据管理的“道”，“法”，“术”，“器”

道

（一）”道”：这里引用DAMA-DMBOK2的数据治理之道，主要包含数据战略，组织机制和数据文化。如果数据治理好比我们驱车到达远方的一项任务，那么“道“就是我们行驶的方向，以及可以利用的政策和可规避的风险。

数据战略好比数字化转型的灯塔，由制度流程、组织人员和技术工具为数据战略提供指导，数据战略是为企业发展和运营目标提供支撑。通常制定为五个主要步骤：环境因素分析，确定战略目标，制定行动方案，落实保障措施，战略评估优化，其核心是建立数据思维。数据思维建立方法可通过自上而下的推动，营造数据驱动的文化氛围，以及建立循序渐进的培训机制等。不只是从企业做起，是需要从每个人做起，建立“我为人人，人人为我”的数据服务思维。G行数据治理总体框架包括“统一管理、合规底线、协同共建、创新驱动”四个方面。有三个要点：抓重点，善于简化；求精确，注重量化；明不知，追求细化。

法

（二）“法”：主要是数据管理的一些方法和策略，好比我们驱车到达目的地的可选路径，这些需要前期规划好，结合流程确保管理策略能落地。

G行主要分为事前预防手段，事中控制技术，事后改进措施。事前包括数据标准定义，校验规范，流程制度优化，组织人员培训保持认知一致；事中包括控制源头，规范标准输入输出，控制流转，质量校验，精准定位，预警机制；事后包括数据质量探查和评估，数据问题汇总，根因分析，问题修复，流程和模型优化。这里最重要的是数据标准的制定、推广和跟踪，数据标准其实可以分为基础数据标准，分析和校验数据标准和实施标准，然后通过组织、制度和流程将其管理规范贯穿起来，通过流程和制度监督标准的执行，有效地闭环管理。我们也是首先统一并制定了数据标准，利用ITSM流程工具结合CMDB发现的问题，逐一溯源，消灭数据问题，形成闭环跟踪，持续监督提高数据质量。

术

（三）“术”：这里指数据管理的一些技术方法，好比我们驱车到达目的地的驾驶经验。

主要涉及元数据，主数据和参考数据的一些管理技术，我们主要通过DAMA数据定义标准的学习，对系统运维领域的数据做了元数据和主数据的划分。元数据可以理解为定义和描述其它数据的数据，包括技术和业务流程、数据规则和约束，还包括逻辑数据结构与物理数据结构等。主数据可以理解为与业务活动相关或提供业务活动语境，系统间共享的数据，包括业务交易中涉及的内外部对象的详细信息。元数据就像我们数据库中定义的基表结构，主数据是表里存储共享的实际数据，或者好比元数据像一本书的目录和索引，主数据就是书中的正文。很多金融企业的运维数据在前期都是按运维需求建立起来的，并没有事先区分元数据与主数据，我们之前也是已经定义的运维相关的运营配置数据、运营性能数据和运营管理数据，所以管理过程主要在之前数据需求划分的基础上，再按元数据和主数据进行划分，这样划分后的好处更有的放矢，更清晰我们的数据分类管理策略，更好地为我们的onedata数据中台体系服务。我们对运维领域元数据和主数据是按以下过程进行管理：摸底、优化、标准、整合、运营。

图3 数据管理过程

大部分运维的配置类描述元数据都是未标准定义，或引用后再定义的，比如服务器硬件配置信息、操作系统信息、应用软件信息、IP信息等。这些信息我们都是在CMDB收集时直接采集，往往没有制定标准，在之后的消费过程就可能出现歧义、遗漏或无法关联等问题。元数据就是数据标准的基础，企业在制定数据标准的时候最先需要明确的就是数据业务属性、技术属性和管理属性，而这三类属性就是我们所说的业务元数据、技术元数据和管理元数据，元数据如果不进行规范化约束，就无法成为数据标准。我们针对元数据的梳理主要是分类了业务、技术和管理三类，并制定了配置数据管理标准规范，具体有三项措施：

1. 梳理出关键数据，将这些数据做埋点，以便后续进行数据血缘跟踪和分析；

2. 统一表结构，将各类数据表形成统一结构规范，层级管理，比如第一层基本信息，第二层关联信息，第三层特殊信息；

3. 统一字段名规范，建立数据字典统一命名规范，再确定各个表来源和优先级。

这些措施保障了理解数据准确和标准的一致性，并提供统一访问途径，以便推广技术元数据标准和应用。在主数据管理方面，主要是按元数据定义的标准，对数据值和标识符进行控制和校验，经过管理的主数据应是关键业务实体唯一的、权威的、最准确的数据，更方便数据共享。在主数据规范管理后，我们更多关注系统之间的数据流转、访问关系、共享应用等，更多地挖掘运维消费场景，实现数据服务。

器

（四）“器”：是在数据管理技术的基础上，实现具体工作的工具，好比我们驱车到达目的地的主要交通工具。所谓“工欲善其事，必先利其器”， 在定义梳理这些元数据和主数据后，必然会用到两个最常用的方法工具，建立模型和数据血缘。数据建模是最重要也是最常用的，是发现、分析和确定数据需求的过程，用数据模型的精确形式表示和传递这些数据需求。建立系统或平台前期一般都会建立数据模型，其模型核心内容是数据结构、约束关系和数据操作这三部分，形成概念、逻辑和物理模型成果物，但建立和维护的过程是循环迭代的。我们按照以前CMDB系统建立的模型，进行了重新梳理，发现有一些数据结构已经过期需要优化调整，还有一些一直存在缺失，需补充数据结构，也同步更新了约束关系和数据流向的定义，具体是按以下六个方面进行全面梳理:

图4 数据建模工作

数据建模工作我们是这样具体实施的：关于数据结构，重新收集数据有关需求，定义数据类型、结构等信息，实现配置项结构、字典（具体元数据）的建立；约束关系，梳理各团队内部数据，定义数据的唯一标识符，确定数据间关联约束和验证关系；数据操作：协商定义各运维团队之间的接口规范和数据流向，明确数据操作和流向的消费场景。除了数据模型的三个核心内容外，我们还制定了接口传输方式，同步周期和接口负责人。首先根据数据量大小、重要程度以及数据时效性等要求，规范定义不同的接口同步方式，再次明确各运维团队接口数据采集和同步周期，保证提供接口数据的完整和时效性，最终指定接口负责人沟通同步需求，确认接口数据质量，由负责人跟踪推进接口同步实现和问题解决，实现数据问题闭环处理。

04应用实践

（一）具体应用场景：

G行通过系统运维配置管理平台（SMDB）和网络安全自动化合规管理平台（INS）实现基于底层的配置数据管理，通过应用配置管理平台（AMDB）实现应用路书、系统交易信息和档案管理等应用场景管理，为CMDB提供数据消费，规范数据标准，整合数据需求，去重寻源等优化，增加数据校验，实现闭环管理。通过平台，结合数据采集汇总分析，以及相关操作工具，实现日常运维配置管理、系统自动巡检、系统档案和运维报表等运维自动化消费场景。

图5 数据应用场景

图6 配置管理

图7 运维消费场景

此外我们还结合数据血缘流向图，提供多平台互联的消费场景。在运维环境随着云计算和大数据的发展，集成化程度越来越高，系统全局性风险的可能和危害越来越大，我们利用梳理的数据流向，和日常故障处理场景，重点为一线团队开发应急故障查询和应急场景发布工具。一线同事在处理全局性故障时，能及时准确地查询相关信息并第一时间关联处置，实现运维的“手眼”并用。

图8 数据服务输出成果

（二）解决数据问题：

针对已经建立的CMDB，我们如何梳理存在的数据问题呢？我们主要从两个方面进行梳理检查：一是日常事件处理、问题分析等发现的数据问题，统一记录、分析和整改跟踪；二是通过数据模型的度量指标进行反向检查：1.模型多大程度上反映了实际使用需求？2.模型的完整性如何？3.模型的结构通用性如何？4.模型遵循命名标准的情况如何？5.模型的清晰、完整、准确性如何？基于以上自查不难发现数据模型的问题，可以重新定义、梳理和规范数据模型，数据模型是数据规范标准的核心底座，是绝对值得花费精力打造优化的。

其实解决数据问题更多要源于数据诉求，对数据流向的管理无论从业务还是运维管理都已经变得非常重要。通过数据血缘分析能满足元数据管理的需求，满足监管需求，影响分析和数据质量问题分析等，针对运维最有效的还可以系统迁移时参考数据血缘，减少系统迁移工作量。通常建立数据血缘的步骤是先梳理出元数据之间的关联关系建立模型，再以此为基础整理所需的数据，并将数据加载进数据库，设计关系进行链路匹配查询分析，我们主要针对CMDB的数据进行反向步骤的梳理，重点结合目前数据和应用场景，抽取数据流向和关系，再根据关系检查验证以前的模型，对错误和遗漏的问题进行修正和补充。

比如我们梳理的数据血缘关系，制作了以下数据流向图，便于梳理和解决数据问题，具体包含以下内容：

图9 数据流向图

1.数据节点（包括数据流入节点，主节点，数据流出节点），数据节点信息一般用来做可视化展示。

2.数据流转线路，数据流转线路表现三个维度的信息，分别是方向、唯一标识、数据更新频次。

3.清洗过滤规则，数据接受方会根据自己对数据的要求过滤接入的数据，这些要求就形成数据标准，依据这些标准选择数据清洗。

4.转换和关联规则，从数据提供方出来的数据，有时需要特殊处理才能接入到数据需求方，按唯一标识建立关联并维持生命周期，到期后需要做归档或清除等处理。我们设计的血缘关系，能较清晰地表达数据间关联关系，对组织数据的完整性、准确性管理和溯源分析有一定帮助。

通过数据流向的血缘分析还可以纠偏数据和挖掘更多的应用场景。方法通常有：自动解析，系统跟踪，手工收集和机器学习等，我们主要使用的是自动解析结合手工收集，重点排查CMDB平台原有的SQL语句和存储过程，找出核心数据的来源和目标流向，这些数据覆盖约70%的流向关系，我们也按重点、热点数据进行收集，梳理过程主要还靠人员整理，虽然比较繁琐，但是最大的好处是更加明确数据流向和应用场景。还有一些数据是基于流程或手工更新的，我们采用手工收集方式，这些数据要确定好唯一数据源，能优化流程的尽量自动化处理，必须手工处理的增加校验机制来确保及时性和准确性。

05总结展望

以上是我们结合数据管理方法，针对运维数据的一些管理实践。“在危机中育新机，于变局中开新局”，“十四五”规划提出发展数字经济，G行也积极推进数字化转型工作，实现科技为业务赋能，运维数据管理工作就是我们要重点开拓的新局。数据管理实践是一项有既有挑战又有意义的工作，而且需要不断持续优化，它即是一门科学，更是一门艺术，我们要深入学习以上“道”，“法”，“术”，“器”的方法论，再结合工作中的具体场景，不断深耕实践，让运维之手和运维之眼有数可依，更加高效、从容地实现自动化、智能化运维，全面实现科技赋能。我们将踔厉奋发、笃行不怠，持续推动数字化转型工作更上一层楼，把一流财富管理银行推向前进！