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

8.3 DevOps 数据在运维领域的使用场景

在 DevOps 数据体系中，数据的重要使用场景大致分为项目管理、需求吞吐流水线、研发吞吐流水线、代码质量管理、运维管理和项目后评价。在运维领域，适合将 DevOps 数据与大数据技术、算法技术、 AI 进行结合，进行高阶场景的落地，在全链路监控、故障分析和根因分析等场景中使用。

8.3.1 DevOps 数据在运维领域使用时的难点

对于狭义的运维，数据的覆盖面较小，数据以实现系统稳定和资源管理为主，大致分为 3 类：资源元数据、系统状态数据和事件类数据。其中，资源元数据主要覆盖基础架构、标准化支撑组件、虚拟资源数据，以及相关属性；系统状态数据以各类监控输出为主，如使用率、存活状态、支撑能力，以及系统级、组件级、请求级的链路交互和拓扑；事件类数据一般用于描述系统和设备的变更，业务系统的异常，流程节点的阻断和策略。

对于广义的运维，数据的覆盖面大小取决于企业的业务复杂度和组织架构职能的交叉延伸。在狭义的运维数据的覆盖面之上，广义的运维数据还包括业务数据、运营数据、工程效率数据和用户体验数据。相应地，衍生出复杂的数据使用场景、数据处理规则、数据关联关系和复杂的运维数据输出能力。

运维数据输出场景有 4 个前置阶段，分别为场景适配、运维数据中台、运维工程体系和运维数据策略，本节主要对场景适配进行阐述。在这 4 个前置阶段，存在一些共同的获取数据的难点，如不确定的数据来源、多种数据类型和基于场景的数据关联变化，相关内容见表 8-1 。

表 8-1

8.3.2 适合使用的高阶场景

在运维数据输出场景中，大多数场景需要依赖数据的时效性和数据的获取方式。数据处理时效规则分 3 种：离线数据处理规则、近线数据处理规则和实时数据处理规则。数据获取的方式一般包括周期性地拉取数据、周期性地主动推送数据和实时获取数据。在数据运用和场景适配阶段，离线数据适用于指标统计类，近线数据适用于智能监控的故障诊断和预测，实时数据适用于“自愈”场景、无人值守场景和自动调度场景。下面以知识图谱、故障自动评估、无人值守变更和动态阈值高阶场景为例，分别阐述相应的实施方法。

1 ．知识图谱

知识 图谱的广泛应用始于 Google 搜索服务。从此，知识图谱的 数据输出能力得到拓展，常见的是各类知识库。在运维领域，很多高阶的运维数据运用知识图谱，尤其是基于海量数据的颗粒度关联和数据在聚合场景下的应用，通俗点说，基于运维的知识图谱是基于业务连续性框架下的运维知识工程。

知识图谱是采用数据聚合和运维策略的 CMDB 进阶方式。在云环境下，如果某个宿主机重启，知识图谱就会“告诉”我们这个宿主机上运行了哪些虚拟机，部署了什么系统，承接了什么业务，这些系统的服务状态会影响哪些下游系统，下游系统会影响什么业务场景，对业务链路会造成什么影响，对正常展业会带来什么风险。上述就是知识图谱的“能力”输出方式。

在知识图谱的落地过程中，我们需要打通基础架构、系统架构、业务架构的数据层次和数据颗粒度的关系，如 CMDB 、配置中心和接口系统，甚至需要对接业务需求系统，在比较理想的情况下，获取完整的结构化数据。同时，通过运维策略和业务规则进行数据关系的映射，对运维数据不断进行筛选和知识验证，最终实现正确的运维知识结构。某业务的知识图谱示例如表 8-2 所示。

表 8-2

在表 8-2 所示的关联关系中，我们可以发现一些不合理的地方，如系统 C 部署在同一个物理机上， Redis 集群的主节点 1 和从节点 1 部署在同一个物理机上，系统 C 的 d 接口是一个公共接口，集群规模不够大。通过知识图谱的一些图形化能力，可以便捷地查询结果，展现各能力子域较为全面的知识，还可以进阶为更高级的语义匹配能力。知识图谱在运维领域主要构建了常见的容量场景、业务链路场景和故障场景，通过策略判断对数据输出实现辅助决策功能。对于 DevOps ，知识图谱实现了一定的数据“思考”和数据“推理”，和监控系统打通，能够实现系统的事前 / 事中的风险判断和风险溯源。

