你从未见过的五个强大的DevOps指标

为了在市场中保持竞争力的技术公司都在进行某种程度的转型。敏捷转型、数字化转型和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(流分布)