随着 DevOps 的持续火热，企业的信息化能力的持续加强，以及企业对于IT精益运行的迫切需要，从根本上提升 IT 的生产效率，加速部门、企业的业务创新能力。让团队从IT支撑部门，转向为IT创新部门。
苏宁消费金融践行 DevOps 过程中，发现交付服务重要组成部分，交付全链路数据，还采取断点的、无序的、度量性较差的传统方式，缺乏配套的全链路数据采集、管理、汇聚和输出，导致项目交付过程中的管控和交付后的评价缺乏科学、客观的可度量数据和度量体系，进而由流程驱动在积累一段时间后不能快速的推进至流程和数据双驱动的模式。
建立健全的度量体系的需求在 DevOps 领域具有普遍性，有助于在更大范围内快速实现可度量的价值交付，拓展了业界的 DevOps 适用范围，有助于更好提升组织级的质量和效率。
在正文之前，先谈一下IT运维数据的发展历程和 DevOps 落地的几种方式，以及各个窗口期运维数据的输出方式。
根据《企业IT运维发展白皮书》所述，IT运维技术可以从自动化运维能力、平台化运维能力、数据化运维能力和智能化运维能力四个层次进行阶段性落地尝试，这四个阶段恰好凸显了运维数据在不同阶段对运维工具的纳管能力、数据的采集、数据的聚合、数据的计算、数据的链路构建、数据的输出、数据的驱动。
从交付的层面来说，价值交付的各个节点大致分为如下，版本、产品需求、资源、研发、测试、运维、项目投产、项目后评价，仅有两个角色是贯穿始终的，那就是运维和项目管控，而这两个角色分别需要解决数据的管理和数据的度量。
DevOps落地的方式大致有四种，如下图所示，（1）以项目周期数据为基准的；（2）以资源数据为基准的；（3）以交付数据为基准的；（4）以监控数据为基准的。
在这四种方式中，各窗口期的运维数据输出方式各不相同，以1、3为例，度量的手段囊括了资产、资源、版本质量、组织效率、工程环境，以2、4为例，更多的体现在项目的后评价、成本化复盘方面。
度量如何做，如何通过度量来进行过程和结果的管控，如何通过度量来优化现有流程，笔者认为遵循以下几点步骤。1、归集度量数据指标；2、度量数据指标拆解；3、确定度量数据维度；4、构建 DevOps 全链路度量体系。
一、归集度量数据指标
在 DevOps 方法论的论述中，构建一个度量指标体系，首先需要根据 DevOps 落地的方式来了解 DevOps 的相关指标都有什么。
在这之前需要明确一个观点，任何度量的终极目标都是为了更好管理和更有针对性的优化，从而使 DevOps 价值最大化。
接下来就以项目生命周期管理流程为例来归集所有数据指标，下图为苏宁消费金融以项目生命周期为基准的流水线，以此为例。
1、基于项目生命周期管理的终极目标在于交付的价值和投入产出比的最大化。所以体现在数据指标上，最直接的两个指标就是过程管理和项目后评价，其中过程管理又分为两个大类，分别为工程效率和人员能效。而项目后评价则侧重于项目达成和资源投入，具体的在指标分解中体现。
2、任何项目或者产品的上线都会有生命周期，即项目版本确定到项目上线的一个过程。而这个过程是可以分成多个阶段的。只要我们思考清楚如何使每个阶段的又快又好的达成终极目标，我们就可以归集出整个周期内所需要的大部分数据。项目生命周期管理按顺序可以分为五大阶段：
3、产品投产阶段是实现产品阶段性目标的重要阶段，所以我们要做的工作就是使能调度的资源都进入阶段。所以在产品眼中，其实希望产品生命周期是这样演变的。
4、项目后评价阶段是进行成本复盘的重要阶段，是判断人力资源、软硬件资源的投入和产品运营后的产出对比，也是判断项目或产品的成功与否，更是从较高的视野来进行项目和产品优化的重要手段。
二、度量数据指标拆解
归集完所涉及的指标后，会发现指标很多。但是在具体的度量中，可能不同阶段重点关注的指标不一样。例如需求阶段关注需求的吞吐量和需求总数，研发阶段更关注研发效率和研发质量。所以对于不同的交付阶段，我们需要挑选出该阶段的核心指标，然后进行拆解，再根据拆解的指标去重点关注。
在度量数据指标拆解之前，说一下流程驱动和数据驱动的区别。流程驱动更类似于ITIL（IT服务流程），分别有问题管理、事件管理、变更管理、业务连续性管理等指标。而数据驱动更关注以结果为导向的指标，可优化可回溯的特性较为明显，即交付价值。
在流程驱动的过程中，我们会发现有一个严重的问题需要我们去解决，那就是为了完成流程驱动，有可能实现的执行手段和目标所达成的愿景是相悖的，这也是流程驱动转变至数据驱动，或者说流程和数据的双轨驱动的需求。
简单的总结一下，流程驱动让你在正确的道路上往前走，而数据驱动是持续的确保你往正确的道路上走。而提升组织级的效率和质量，你需要整体性的优化，当你进行度量指标拆解的时候，你需要关注两个问题，①为什么需要这个指标；②从这些指标中，你能够获得什么。
同样拿苏宁消费金融项目生命周期为基准的流水线举例，进行指标拆解：
项目指标：项目进度、项目工时、项目质量
需求指标：需求总数、各状态的需求总数、当前的需求完成情况、各业务方的需求总数、需求吞吐率
版本指标：版本数量、分支数量、仓库数量、代码提交数、代码提交频率
团队指标：团队情况、人员情况、任务分解情况、团队所管理系统情况、团队承接需求情况、团队承接任务情况
资源指标：工程环境数量、系统分配资源情况、团队分配资源情况、人员分配资源情况、资源可用数据、资源使用数据、资源性能数据
构建指标：构建次数、构建频率、构建时长、构建成功率
质量指标：坏味道数量、阻塞数量、代码行数、代码重复率、代码问题数、单元测试用例数、单元测试覆盖率、单元测试执行结果、自动化测试用例数、自动化测试成功率、手动测试用例数、BUG数量、团队BUG数量、人员BUG数量、BUG修复时长、千行代码BUG数
环境指标：环境变更时长、环境变更评率、环境不可用时长、工程环境数量
部署指标：部署次数、部署时长、变更时长、部署成功率、总体变更成功率、一次变更成功率
监控指标：监控覆盖率、监控送达率、监控准确率、线上问题统计、线上问题恢复时长
项目后评价指标：以产品运营核心指标为准 ，如PV\UV、行为、转化率、利润
三、确定度量数据维度
在确定度量数据维度之前，介绍下业内两种常用的方式，①数字维度，②类型维度。
软件是数字化的事物，根据度量维度的不同，涵盖相应的指标类型分别有
可具体的；
可度量的；
可实现的；
现实性的；
有时限的。
而具体的实施有几种方式，
计数实施，统计度量指标的数量、度量任务的数量、偏差的数量；
测量测算，统计状态的数据信息，如区间内递增值和递减值；
数据分布，统计数据的分布情况，如最大值、最小值、平均值、中位数、百分比；
计时，统计单位时间内的消耗时间和分布情况；
按类型维度，可分为时间维度，如秒、分、时、天、周、月、年；按组织架构，如A团队、B团队、C团队；按渠道，如A渠道、B渠道、C渠道；按系统类型，如公众号、官网、APP、IOS。
在进行度量数据维度考核的时候，会有一些难点需要考虑。①度量的难点；②度量的误区；③度量指标不能动态调整。
度量的难点，主要集中在度量的可视化不够健全、工作切分的随意性、敏捷交付过程中存在多项目的并行；
度量的误区，主要集中在过渡考核虚荣性指标，如日均代码量，局部单元测试覆盖率，工时统计等等，当虚荣性指标成为核心度量指标，那就是灾难的开始。
度量指标不能动态调整，随着团队的效能提升，指标也随之调整，否则将使团队的效能停滞不前。
确定度量指标维度有四个原则，分别是：
①全局指标和局部指标的关系，过渡对局部指标进行优化可能使全局劣势，因此要提升全局指标的达成率为目标。
②定量指标和定性指标的关系，尽量使用量化指标的客观评价，让流程驱动尽快延伸至数据驱动。
③团队指标和个人指标的关系，指标的设定是促进团队协作，提升组织级的能效和质量，不能因个人指标的关系造成团队和谐。
④结果指标和过程指标的关系，通过结果指标来评估结果，通过过程指标来优化改进，二者不是简单的包含和被包含的关系。
四、构建 DevOps 全链路度量体系
对于流程和数据双轨驱动的DevOps，打造和构建全链路的度量体系，通过自动化部署流水线有效提高软件交付的效率，通过质量内建确保软件交付的质量，通过对过程性数据的持续收集和分析发现交付过程中存在的瓶颈，通过对软件产品和用户的线上数据获取反馈并且及时作出调整，通过结果性数据去评价团队的成效。
以DevOps价值服务输出模型作为本次文章的结尾。
