9.1 术语表

本书全书所使用的术语和缩写的定义。每个词条都标明了该术语被深入介绍的主题。

活动指标（Activity metric）。 对工程动作（提交、拉取请求、代码行数）的计数，衡量的是数量，而不是价值。参见主题 3.4。

巴士因子（Bus factor）。 需要有多少人变得不可用，一个系统或一项知识才会变得无法维护。巴士因子为一是一种严重的风险。参见主题 3.5。

变更失败率（Change failure rate）。 导致需要补救的生产故障的部署所占的百分比。DORA四项指标之一。参见主题 2.10。

控制图（Control chart）。 一种显示一项指标随时间变化的正常变异范围的图表，用于把一次真实的变动与普通噪声区分开来。参见主题 1.6。

周期时间（Cycle time）。 交付周期的内部构成，被分解为编码、评审、测试和部署等阶段。参见主题 2.6。

CVSS（通用漏洞评分系统，Common Vulnerability Scoring System）。 一种为安全漏洞的严重程度评分的标准化量表。参见主题 6.4。

圈复杂度（Cyclomatic complexity）。 对一段代码控制流中独立路径的计数，由Thomas J. McCabe于1976年提出。参见主题 4.1。

DevEx（开发者体验，developer experience）。 与SPACE相关的一种更宽泛的表述，围绕反馈回路、认知负荷和心流状态组织。参见主题 3.7。

部署频率（Deployment frequency）。 一个团队成功发布到生产环境的频次。DORA四项指标之一。参见主题 2.10。

DORA指标（DORA metrics）。 来自DevOps研究与评估项目的四项指标：部署频率、变更交付周期、变更失败率，以及故障部署恢复时长。参见主题 2.10。

错误预算（Error budget）。 一项服务水平目标与100%可靠性之间被允许的差额，被当作一种可花费的资源来对待。参见主题 6.1。

逃逸缺陷（Escaped defect）。 一个抵达生产环境、影响真实用户的缺陷，有别于在评审或测试中被捕捉到的缺陷。参见主题 5.1。

FinOps。 通过跨职能协作为可变云基础设施支出带来财务问责的纪律。参见主题 5.4。

流动分布（Flow distribution）。 在一段给定时期内，属于每种流动项类型的已完成流动项所占的比例。参见主题 2.3。

流动效率（Flow efficiency）。 一项工作在穿过一条交付流水线时，主动工作时间与总耗用时间之比。参见主题 2.5。

流动框架（Flow Framework）。 由Mik Kersten创建的一种管理模型，把软件交付当作一条价值流来对待，并用四种流动项类型和五项流动指标来衡量它。参见主题 2.1。

流动项（Flow item）。 流动框架的工作单元：一项功能、缺陷、风险，或债务条目，在纳入时被分类。参见主题 2.2。

流动负载（Flow load）。 一条价值流中当前活跃或等待中的流动项总数，是流动框架对在制品的称呼。参见主题 2.4。

流动时间（Flow time）。 从一个流动项进入价值流到它被交付之间的总耗用时间，涵盖整条价值流，而不仅仅是工程环节。参见主题 2.4。

流动速度（Flow velocity）。 在一段给定时期内完成的流动项数量，是流动框架对吞吐量的衡量方式。参见主题 2.3。

古德哈特定律（Goodhart’s law）。 当一项衡量指标变成一个目标时，它就不再是一项好的衡量指标这一原则。本书的核心指导理念。参见主题 1.2。

护栏指标（Guardrail metric）。 一项配对的反向指标，在一项被激励的指标改善时，它必须不能恶化，被设计用来捕捉操纵。参见主题 1.2。

热点（Hotspot）。 一个既频繁变更（高变动量）又高度复杂的文件或模块，通过热点分析被识别出来。参见主题 4.3。

变更交付周期（Lead time for changes）。 从一次代码变更的首次提交，到它成功部署至生产环境之间的时间。DORA四项指标之一。参见主题 2.10。

利特尔法则（Little’s law）。 证明一个稳定队列中项目的平均数量，等于平均到达率乘以一个项目在系统中花费的平均时间。应用于交付，在制品等于到达率乘以周期时间。参见主题 2.7。

