·2022-01-17 11:51

技术总监·畅销书作者

《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.1）

字数 12017阅读 4533评论 0赞 3

## 8.1 数据思维

从流程驱动到数据驱动，显著的特征为通过指标进行度量，通过度量进行优化，基于数据来建立数据指标体系，通过指标体系达到主观事件客观呈现的效果。在度量和反馈之前，需要 DevOps 价值交付流水线中的所有能力子域具备数据思维。根据中国信息通信研究院的分析数据，企业 IT 的信息化逐渐完成，企业对 IT 的精益运行的需求越来越迫切，在这个场景下，数据思维和数据使用能力成为提升 IT 生产效率的制约因素。在 DevOps 的最佳实践中，数据思维也是一个制约因素。

作者认为，企业数字化放在 DevOps 领域，更多的场景还处在数据量化的扩展阶段，除快速交付、质量保障、服务输出和业务连续性能力输出以外，还有一些重要的场景需要开拓，其中包括 DevOps 价值交付全链路的数字信息能力输出。随着 DevOps 在企业中的逐步推广和落地，在数据驱动的基础上， DevOps 的锚定价值进行多场景的扩展，安全、稳定、高效和低成本已经成为数据驱动的方向。

### 8.1.1 DevOps 数据的发展历程

从企业的信息系统规模、复杂程度、交付方式，以及 DevOps 工具的应用等方面综合考虑，可以把 DevOps 数据的发展大致分为 5 个阶段：服务产品化阶段、能力平台化阶段、管理精益化阶段、运营体系化阶段和数据价值化阶段。在这 5 个阶段， DevOps 的场景输 出能力在不断提升，从最初的 DevOps 流水线节点的自动化，到 DevOps 门户的服务目录和 IT 管理通过 DevOps 数据进行度量反馈，再到用户体验和场景化增值服务的技术运营场景。因此， DevOps 的发展遵循泛化边界的思路，“浸润式”地进入整个 IT 服务体系，从业务的角度来提升 DevOps 价值输出能力、提高技术的投入产出比和降低企业成本压力。

如果我们把 DevOps 的发展“浓缩”成流程约束、技术提升、工具建设和数字化呈现，那与之相对应的， DevOps 数据的场景发展也有 5 个阶段：效率提升阶段、质量保证阶段、成本集约阶段、业务创新阶段和客户满意阶段。在 DevOps 价值能力输出中，数据已初步形成生态标准，用以构建 DevOps 数据中台和数据可视化，也能对数据的进行“血缘”能力和影响能力的初步分析。在客户满意阶段， DevOps 数据已形成较大规模，将价值交付过程和大数据、机器学习的技术相结合，形成一系列智能策略，提升 DevOps 数据的输出能力，让数据边界延伸至更多场景，覆盖企业内部更多的职能部门。

### 8.1.2 数据思维的含义

随着 DevOps 的实践和应用，各能力子域的自动化水平不断提升，基于 DevOps 能力输出进行价值交付的门槛逐渐降低。除工具赋能以外，度量和反馈的能力进一步得到提升，通过度量和反馈，进行内部管理和流程优化，这些都离不开数据的展示和验证。通常在两种场景中进行体现，分别为数据对于打通业务服务链路的价值和 DevOps 价值交付链路中各能力子域的数据观念。

1 ．数据对于打通业务服务链路的价值

数据在企业数字化实践中处在核心地位，用 DevOps 进行实践也是如此。不同的数据对于不同的 DevOps 实践对象而言，发挥的作用不一样，因此，对于 IT 组织，数据对于打通业务服务链路的价值主要体现在以下两点。

