文/时任兴业银行科技运维中心总经理 吴上荣

兴业银行科技运维中心 罗胜涛

随着云原生技术的大规模使用，应用的复杂度越来越高，运维的难度也日渐加大，异常的定界定位及应急决策也愈发困难。信息系统在生命周期中会产生大量的业务数据和技术数据，日常运维中变更、监控、应急、演练等主要运维场景，均依赖这些数据。数据中心运维的就是这些重要的数据资产，运维的本质是保障数据资产稳定地提供预期服务。数据资产需要动态管理以保持准确性、完整性和及时性，而如何成为有效的数据资产并发挥重要的作用是值得研究的课题。

时任兴业银行科技运维中心总经理 吴上荣

运维的本质是保障数据资产稳定地提供预期服务

信息系统在资源配置及其运行过程中会产生大量的数据，这些数据分为业务数据和技术数据。这两种数据均由元数据、主数据、事实数据三个维度的数据组成。

元数据是描述数据的数据，是从信息资源中抽取出来说明数据特征、内容的结构化数据。比如：业务数据中的产品、合同、会计科目等定义数据，技术数据中的机房、服务器、应用系统、计算设备等配置模型定义数据。

主数据是具有稳定、权威、可共享、描述关系等特征的数据。主数据一般是元数据的子集，但包含实例数据，比如：业务数据中的客户列表、产品列表等数据，技术数据中的PC服务器列表、应用系统服务列表和调用关系等数据。

事实数据是描述具体事件或行为的数据。通常是在某个时间发生的行为，比如：业务数据中的交易记录、贷款记录等数据，技术数据中的主机运行日志、应用日志、监控指标和告警等数据。

业务数据主要由业务系统依照业务逻辑，通过功能模块的操作进行数据的生成、加工和展示。而技术数据在可行性研究、需求、开发、测试、上线、运行维护等各个阶段中产生、转换和关联。这两部分数据共同组成了信息系统数据资产。

数据资产的状态和变换过程

1. 数据资产的逻辑态。需求规格说明书会产生静态的业务数据资产，可行性研究阶段的架构设计、开发阶段的概要设计和详细设计会产生静态的技术数据资产，一般保存在设计工具中或文档中。这时的数据资产处于逻辑态，用来描述业务上和技术上的逻辑关系，明确要达到的业务目标和技术目标。

2. 数据资产的部署态。编码和测试阶段的各种代码、程序包、配置文件、依赖环境、镜像等将逻辑态的数据资产发展和转化为测试环境中可用于验证项目目标的部署态环境数据。根据不同的测试目标和执行人员一般会有以下部署态交付环境：开发测试环境、集成测试环境、UAT测试环境、性能测试环境等。上线阶段在生产中形成正式的部署态环境。这时的数据资产处于部署态，为实现项目目标的软件和硬件环境已处于能提供预期服务的状态。

3. 数据资产的运行态。系统投产使用则将部署态的数据资产转化为运行态。在日常的运行中，将根据预先的定义，通过用户行为、业务事件、交易活动等持续产生业务事实数据。同时根据预先的定义也将不断地产生各种技术事实数据，例如日志类数据（系统、应用、中间件、数据库、调用链、服务响应等）及指标数据（应用服务的黄金指标、业务/技术监控指标等）。基于这些数据，事前可以预防和预警，事中可通过全景监控来发现异常、告警通知、定界定位，并根据预案和专家经验进行应急决策和处置，事后可进行故障复盘、总结和改进。这时的数据资产处于运行态，需要通过各种运维措施保障这些数据资产稳定地提供预期服务。

数据资产需要动态管理

信息系统经历可行性研究、需求、设计、开发、测试、上线等阶段，在生产环境中体现出完整的结构和数据，提供预期的服务。数据资产在三种状态的转换过程中及日常运维的变更过程中，如何能持续对数据资产保鲜是难点所在。生产环境处于一个持续变化中的状态，经常会面临以下实际困难和痛点。

1. 业务数据资产较少考虑运维场景所需的数据。业务数据资产中主要是为实现业务目标的功能产生的数据，较少考虑运维场景需要的业务数据。例如，经常发现业务监控指标遗漏或不准确，原因大多是业务系统上线后才根据已有的业务数据去考虑监控哪些指标，没有根据业务场景实际的特征去设计。业务监控指标应该作为需求由业务部门提出，明确需要监控的业务场景及依赖的业务数据，厘清告警规则和告警级别等，然后研发侧在设计和开发阶段实现，在测试阶段验证，运维侧在上线阶段通过配置的方式在监控工具中实现这些指标的监测、告警及处置。这样才能将业务数据和技术数据有效结合，有利于在运维中更早更全面发现业务异常。