2 ．故障自动评估

故障自动评估有较多应用场景，如应急演练时快速规避盲测带来的风险，故障发生时快速判断其对业务的影响。故障自动评估是基于运维知识图谱实现的。

下面以表 8-2 中的关联关系为例，进行一些延伸。当我们对宿主机 1 ～ 6 进行数量枚举时，“死”机一台有 6 种方式，“死”机两台有 15 种方式，“死”机三台的概率较小，不做分析，此处还可以结合数据中心和机柜的信息进行数据聚合。针对“死”机一台进行分析得到，宿主机 3 和宿主机 4 “死”机对业务链路产生中断影响。

在故障自动评估中，有一点需要特别关注，那就是数据的边界。数据的边界大致分为 3 类：面向基础架构的数据边界、面向应用系统的数据边界和面向业务保障的数据边界。在这个过程中，需要将这些数据边界完全打破，形成多层次的颗粒化数据展现。

在故障自动评估落地过程中，有一点值得关注，业务侧的运维数据分析和业务连续性评估方法是顶层设计，将业务逻辑、数据流和基础架构集成数据进行分析评估，并实现多个运维数据模型的输出汇总，在业务服务的场景下进行数据映射。

场景识别是 CMDB 能否成为运维知识图谱的关键。如果不考虑将价值交付进行嵌入，那么基于流程的场景识别和基于业务服务化的场景识别是运维数据的高阶使用中必不可少的抓手。

3 ．无人值守变更

变更在运维领域是核心输出能力。在项目上线和产品投产环节，变更是最后一个步骤，变更的成功与否至关重要。在运维领域无人值守变更并不是指没有人参与，而是指无须人员过度参与。

在上线变更过程中，变更前，评估变更步骤和上线策略，其中包括代码变更、数据库变更、网络策略变更、流量切换、业务开关和策略；变更中，执行变更策略和上线策略，确保变更有序、正确；变更后，执行系统和业务检查。

在很多企业中，运维人员关注监控、发布单、机器、业务故障预警， 监控能够反映当前系统的一些状况，如机器的负载是否上升了，接口的成功率是否下降了；发布单则能让我们了解当前的发布情况，如有多少机器已经更新到新版本，有多少机器还在运行旧版本，有多少机器启动后又遇到异常等；通过机器，则可以查看一些日志信息，如是否出现了一些新异常，异常的数量是否很大。这种变更方式被很多企业接受，但是人毕竟有其局限性，如果运维 人员责任心不强、流量过大导致数据刷新过快，或者运维人员对业务指标不熟悉，那么容易造成变更过程中的故障被疏忽，因此，我们需要无人值守变更。

一般情况下，无人值守变更需要具备下列条件：具备业务线的发布的先后顺序，系统之间发布的阻断条件，如 A 系统发布成功后，执行 B 系统发布， B 系统成功发布后，可以同时对 C 、 D 、 E 系统进行发布；业务开关策略需要纳入自动变更体系，如 A 系统发布后，关闭某个挂起任务；必须提供完善的验证条件，如最新包验证、异常启动日志验证、无日志验证和异常业务日志验证；触发阻断后自动回退；基于业务指标的监控回检，如用户流量、业务成功率和异常指标的同比 / 环比。

无人值守变更是运维数据高阶运用的典型，通过对接发布策略、基础架构、全链路监控和数据分析系统，对发布过程中的流量数据进行采集分析和比对，进行结果的判断。事后针对历史变更故障异常集的回放属于更高阶的功能。

检验无人值守变更成功的推荐方式是事后验证，通过业务监控的召回率和准确率指标来回溯，优先保证准确率，其次是召回率。

4 ．动态阈值

动态阈值在智能运维领域是个热门，最佳实践案例也较多，下面简单介绍一下动态阈值的一些基本方法和应用场景。

动态阈值经常应用在高流量且突增突降的电商生态场景中，如数据源输出、支付、线上抢购。此类生态系统的运维方式和普通的运维方式相比，存在诸多不同，如监控指标繁多，动辄上万个监控指标，且配置复杂，一旦用户流量呈几何级增长，准确率和召回率断崖式下降，同时会出现剧烈的报警“风暴”，噪音也呈几何级上升态势。因此，调整监控阈值并不是一个好办法，只能通过数据挖掘或机器学习来实现阈值的自动调整。

