下载掌阅APP，畅读海量书库
立即打开
成功转型的关键是衡量和理解正确的事情，并关注能力。
Forsgren.N ., Humble . J. 和 Kim . G. （ 2018 ） p.38
要衡量在转型过程中所处的位置，最好关注DORA中使用的四个指标，两项为性能，两项为稳定性。
●交付性能指标：
-交付前置时间
-部署频率
●稳定性指标：
-平均故障恢复时间
-变更失败率
交付前置时间（Delivery Lead Time，DLT）是指从工程师开始开发某个功能到最终用户可以使用该功能的时长。另一种说法是“从代码提交到生产环境”，但通常情况下，从团队开始处理某个需求并将状态变为“进行中”时开始计时。
从系统中自动获取这个指标并不容易。第7章展示如何使用GitHub Actions和Projects来自动化度量。如果没有从系统中获取指标，可以使用以下选项设置一个调查：
●少于1小时
●少于1天
●少于1周
●少于1个月
●少于半年
●超过半年
根据实际情况在量表上的位置，可以或多或少进行调查。当然，更可取的是系统生成的值，但如果实际情况以月份为单位甚至更长，那就无所谓了。如果以小时或天为单位，就更有趣了。
从精益管理的角度来看，前置时间（Lead Time，LT）将是更好的指标：从理解客户反馈到整个系统需要多长时间？但是软件工程中的需求是复杂的，在实际工程工作开始之前，通常会涉及许多步骤。如果必须依赖调查数据，那么变化会很大，指标很难猜测。有些需求可以排期至几个月后，有些只需要几个小时。从工程角度来看，专注于交付前置周期要好得多。第18章会详细介绍关于前置时间的内容。
部署频率侧重于速度。交付变更需要多长时间？更关注吞吐量的指标是部署频率。多久部署一次变更到生产环境？部署频率表示批量大小规模。在精益制造中，人们希望减少批量的规模大小。部署频率越高，批量的规模越小。
乍一看，在系统中测量部署频率看起来很容易。但仔细观察一下，有多少部署真正部署到生产环境中了？在第7章中将解释如何使用GitHub Actions获取该指标。
如果暂时不能自动测量该指标，也可以使用调查表，并使用以下选项：
●灵活（每天多次）
●每小时一次到每天一次
●每天一次到每周一次
●每周一次到每月一次
●每月一次到每半年一次
●小于半年一次
平均故障恢复时间（MTTR）是衡量稳定性的一个很好的指标。这衡量了在出现中断时恢复产品或服务所需的时间。如果测量正常运行时间，它基本上就是服务不可用的时间跨度。要测量正常运行时间，可以使用冒烟测试。例如Application Insights（参见https://docs.microsoft.com/en-us/azure/azure-monitor/app/monitor-web-app-availability）。如果应用程序安装在客户端上，并且不可远程访问，那么情况就更复杂了。通常，可以查看帮助台系统中特定工单类型的处理时间来进行评估。
如果无法自动测量，仍然可以使用以下选项进行调查：
●少于1小时
●少于1天
●少于1周
●少于1个月
●少于半年
●超过半年
但这应该是最后的手段。MTTR应该是一个很容易从系统中自动得到的指标。
与交付前置时间用于衡量性能一样，平均故障恢复时间是衡量稳定性的时间指标。部署频率与吞吐量相关的特性是变更失败率（CFR）：有多少次部署导致在生产环境中的故障？CFR使用百分比呈现。要决定哪些部署应该计入该指标，应该使用与部署频率相同的定义。
这四个基于DORA研究的指标是衡量在DevOps实施过程中所处位置的好方法。在仪表盘上可视化这些指标，是改变与管理层交流方式的一个很好的起点。别担心自己还不是一名优秀的员工，最重要的是要不断进步。
从基于调查获取的数值开始很简单。但如果想使用自动生成的系统数据，可以使用“Four Keys Project”在仪表盘上美观地显示数据（见图1-4）。
图1-4 “四要素”仪表盘
该项目基于谷歌云，并且是开源的，（https://github.com/GoogleCloudPlatform/fourkeys），但它依赖于webhooks从项目中获取数据。第7章将介绍如何使用webhooks将数据发送到仪表盘。
需要注意的是，这些指标不能用于进行团队相互比较。可以汇总这些指标以概述组织情况，但不要用于比较单个团队！每个团队都有不同的实际情况。重要的是使用的度量标准朝着正确的方向发展。
此外，度量不应该成为目标，仅仅为了获得更好的指标是不可取的。重点应该始终放在在本书中讨论的与这些指标相关的能力上。专注于发展能力，度量标准将随之而来。