为了在市场中保持竞争力的技术公司都在进行某种程度的转型。敏捷转型、数字化转型和DevOps转型无处不在，因为公司试图改变他们的工作方式，从而改善业务结果。

指标(metrics)是任何转型的关键部分。传统的IT绩效指标，例如计算代码行数和软件bug的数量，应该谨慎使用，因为存在不值得修复的bug和不值得维护的代码。这些老式的绩效指标度量的是活动(activities)，而非结果(outcomes)。活动指标很少能告诉组织对业务目标的真正影响是什么。

那么，应该如何度量呢?我们需要考虑Flow(流)相关的指标。Flow指标是一种绩效(performance)指标，它揭示了期望的业务结果的趋势 —— 例如更快的上市时间、对客户的响应以及可预测的发布时间框架。这些业务结果在成功的转型努力中起着至关重要的作用。请允许我向您介绍五个强大的流指标。

Flow Time(流动时间)

Flow Time是衡量一件事从开始到结束需要多长时间。你可能会想，“等等，这不是周期时间(Cycle Time)吗?”。你可能是对的。这取决于使用该定义的上下文。根据你所问的人的不同，“周期时间”有不同的含义，计时可能在不同的时间点开始或停止。理解周期时间是一个模棱两可的术语，这就是为什么我喜欢在讨论速度指标时使用Flow Time。因为Flow Time对于大多数人来说是一个陌生的术语，它提供了一个清晰定义含义的机会。Flow是通过系统顺利且可预测的值，是支撑DevOps的三个基本原则中的第一个。

Flow Time说明：当请求(request)被批准时，计时开始，当变更生效并在生产环境中运行时，计时结束。

Flow Time计算开始时间和结束时间。Flow Time不会因为周末的到来而停止。Flow Time所做的是量化在该时间段内完成给定工作的概率。

例如，如果历史Flow Time显示，某种类型的工作有90%的概率在30天内交付，这样我们就可以说，10次中有9次我们可以30天内交付该类型的工作。我们知道有10%的可能需要更长的时间。这让我们对客户的需求有更好的可预测性。

译注：在DevOps里通常会用到Lead Time(前置时间)这一术语。但Lead Time也来源于工业生产里，这样也会出现歧义。Flow Time这样一个专有名词显然更好。

Flow Efficiency(流动效率)

好的指标让我们有更清晰的全景和对诸如“何时能够完成?”这样的问题有更准确的答案。到期日(due date)这样的指标很少考虑等待时间。然而问题通常不在于处理工作的时间，而在于等待时间。

想想由于工作依赖而造成的延迟——当涉及到需要多长时间完成工作这样的问题时，等待时间往往比实际处理工作时间影响更大。你最好是估计等待时间，而不是工作时间。等待时间通常消耗85%或更多的Flow Time。

译注：这个指标也叫PCE(Process Cycle Efficency)。

WIP Report(在制品报告)

把工作分解成更小的部分是很重要的，这些部分可以很快完成并交付。交付越快，反馈就越快。太多的在制品(WIP)(在Flow Framework中称为“流负载”)，为更多的工作间依赖、更多的冲突优先级、更多的计划外工作悄悄开了口子，这会导致延迟。获取WIP趋势并将其与Flow Time结果进行比较，可以帮助我们了解组织中的WIP与速度之间的关系。

Aging Report(老化报告)

Aging Report展示了工作项在系统中停留的时间。看看系统中有多少工作项停留了超过30天(或60天或120天)，就会发现系统中有多少浪费。下图的例子比较了工作的平均耗时，并突出显示了那些比平均耗时更长的工作项。

译注：方框代表该类型工作的平均耗时，黑线是该工作的实际耗时，粉线代表超出平均时长的时间。

Flow Distribution(流分布)

将工作分成不同的工作类别使我们可以调整工作优先级以及对报告数据做过滤。流分布显示各种工作类别期待的(以及历史的)分布比例，为计划性工作(planned work)分配带来可见性。当有了工作类别后，我们就可以对报告按照类别过滤，比如WIP报告，这反过来可以帮助改进WIP设定及可预测性。

译注：工作类型是每个组织自己定义的。比如在《凤凰项目》里，定义了四种类型的工作：业务相关的，运维的日常维护工作，变更，以及计划外工作。

根据工作状况，WIP设定可能需要调整。比如刚刚发布了一个新特性，那么处理缺陷或技术债务可能会优先于引入更多特性。如果这时选择继续做更多的特性工作，它将占用其他工作类型时间，比如修复与技术债务相关的问题。对工作类型分布进行分类和度量有助于进行优先级排序。

映射指标和结果

如果上市时间(time-to-market)是追求的结果，那就度量Flow Time(流动时间)，帮助别人了解事情实际上要花多长时间。

如果效率是你追求的结果，那就度量Flow Efficiency(流动效率)，以查看瓶颈点，因此将重点放在能够改善流的地方。当涉及到流时，优化一个非瓶颈点并没有什么帮助。

如果团队正在处理计划外的工作和/或优先级冲突，那么就度量WIP数量(WIP Report)以暴露分配工作过多的团队。说到效率，如果过多地关注资源效率而不是流效率，那么其实是在浪费时间。

如果忽略了未完成的重要工作(如修复安全漏洞)，则应度量未完成工作在系统里停留的时间(Aging Report)以暴露风险。就像一座正在建造中的桥梁，在它完成之前，是不产生任何价值的。

如果某些类型的重要工作(比如修复技术债务)没有相应的优先级，则应度量工作类型的分布(Flow Distribution)，以使与工作分配相关的问题变得可见。

原文链接：https://www.tasktop.com/blog/5-best-metrics-youve-never-met/

【本文为51CTO专栏作者“徐磊”的原创稿件，转载请通过作者微信公众号devopshub获取授权】

戳这里，看该作者更多好文

【编辑推荐】

外媒速递：十款开发者不容错过的DevOps友好型免费安全工具

外媒速递：五款卓越开源DevOps工具轻松实现自动化转型

外媒速递：DevOps终极指南与关键收益解读

京东金融以应用为中心的DevOps体系建设

从DevOps到AIOps，阿里如何实现智能化运维？