数据偏差的 3 类场景：数据的环比 / 同比出现明显问题，周期内的数据出现持续偏离问题，数据指标在周期内发生较为明显的漂移。

在实际的业务场景中，结合数据偏差对应 3 种阈值类型：周期性波动的数据，如非活动期间的接口的平均耗时和活动期间的接口的平均耗时，以及工作日流量和非工作日流量，此类数据一般按天计算；某些时间点的突变数据，如接口的峰值耗时和数量，此类数据主要体现在局部数据的影响放大，针对此类数据的处理，需要谨慎，并考虑场外因素如发布、第三方外部系统导致的短暂异常；毛刺数据在寻常监控中难以被发现，对于全局数据，毛刺数据对均值和阈值基线不会产生影响，但对“抢购”场景中的“洪峰”阈值存在较大的不确定性，因此，在阈值方面，要进行一些滤波操作。

在报警“风暴”方面，除对报警信息按照系统级进行收敛以外，还需要有依赖策略。根据知识图谱的数据关联，进行基础架构和业务系统的关键字数据匹配，对告警信息进行依赖匹配。例如，某个宿主机“死”机，宿主机承载的虚拟机出现请求失败，秒级和分钟级的数据呈现势必引起较高的峰值耗时和熔断数量，对业务指标的影响不会放大，因此需要对服务器“死”机和接口耗时进行策略依赖与异常依赖，避免报警“风暴”和额外的人力投入，这就是通过传统的数据挖掘来实现数据特征的关联分析。

故障处理包括 4 个阶段：故障发现、故障处理、故障恢复和故障总结，动态阈值是故障发现的重要一环。

8.4 构建 DevOps 度量体系

构建 DevOps 度量体系需要先达到两个重要的前置要求： DevOps 所有成员，包括 DevOps 管理者、 DevOps 推动者和 DevOps 价值交付全链路中所有的能力子域，具备科学的数据思维；需要进行 DevOps 数据体系的建设和管理。 DevOps 度量体系是 DevOps 最佳实践的后置阶段，也是流程驱动到数据驱动的重要支撑。根据中国信息通信研究院的统计报告，传统企业对 DevOps 的接受程度比互联网企业高，这是企业转型的需要，也是技术革新的趋势。目前，国内大多数相关企业已经进入 DevOps 实践的“深水区”，不再局限于流水线的构建和工具的自动化，尤其在全面数字化运营理念的推动下， DevOps 的最佳实践逐步进入度量和反馈阶段。近几年，超过 10 家头部传统企业通过了《研发运营一体化（ DevOps ）能力成熟度模型》三级评估。

8.4.1 度量体系的重要性

通过 DevOps 最佳实践的经典案例，我们不难看出， DevOps 加速了软件产品的集成和部署，实现了端到端的持续交付，以流程驱动的方式打通端到端的交付通道。作者认为，在 DevOps 的最佳实践中，度量环节有一个难点需要消除，即交付全链路数据还采取 断点的、无序的、度量性较差的传统方式，缺乏配套的全链路数据采集、管理、汇聚和输出，导致 DevOps 价值交付过程中的管控和交付后评价缺乏科学、客观的可度量数据与度量体系，进而流程驱动在积累一段时间后不能快速推进至流程和数据双驱动的模式。

建立健全的度量体系在 DevOps 最佳实践中具有普遍性，有助于价值交付在更大范围内通过数据的能力输出实现 效率提升、质量保证、成本集约、业务创新和客户满意 。更大范围地进行 DevOps 最佳实践，有助于提升组织级的质量和效率。

根据《中国 DevOps 现状调查报告（ 2020 ）》中的内容， DevOps 数据体系包含 3 个方面，分别为数据归集、数据应用和数据开放， DevOps 数据输出能力包含 5 个方面，分别为数据服务产品化、数据服务平台化、数据使用场景化、数据管理精益化和数据运营体系化。在 DevOps 度量阶段，落地过程遵循 DevOps 实践原则，从自动化、平台化、数据化，到最终的智能化，阶段性地进行落地，恰好凸显了 DevOps 数据在不同阶段对 DevOps 工具的纳管能力，以及数据的采集、数据的聚合、数据的计算、数据的链路构建、数据的输出和数据的驱动。从交付的层面进行分析，价值交付的节点大致分为项目管理、业务需求、产品需求、资源管理、开发管理、测试管理、运维管理、安全管理、投产管理和项目后评价管理。随着 DevOps 度量体系的完善，贯穿始终的角色越来越多，这和 DevOps 提倡的模糊边界有直接的联系。 DevOps 数据度量过程如图 8-6 所示。