2. 大量数据资产往往与生产环境实际情况不一致。需求类、设计类等数据资产往往保存在设计工具或文档中，一般是静态的数据。在上线时基本能保持与生产环境一致，但随着多次变更之后，这些数据资产的维护缺失或不及时，使得与生产环境实际情况不一致，运维人员经常被迫面对“以生产环境为准”的现实。

3. 数据资产缺少运维视图和更加直观的展现形式。生产环境中的数据资产大多以代码、配置文件、运行参数、调用链、海量的日志等终态形式存在，虽然目前有APM、全链路等方式提高可观测性，但更多的是研发视角的细节数据，缺乏运维视角的视图和更好的自动关联数据的展现形式，很难为应急处置等时效性要求较高的运维场景提供有效帮助。

以上痛点的核心在于业务数据与技术数据有效结合度不高、逻辑态结构化数据的缺失且向部署态转化时数据丢失，以及运行态数据可视化关联展示的能力不足。理论依据和实践经验均表明：数据只有在不断使用中才能保持准确性、完整性和及时性。一个行之有效的解决痛点的方案是对数据资产进行动态管理，从数据资产的构建、转换、使用等环节入手将静态数据通过应用模型、资源模型等关联起来，在开发、运维过程中进行数据闭环管理，使数据资产保鲜并通过分层拓扑关联展示等方式更有效地使用数据资产。

一体化交付实现动态管理数据资产

一体化交付是指将应用发布和资源供给这两个过程有机结合，而且将其关联的数据资产运用于上线、变更、应急、演练等各种场合，形成管理闭环和数据闭环，实现资源高效供给、数据资产保鲜和数据关联使用的综合目标。一体化交付过程涉及数据资产的逻辑态、部署态和运行态，分别通过逻辑图、部署图、运行图作为载体，使用在线白屏化的功能落地实现。

在一体化交付中，应用发布需注重逻辑图的构建和应用的全生命周期管理。逻辑图以发布单元为粒度，以应用模型为载体进行构建。发布单元是版本构建、部署和发布的基本单元，发布单元包含一个或多个部署单元。应用模型主要包括以下数据资产：应用与发布单元之间的层次关系和逻辑关系、发布单元之间的调用关系、发布单元内部的服务关系、发布单元与制品库的关系、与PaaS中间件及数据库等资源的关系、各类管理策略（应用监控指标、高可用、容灾、安全等策略，管理策略会和应用的资源产生创建、发布、安全管控、监控等关联）等。针对传统应用和云原生应用可分别建立不同粒度的发布单元、应用模型，这些数据资产将伴随应用的全生命周期动态变化，在每次应用发布时通过逻辑图的更新持续保鲜。

研发侧将根据逻辑图一站式申请应用所需资源（基础设施资源、PaaS中间件及数据库等资源），运维侧对资源的供给过程将实现部署图的构建。资源供给和应用发布通过发布单元进行衔接。发布单元向上根据应用模型关联应用服务或业务场景，向下根据CMDB中各类配置项的关系关联部署和运行所依赖的计算资源（虚机/物理机、容器集群、POD、容器等），再逐层自动关联存储资源（集中式/分布式存储等）、网络资源（软/硬负载、虚拟/实体交换机、路由器、IP地址、DNS、专线、VPC等）、安全组、机房物理设施等，形成应用维度完整的部署图。

进入日常运维阶段后，将以各种运行图展示日常的运行信息，并在主要的运维场景基于这些数据资产开展变更、监控、异常定界定位、应急处置、演练等工作。特别是异常定界定位场景，需要将这些数据资产通过更好的分层拓扑关联展示来帮助更快定界定位，以更有效支撑应急决策。这些运维场景对数据资产的变更可依托CMDB和流程审批进行闭环管理，达到保鲜的目标。一体化交付是一种动态管理数据资产的方式，实施有一定的难度，关键点是构建逻辑图、部署图和运行图，需要研发侧和运维侧共同协作，设计合适粒度的发布单元，将应用模型、资源模型有机结合，并在日常运维场景中以运行图为基础并依托CMDB实现数据闭环管理和数据保鲜，以探索和实现更高效智能和更有韧性的运维模式。

总结

数据资产管理是一件重要但难度很高的工作，闭环的动态管理则更加困难。但其带来的价值和意义非凡，也是为走向全面智能化打下坚实且高质量的数据基础。从管理角度和技术角度在运维领域都具备落地的可行性，目前在采用华为云产品实施的新一代云平台项目中实践，持之以恒，可预见将产生很高的价值。

运维中数据资产的动态管理是在生产环境中进行的，其实开发环境和测试环境中也同样需要实现数据资产的动态管理，才能更好地支撑开发和测试的自动化和智能化。最终实现数据资产的研发运维一体化，这将是一个更高的目标。

（此文刊发于《金融电子化》2025年6月上半月刊）