（ 1 ）在产品运营阶段，快速发现业务问题。公司管理层通过经营指标发现公司运营中的问题，同样， IT 组织能够通过业务数据发现产品运营中的问题。业务数据体现的是每个用户的行为，如数据有变动，一定是产品运营过程中某些运营方法和运营策略不同于往常，需要重点关注。举一个简单的例子，如多个第三方渠道出现访问量、访问成功率下降的情况，在系统无故障的情况下，检查是第三方渠道出现问题或新上线功能出现 bug 而导致数据变化，还是某些业务开关和策略出现误操作的情况。因此，在产品运营阶段，数据是沟通 IT 组织和业务组织的桥梁。对于 IT 组织，监控着力点的前置，有助于快速发现业务问题。在业务监控中，数据的变动点可能是公司运营的问题点，也是 IT 组织在工作中要解决问题的重点。

（ 2 ）在实际的价值交付过程中，资源端到端输出是前置环境，一般有一些特殊场景是流程无法覆盖的，如企业重大营销活动时的系统资源扩容和紧急情况下的系统降级。在链路系统扩容方面，存在 A 系统扩容和 B 系统扩容。如果有数据能直接证明 A 系统扩容比 B 系统扩容方式好，就采取 A 系统扩容。通常情况下，可以用链路压测确定，而现实中，在庞大的业务系统链路中，涉及外部第三方系统的多级调用，并不一定能够协调足够多的基础架构资源，因此，只能基于现有的数据进行决策，紧急情况下的系统降级也一样。在数据积累过程中，如果数据向好的方向发展，那么要放大这个效应，全面应用促使数据好转的措施。如果数据表现存在偏差，则需要快速定位导致数据变动的真正原因，并给予解决。无论是产品上线后运维方面的决策还是应急预案的决策，都能通过数据来指导。

成本复盘和项目后评价是项目管理过程中的后置阶段，对于企业，每个项目和需求的上线，有且只有一个合适的指标来评估其结果，因此，项目后评价是成本复盘的重要手段，是判断人力资源、软硬件资源的投入和产品运营后的产出是否成正比的依据，是判断项目或产品成功与否的根据，也是进行项目和产品优化的重要手段。对于 IT 组织，除资源成本、人力成本以外，全局的成本复盘还包括企业的经营成本、沟通成本，以及过程中的损耗，需要将项目上线前的预期收益和项目上线后的阶段性实际收益进行对比，相关数据可以确定对全局资源的投入是否形成了收益，也能将此类数据作为业务继续迭代优化和下线止损的参考。

2 ． DevOps 价值交付链路中各能力子域的数据观念

在 DevOps 价值交付的所有阶段，都应该通过数据进行辅助工作。对于 IT 组织成员，如果没有数据作为参考，那么工作的方向和思路会出现严重偏差，任务推进和过程管理的效果也因数据缺少实时性和准确性而大打折扣，导致不能快速、高质量地进行交付。因此，对于 IT 组织成员，要充分使用数据的反馈和支撑能力。

数据让问题及时暴露，交付进度第一时间反馈在看板泳道上，交付风险第一时间反馈在交付看板上，上线后出现的 bug 第一时间反馈在数据变动中，系统和资源的问题第一时间体现在监控反馈上，代码质量第一时间反馈在持续构建环节，业务受理问题第一时间反馈在数据的环比上。

IT 系统集中了企业经营数据、 IT 数据等企业运营所需的数据，经营数据包括财务数据、人力资源数据、业务数据、管理数据， IT 数据包括资源数据、监控数据、流量数据、后台支撑数据。企业的管理者、 DevOps 推动者、员工都需要合理使用数据，进行数据使用场景和数据输出场景的匹配，其中数据管理工程师负责将业务数据进行分析并提供数据的结构化能力，数据研发工程师负责满足企业对各类数据的需求，运营人员负责对业务数据进行分析并给出反馈。 DevOps 推动者只需要将 DevOps 场景的数据和其他第三方数据进行有机结合， DevOps 其他参与者需要随时使用数据，并不需要关注数据的采集和加工。价值交付服务能力的边界延伸并不意味 IT 技术的延伸，需要善于运用现有的数据来获得想要的结果和反馈。

### 8.1.3 数据思维的落地方式

数据的使用者通过数据进行分析、跟踪和反馈，最终使数据的使用者具备数据思维。数据规模如何形成数据生态，数据生态如何构建数据指标体系，数据指标体系如何具备数据输出场景，数据输出场景如何实现度量和反馈，如何通过度量与反馈实现 DevOps 价值交付过程中的持续优化和最终结果持续反馈，这是构建数据思维的方式。