指标树（Metric tree）。 一种把一项顶层结果指标，向下连接到其驱动因素、再到各团队所拥有的运营指标的结构。参见主题 1.3。

MTTA（平均确认时间，mean time to acknowledge）。 从一起事件的通知，到有人承担起响应责任之间的时间。参见主题 6.2。

MTTD（平均检测时间，mean time to detect）。 从一起事件真正开始，到有人注意到它发生之间的时间。参见主题 6.2。

MTTR（平均恢复时间，mean time to recovery / mean time to resolve）。 一次故障之后完全恢复服务所需的时间。既用于由部署引发的故障（主题 2.10），也用于一般事件（主题 6.2）。

变异测试（Mutation testing）。 一种刻意向代码中引入微小、人为错误、以检查一个测试套件是否真的能捕捉到它们的技术，作为对覆盖率的补充。参见主题 4.2。

北极星指标（North-star metric）。 最能捕捉一个组织所交付的核心价值的单一衡量指标，位于一棵指标树的顶端。参见主题 1.3。

结果遥测（Outcome telemetry）。 对真实结果、而不是活动或产出的持续、埋点化测量。参见主题 7.4。

完全准确率（percent complete and accurate，%C/A）。 来自经典精益价值流图的概念，指下游团队无需返工就能处理的单位所占的百分比。参见主题 2.8。

处理时间（process time，PT）。 来自经典精益价值流图的概念，指实际用于处理单一单位的、动手操作的时间，有别于等待所花的时间。参见主题 2.8。

排队论（Queueing theory）。 对等待队列的数学研究，应用于交付流水线，以解释在制品、到达率和利用率如何驱动等待时间。参见主题 2.7。

ROI（投资回报，return on investment）。 一项举措相对于其成本的财务回报，在这里从有文档记录的成本和结果证据出发构建，而不是从假设出发。参见主题 5.5。

累积吞吐良率（Rolled throughput yield）。 一条价值流中每一个阶段的完全准确率数字相乘的结果，揭示返工如何在一条多阶段流水线上累积。参见主题 2.8。

SLI（服务水平指标，service level indicator）。 对一项服务健康状况的直接测量信号，例如延迟或错误率。参见主题 6.1。

SLO（服务水平目标，service level objective）。 一项服务水平指标的目标范围。参见主题 6.1。

SPACE框架（SPACE framework）。 一个衡量开发者生产力的五维度框架：满意度与幸福感、绩效、活动、沟通与协作，以及效率与心流。参见主题 3.1。

SRE（站点可靠性工程，site reliability engineering）。 由Google开创的、把软件工程方法应用于运营和可靠性的学科。参见主题 6.1。

节拍时间（Takt time）。 来自经典精益价值流图的概念，指为了干净利落地匹配客户需求，完成一个工作单位所能接受的最长时间。参见主题 2.8。

技术债务（Technical debt）。 一个代码库中过去权宜之计所积累下来的成本，一个用来描述可管理权衡的比喻，而不是一个可耻的秘密。参见主题 4.5。

TCO（总拥有成本，total cost of ownership）。 一项举措或系统在其整个生命周期中的完整成本，包括持续的维护和基础设施，而不只是前期成本。参见主题 5.5。

单位经济学（Unit economics）。 按每一个有意义的交付价值单位（每位客户、每笔交易）表达的成本，而不是作为一个不透明的总数。参见主题 5.4。

利用率（Utilization）。 一项资源可用产能中忙碌的比例，计算方式为到达率除以服务率。随着利用率接近满负荷，等待时间会急剧、而不是渐进地增长。参见主题 2.7。

价值流（Value stream）。 把一个想法转化为客户所获得价值的端到端活动序列，是流动框架的测量单位。参见主题 2.1。

虚荣指标（Vanity metric）。 一项可靠地上升、看起来令人印象深刻、却不改变任何决策的指标。参见主题 1.1。

在制品（work in process，WIP）。 在任何一个时刻，一个团队或系统中正被积极处理的条目数量。参见主题 2.5。