图 8-6

8.4.2 DevOps 度量体系的建设过程

构建 DevOps 生态的方法有下列 4 种：以项目生命周期数据为基准、以资源数据为 基准、以交付数据为基准和以监控数据为基准，如图 8-7 所示。在这 4 种方式中，各“窗口期”的度量体系各不相同，以项目周期数据和交付数据为例，包括资产、资源、版本质量、组织效率、工程环境；以资源数据和监控数据为例，主要体现在项目后评价和成本复盘方面。

图 8-7

通过度量来进行过程和结果的管控，通过度量来优化现有流程，应执行 4 个步骤，分别为归集度量数据指标、度量数据指标拆解、确定度量数据维度和构建 DevOps 全链路度量体系。

1 ．归集度量数据指标

构建一个度量指标体系，首先需要根据 DevOps 落地的方式获取 DevOps 的相关指标。此处需要明确一个观点，任何度量的终极目标是为了更好地进行管理，有针对性地进行优化，从而使 DevOps 的价值最大化。以项目生命周期管理流程为例，归集所有数据指标，如图 8-8 所示。

图 8-8

基 于项目生命周期管理的终极目标在于交付的价值和投入产出比的最大化。如果体现在数 据指标上，那么直接的两个指标为过程管理和项目后评价，其中过程管理分为两大类：工程效率和人员效能。项目后评价侧重项目达成和资源投入，具体在指标分解中体现。

任何项目或产品的上线都会有生命周期，即项目版本确定到项目上线的过程。这个过程可以分成多个阶段。我们只需要思考清楚如何在每个阶段又快又好地达成终极目标，就可以归集出整个周期所需的大部分数据。项目生命周期管理按顺序可以分为 5 个阶段，如图 8-9 所示。

图 8-9

项目投产阶段是项目生命周期的重要阶段，由两方面构成，即产品的交付和运维，以及产品运营。因此，项目投产阶段的质量决定了产品最大盈利的周期和产品的寿命。因此，项目投产阶段的工作是将能调度的资源尽可能地投入这个阶段。产品经理眼中的项目生命周期如图 8-10 所示。

图 8-10

项目评价阶段是成本复盘的重要阶段，可以获得人力资源、软硬件资源的投入和产品在运营后的产出比，可以判断项目或产品成功与否，是进行项目和产品优化的重要手段。数据驱动的评价反馈环如图 8-11 所示。

图 8-11

2 ．度量数据指标拆解

归集完涉及的指标后，通常存在一个问题，即指标多且复杂。在具体的度量过程中，存在不同阶段重点关注的指标不一样的情况，如需求阶段关注需求的吞吐量和需求总数，研发阶段关注研发效率和研发质量，测试阶段关注测试覆盖率和缺陷修复情况。在不同的 DevOps 阶段，需要挑选出对应阶段的核心指标，然后进行指标拆解，接着根据拆解的指标进行度量，并根据度量情况有针对性地进行重点关注。

在度量数据指标拆解之前，需要明确流程驱动和数据驱动的区别。流程驱动类似于 ITIL （ IT 服务流程），包含问题管理、事件管理、变更管理和业务连续性管理等指标。而数据驱动更关注以结果为导向的指标，可优化、可回溯的特性较为明显。在流程驱动的过程中，通常存在一个严重的问题需要解决，解决的过程成为完成流程驱动的过程，在过程中，会进入一个误区，实现的执行手段和目标愿景是相悖的，这也是流程驱动转变至数据驱动，或者流程和数据的双轨驱动的需求。

通俗地讲，流程驱动让你在正确的道路上向前走，而数据驱动可以确保你在正确的道路上持续地向前走。提升组织级的效率和质量，需要整体优化，在进行度量指标拆解的过程，需要关注两个问题：为什么需要这个指标？从这些指标中，能够获得什么？

下面以项目生命周期为基准的流水线举例，进行指标拆解。常用的指标有项目指标、需求指标、版本指标、团队指标、资源指标、构建指标、质量指标、环境指标、部署指标、监控指标和项目后评价指标。

（ 1 ）项目指标：项目进度、项目工时和项目质量。

（ 2 ）需求指标：需求总数、各状态的需求总数、当前的需求完成情况、各业务方的需求总数和需求吞吐率。