1 ．具备 DevOps 数据生态

在 DevOps 的最佳实践中，数据的范围大且离散，集中了企业经营的所有数据，需要 DevOps 的推动者通过场景的适配进行数据流动。

对于资源管理，基于资源的数据大致分为以下两类：数据中心数据（包括机房、机柜、 U 位、服务器及配件、系统版本、 IP 信息等数据）和云计算管理数据（包括宿主机、虚拟机、容器、系统版本、 IP 信息、承载系统、负载均衡、系统信息、中间件信息、业务信息等数据）。基于价值交付的数据均来自需求过程的数据、项目管理的数据、研发过程的数据、测试过程的数据、运维过程的数据和安全管理过程的数据。基于系统的数据均来自业务日志，包括时间、请求号、系统、接口、方法、耗时和响应码。基于业务的信息大致有 PV 、 UV 、转化率、成功率、新客人数和利润等。基于成本的数据均来自软硬件成本、人员成本、沟通成本和正常损耗成本等数据。基于组织架构的数据大致有部门、团队和人员等数据。另外，还有一些文档数据，如需求文档、接口文档和知识库。

如图 8-1 所示，具备 DevOps 数据的生态基础需要将上述源数据进行采集、加工、存储和分析，最终达到应用的目的。
![](/home/attachment/202201/11/1225551_164187102375111.png)
图 8-1

2 ．提供数据使用场景

对于 IT 组织，狭义的价值交付是产品交付的过程，从业务需求开始，到产品交付结束。广义的价值交付是产品运营的过程，从业务需求开始，到产品投产上线，一直到产品下线结束。因此，在狭义的价值交付过程中，数据使用场景局限于 IT 组织内部，在广义的价值交付过程中，数据使用场景需要大范围延伸，数据输出范围涵盖了企业绝大多数职能组织。

对于 DevOps 推动者，数据使用场景看似复杂，却离不开稳定、安全、高效和低成本 4 项基本要素，这也是 IT 组织的能力输出范围。通过大范围的数据化能力， DevOps 能为企业决策提供有力支撑，实现基于产品的快速交付、基于 IT 能力的服务目录、基于数据的运营服务、基于标准的数字化管理和基于场景的数据开放能力，下面以知识图谱、数据中台和数据可视化为例加以说明。

（ 1 ）知识图谱。使用统一的语言定义 DevOps 数据，将价值交付过程中的对象通过实体与实体的关系来表达，整合 DevOps 领域的实体关系，形成知识图谱。和 IT 组织服务目录类似，知识图谱的作用是将 IT 组织透明化，由 IT 服务业务升级成 IT 支撑业务。

（ 2 ）数据中台。建设面向交付领域的数据中台，统一纳管流程数据、需求数据、开发进度数据、测试进度数据、资源数据、告警数据、系统性能数据、产品性能数据、业务数据、日志数据、工单数据、指标数据和团队效能数据等，面向企业级产品交付和运营场景提供统一的数据访问路由、数据服务目录、数据接入管理、数据可视化等功能，消除“数据孤岛”，通过整合关联和对外开放，深度挖掘运营数据的价值。识别前台数据需求，整合后台数据，对数据进行加工和输出，建立数据中心级的数据服务共享平台。通过数据的梳理，数据源的规划，数据流程的整合，对存量数据进行加工整合，达到以数据服务化的方式来实现数据对企业运营、产品经营和 IT 赋能的目的。

（ 3 ）数据可视化。通过数据的可视化呈现，帮助 IT 组织和其他职能组织以直观、快捷、方便的方式进行数据反馈，还可通过一系列工具组件让数据使用人员根据自身的需求对海量数据进行快速视图编辑、多层“下钻”分析、多维度关联分析、报表编排，并进行数据的横向 / 纵向对比等，同时将传统的数据使用经验进行数字化转变，大大提升工作效率，实现问题快速排查、风险及时发现和知识持续沉淀。

3 ．养成每天看数据的习惯

DevOps 价值交付全链路中的所有成员应养成每天看数据的习惯。作者每天随时查看项目的管理数据、需求吞吐数据和研发吞吐数据，这样做不但可以了解业务经营数据，而且可以保持对数据的敏感性。对于数据的表现，无论是正常还是异常，都需要与需求团队、研发团队、测试团队、产品团队和业务团队保持沟通，让所有人知晓目前的项目和线上产品的表现。这样做一方面能获得来自团队的反馈，另一方面可以搭建快捷且“无损”的沟通渠道。

## 8.2 DevOps 数据体系的建设和管理

DevOps 数据体系的建设和管理过程通常包含两种方式：从数据产品的角度，提供数据的落地途径和方法；从数据场景的角度，提供数据的场景化输出和服务运营。在数据的输出和变现的过程中，场景化作为最终应用的载体， DevOps 数据的输出和变现能力最终还是依靠前期的数据体系建设和管理。

### 8.2.1 DevOps 数据体系的建设思路

数据的规模与企业规模、业务形态和运维能力有很大关系。根据中国信息通信研究院的数据统计，企业规模越大，业务形态越复杂；信息化能力越强的企业， IT 组织采集和纳管的数据越多。在 DevOps 的最佳实践中， DevOps 数据变现的效果和数据体系呈正向关系。与之相对应的，优秀的 DevOps 数据输出能力和 DevOps 数据体系建设有很强的关联。通常，使用大数据技术和 AI 技术来进行数据的价值交付，典型场景有智能度量、智能反馈、 IT 组织成员的智能画像、知识图谱、智能监控、动态阈值、根因分析和故障自愈。

对于规模较小、业务形态单一、信息化能力一般的企业，数据变现能力较弱，数据 输出需要场景的强依赖。在这种情况下， DevOps 的交付场景成为数据应用的唯一突破口，主要进行数据的被动采集、被动存储和被动消费，特征为数据割裂和数据关联性较弱，典型的场景化驱动有资源管理、基础架构监控、业务连续性保障和应急知识库。

对于 DevOps 数据的变现过程，一般关注 3 个阶段：数据由少到多、由单维到多维、覆盖面由内到外的阶段；数据处理由简单到复杂、技术由单一到多样化的阶段；场景由基于需求到基于规划、输出能力由浅入深、由自动化到智能化的阶段。

1 ．从数据获取渠道出发，由少到多

在 DevOps 数据体系建设的初级阶段， DevOps 数据的来源局限于 IT 组织内部，包括资源数据、监控数据、文本数据、日志数据、需求数据、研发数据和测试数据。随着数据源接入进入全覆盖阶段， DevOps 数据已经覆盖业务运营数据、后台支撑数据和财务数据。需要说明的是， DevOps 数据的获取离不开 DevOps 数据输出的强依赖条件，这种强依赖条件完全取决于软件交付场景的需要，随着数据的获取渠道越来越多，数据量越来越大，相应的数据场景也越来越多。

2 ．数据处理的能力决定了数据价值的范围，覆盖面由内到外

从技术的角度出发，大数据只是一个工具，而非一个职能，因此 DevOps 数据是否具备大范围、全流程和全覆盖的输出能力，决定了数据汇聚层的价值模型，也间接影响了数据输出的覆盖场景，这也就是我们理解的 DevOps 数据中台。在这个阶段，需要重点提升数据处理能力和数据衍生能力。

3 ．有价值的场景化选型决定了数据变现能力，变现能力由浅入深

在 DevOps 数据的变现过程中，核心功能为价值输出，最终会得到 3 个结果：优化、反馈和贡献价值。因此，有价值的场景化选型必须从 IT 组织内部的优化开始，再到价值交付的全场景度量反馈，最后到数据衍生体系的贡献价值，如智能运维、价值交付、项目的成本复盘、成本中心的利润测算、智慧运营和高阶数据决策能力。 DevOps 数据变现如图 8-2 所示。
![](/home/attachment/202201/11/1225551_164187104169486.png)
图 8-2