（ 3 ）版本指标：版本数量、分支数量、仓库数量、代码提交数和代码提交频率。

（ 4 ）团队指标：团队情况、人员情况、任务分解情况、团队管理的系统情况、团队承接需求情况和团队承接任务情况。

（ 5 ）资源指标：工程环境数量、系统分配资源情况、团队分配资源情况、人员分配资源情况、资源可用数据、资源使用数据和资源性能数据。

（ 6 ）构建指标：构建次数、构建频率、构建时长和构建成功率。

（ 7 ）质量指标： “坏味道”数量、阻塞数量、代码行数、代码重复率、代码问题数、单元测试用例数、单元测试覆盖率、单元测试执行结果、自动化测试用例数、自动化测试成功率、手动测试用例数、 bug 数量、团队 bug 数量、人员 bug 数量、 bug 修复时长和千行代码 bug 数。

（ 8 ）环境指标：环境变更时长、环境变更频率、环境不可用时长和工程环境数量。

（ 9 ）部署指标：部署次数、部署时长、变更时长、部署成功率、总体变更成功率和一次变更成功率。

（ 10 ）监控指标：监 控覆盖率、监控送达率、监控准确率、线上问题统计和线上问题恢复时长。

（ 11 ）项目后评价指标：以产品运营核心指标为准，如 PV/UV 、行为、转化率和利润。

3 ．确定度量数据维度

在确定度量数据维度之前，需要明确 DevOps 度量与反馈的两种常用方式：通过数据结果维度进行度量和通过数据类型维度进行度量。软件是数字化的事物，虽然度量的方式有多种，但相应的度量指标可以用 3 个特性进行概括，分别是可具体的特性、可实现的特性和有时限的特性。

通过数据结果维度进行度量，有 4 种方式：计数实施，统计度量指标的数量、度量任务的数量、偏差的数量；测量测算，统计状态的数据信息，如区间内的递增值和递减值；数据分布，统计数据的分布情况，如最大值、最小值、平均值、中位数和百分比；计时，统计单位时间内的消耗时间和分布情况。

通过数据类型维度进行度量，可分为时间维度，如秒、分、时、天、周、月和年；组织架构，如 A 团队、 B 团队和 C 团队；渠道，如 A 渠道、 B 渠道和 C 渠道；系统类型，如公众号、官网和 App 。

在进行度量数据维度考核的过程中，需要关注下列问题：度量本身的问题、度量的误区和度量指标不能动态调整。

（ 1 ）度量本身的问题包括度量的可视化程度不够、工作切分随意和敏捷交付过程中存在多项目并行的情况。

（ 2 ）度量的误区主要体现在过度考核虚荣性指标，如日均代码量、局部单元测试覆盖率和工时统计等。当虚荣性指标成为核心度量指标时，就是“灾难”的开始。

（ 3 ）度量指标不能动态调整。随着团队效能的提升，指标也随之调整，否则将使团队的效能停滞不前。

确定度量指标维度时应关注下列 4 种关系。

（ 1 ）全局指标和局部指标的关系。对局部指标过度进行优化，可能使全局劣势，因此要将提升全局指标的达成率作为目标。

（ 2 ）定量指标和定性指标的关系。尽量使用量化指标的客观评价，让流程驱动尽快延伸至数据驱动。

（ 3 ）团队指标和个人指标的关系。设定指标是为了促进团队协作，提升组织级的效能和质量。

（ 4 ）结果指标和过程指标的关系。通过结果指标来评估结果，通过过程指标来优化改进，二者不是简单的包含和被包含的关系。

4 ．构建 DevOps 全链路度量体系

通过流程和数据双轨驱动的 DevOps 度量体系建设，打造和构建全链路的度量方式，通过自动化部署流水线，有效提高软件交付的效率，通过质量内建，确保软件交付的质量，通过对过程性数据的持续收集和分析，发现交付过程中存在的瓶颈，通过软件产品和用户的线上数据，获取反馈并及时进行调整，通过结果性数据，评价团队的成果。

全部连载

《DevOps权威指南：IT效能“新基建”》-前言
《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.1）
《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.2）
《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.3）
《DevOps权威指南：IT效能“新基建”》-支撑管理（3.1）
《DevOps权威指南：IT效能“新基建”》-支撑管理（3.2）
《DevOps权威指南：IT效能“新基建”》-支撑管理（3.3）
《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.1）
《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.2）
《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.3）