### 8.2.2 DevOps 数据体系的建设过程

DevOps 数据体系的建设本质上属于数据项目。 DevOps 数据体系的建设和管理过程需要遵循数据项目的原则。数据项目的建设是一个循序渐进、持续优化的过程，不可一蹴而就， DevOps 数据体系的建设和管理也是如此，和业务数据不同， DevOps 数据的寻找和采集相对困难，因为 DevOps 数据呈现离散状态。 DevOps 数据体系建设的过程一般分为 4 个阶段：寻找数据，建立模型，数据的接入和接出，以及数据的变现。

1 ．寻找数据

在 DevOps 的数据体系构建过程中，寻找数据是一个令人头痛的问题，这和业务数据体系有很大区别。业务数据的管理大多由前置目标驱动，而 DevOps 数据的管理大多由后置目标驱动，这就造成在寻找数据阶段需要自上而下地进行数据的梳理和调研。 DevOps 数据的管理特性和 DevOps 的组织特性、组织文化相关，在 DevOps 领域，价值输出全流程的安全、稳定、高效和低成本是 DevOps 的能力输出特性，前两个特性和数据的耦合度较低，而后两个特性和数据的耦合度较高。

参考数据资源普查的方法，因为 DevOps 数据输出场景的目标后置性，所以只能采取自上而下的方式，而自上而下的方式一般会用到 IRP 。 IRP （ Information Resource Planning ，信息资源规划）是指对所在单位信息的采集、处理、传输和使用的全面规划，其核心是运用先进的信息工程，以及数据管理的理论和方法，通过总体数据规划，奠定资源管理的基础，促进实现集成化的应用开发，构建信息资源网。

根据 DevOps 能力输出框架，可以对 DevOps 数据的流向进行描述，从“数据初态”“数据终态”和“数据去处” 3 个维度描述 DevOps 数据体系构建过程中的数据。在 DevOps 数据的梳理范围过程中，通常会扩大到价值交付全流程中各能力子域所采用的流程、工具、支撑系统的配置信息、数据留存、流程节点、反馈指标，以及产品投产后的告警信息、业务反馈、用户体验反馈、业务系统日志、网络流量日志，还包括过程中的成本投入、项目收益。随着 DevOps 能力输出的泛化，由 IT 组织内部到 IT 组织外部，价值交付的边界出现一定规模的模糊和融合，价值交付不仅仅以产品交付为目标，而是以企业经营和业务运营为目标，典型的有“以产品为中心”到“以用户为中心”的理念转换，如公司业务的用户点击数据既属于 DevOps 数据的范畴，又是业务数据的重要组成。

随着业务的发展， DevOps 数据也出现了爆发式增长，可惜的是，传统的 DevOps 数据消费方式还是通过竖井式的方案，以不同的系统和团队进行划分，通过职责或角色的方式展现给 DevOps 价值交付流水线中的各个能力子域或其他相关联的组织，以供它们使用。例如，交付数据以获取需求数据开始，以代码增量交付结束；监控系统以获取监控数据开始，以输出规则定义的告警信息给使用人员结束；日志系统以获取和索引日志内容信息开始，以提供复杂的搜索和内容并展现给使用人员结束；质量系统以获取缺陷信息开始，以缺陷完成修复结束。传统的 DevOps 数据价值挖掘受制于不友好的 DevOps 工具数据生产方式和 IT 人员自身的数据认知。因此，在通过 IRP 寻找数据的过程中， DevOps 推动者和数据使用者大多会形成一个误区，总是站在 IT 的角度寻找数据，最终找到的都是“掐头去尾”或相对局限的数据。数据价值输出过程如图 8-3 所示。
![](/home/attachment/202201/11/1225551_164187105334316.png)
图 8-3

DevOps 数据量爆发阶段通常是 DevOps 工具组链结束阶段，通过对数据自上而下的梳理，可以让数据使用者对现有数据资源有全面且系统的认识，特别是对数据职能域之间交叉信息的梳理，更加清晰地展示了数据信息的来龙去脉，有助于数据使用者把握各类信息的源头，有效地消除“信息孤岛”和数据冗余，控制数据的唯一性和准确性，从而确保获取信息的准确性和有效性。在寻找数据的同时，可以助推工具化的查缺补漏和优化。常见的数据源如图 8-4 所示。
![](/home/attachment/202201/11/1225551_164187106773490.png)
图 8-4

2 ．建立模型

在 DevOps 领域，数据模型体现在数据识别方面。从传统的数据模型理论来看， DevOps 数据并没有明确的操作数据层、明细数据层、汇总数据层和应用数据层的划分，这是快速交付过程中能力子域“无边界”造成的。在数据模型建设过程中，主要基于数据的特征来考量。

（ 1 ）基于数据的业务属性特征，如偏业务预期、业务达成数据。

（ 2 ）基于数据的共享属性特征。此部分数据主要是用来在 IT 组织内部和 IT 组织外部进行共享的数据，如组织数据、需求数据、业务共享数据、成本数据和配置中心数据。

（ 3 ）基于数据的独立性特征，如成本数据、资产数据和经营目标数据。

（ 4 ）基于数据的唯一属性特征，这是 DevOps 数据形成数据网状拓扑的关键特性，一般以 IT 内 部数据为准，如基础架构数据，通过 IP 地址进行南北向的资产数据拓扑扩展；代码质量数据，通过系统版本或系统名称进行质量的趋势回溯；效能数据，通过工号进行阶段性工程效率的度量；版本数据，通过需求吞吐率和研发吞吐率进行版本控制和风险规避。

（ 5 ）基于数据的长期有效的特性，数据模型的使用场景主要为数据基线、链路基线、容量成本基线和质量基线。

在模型阶段，由于 DevOps 数据的独特性，数据“污染”比较严重，数据质量良莠不齐，因此治理和验证数据成为一个难题。这主要体现在数据的强即时性方面，某些基础架构故障会引发一连串的系统级和业务级故障，在业务较为复杂的情况下，这部分数据的“污染”更为动态和复杂，因此需要数据模型具备一定的降噪和治理能力。

3 ．数据的接入和接出

DevOps 数据的接入主要为工具数据的接入，常见的数据来源为 CMDB 数据和 DevOps 工具链运行过程中留存的数据，而工具链留存的数据存在较多的不确定性，如数据保存方式不同、数据标签不同、数据定义不同、数据管理方式不同，因此需要在接入层对数据进行加工和清洗。

数据接入是将数据从数据源系统汇集到数据平台的过程。该过程需要对接入的数据进行清洗、转换、映射、去重、合并和加载，通过一系列的数据加工和处理，形成标准统一的主数据。常用的数据汇集方式如下。

（ 1 ） ETL 抽取，采用 ETL 工具从数据源系统将数据采集到运维数据中台。

（ 2 ）文件传输，采用文件传输方式将文件中的数据导入运维数据中台。

（ 3 ）消息推送，采用消息方式从数据源系统将数据采集到运维数据中台。

（ 4 ）接口推送，采用接口方式从数据源系统将主数据采集到运维数据中台。

（ 5 ）内容爬虫， 一般用于对 Web 页面的数据爬取，适用于无数据留存场景中的数据汇集。

DevOps 数据的接出是将标准化数据分发共享给下游系统的过程。在数据接出过程中，使用的技术与数据汇集技术基本一致。在实施数据接出的过程中，需要根据不同场景选择不同的集成方式，如图 8-5 所示。
![](/home/attachment/202201/13/1225551_164206347526426.png)
图 8-5

对 于 DevOps 数据体系建设，作者和行业专家就是否通过 DevOps 数据中台或数据仓库的方式将 CMDB 数据、监控平台数据、 DevOps 工具链数据、持续交付过程数据和质量管理数据进行集约化采集进行过多次讨论。数据的接入过程其实是多源数据的导入过程，未必所有数据都是有用的，基础架构监控数据和日志平台数据是其中的典型代表。在此期间，接入的数据往往存在重复和冗余。以监控数据为例，同一个事件可能导致大量重复的指标、告警和日志等，在实施过程中，在更接近数据源的位置及早过滤以消除冗余，这不但节省时间，而且能够节省用在冗余的“垃圾”数据上的存储成本和计算成本。因此，理想的方案是在临近数据源的地方进行实时数据处理，尽早进行降噪和聚合，应用自动模式发现、异常检测等算法，只把具有历史分析价值的数据流转到数据中台进行历史分析。

在 DevOps 数据体系建设过程中，对于如何区分主数据和元数据，作者认为， DevOps 最佳实践中所有能力子域的工具和系统留存的数据属于主数据范畴，而数据中台的数据属于元数据范畴，二者的关系可以通过数据的单维到多维变化来识别。在数据集约化采集过程中，对于 CMDB 数据、监控平台数据、 DevOps 工具链数据、持续交付过程数据和质量管理数据，接出的数据状态维持原状，接入的数据在保持按需接入的同时，我们还需要考虑多个数据源存在多维度、海量异构数据的场景。

4 ．数据的变现

数据的变现是实现数据价值的一种方式。和数据的商业化不同， DevOps 数据的变现主要取决于数据的热点运用，使用热度越高，越是“黄金”数据（也可以称为核心数据资产）。在 DevOps 领域，数据的变现主要可以达到下面 3 个目的。

（ 1 ）促进 组织整体协同和降本增效。提升组织级的效能和质量是 DevOps 的价值输出的一个指标，因此，通过数据驱动的方式来实现端到端的流水线交付、端到端的资源交付、端到端的安全输出、端到端的价值交付。基于多能力的交付场景，需要 DevOps 数据标准统一，打通项目、需求、研发、测试、运维和业务运营的各个环节，提升 DevOps 价值交付过程中各能力子域的协作效率，减少因数据不一致而产生的数据传递交换时的沟通成本。

（ 2 ）通过数据实现驱动，达到智能决策的目的。在数据驱动方面，通过数据反馈的方式来 解决价值交付链路中的问题，通过对过程性数据的持续收集和分析来发现交付过程中存在的瓶颈，通过对软件产品和用户的线上数据来获取反馈，通过结果性数据来评价团队的成果。

（ 3 ）提供数据运营服务能力，一方面可以通过数据的不断优化来提升数据的共享和交换能力，另一方面，对数据进行标签化和整合，结合各种场景，输出给数据使用部门，从而实现企业级的全局数据的打通。

## 全部连载

[《DevOps权威指南：IT效能“新基建”》-前言](https://www.talkwithtrend.com/Article/259857 "《DevOps权威指南：IT效能“新基建”》-前言")
[《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.1）](https://www.talkwithtrend.com/Article/259877 "《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.1）")
[《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.2）](https://www.talkwithtrend.com/Article/259881 "《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.2）")
[《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.3）](https://www.talkwithtrend.com/Article/259883 "《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.3）")
[《DevOps权威指南：IT效能“新基建”》-支撑管理（3.1）](https://www.talkwithtrend.com/Article/259939 "《DevOps权威指南：IT效能“新基建”》-支撑管理（3.1）") 
[《DevOps权威指南：IT效能“新基建”》-支撑管理（3.2）](https://www.talkwithtrend.com/Article/259943 "《DevOps权威指南：IT效能“新基建”》-支撑管理（3.2）") 
[《DevOps权威指南：IT效能“新基建”》-支撑管理（3.3）](https://www.talkwithtrend.com/Article/259947 "《DevOps权威指南：IT效能“新基建”》-支撑管理（3.3）")
[《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.1）](https://www.talkwithtrend.com/Article/259949 "《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.1）")
[《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.2）](https://www.talkwithtrend.com/Article/259951 "《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.2）")
[《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.3）](https://www.talkwithtrend.com/Article/259953 "《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.3）")

新基建持续部署持续交付 DevOps

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.1）

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料