1.1 定义和检测

范式是系统的根源。基于这些范式和对现实本质的社会共识，产生了系统的目标与信息流、反馈、各种存量和流量，以及系统中其他所有的东西。

—Donella Meadows，《系统之美》[1]

支撑Accelerate的心智模型引出了四个关键指标。我在这里就提及它，就是因为这个心智模型对阅读这一章的内容十分重要，你必须记住这个模型。该模型最简单的形式是一个由各类活动组成的流水线（或“流”），从开发人员将他们的代码变更推送到版本控制系统开始，并在这些变更被纳入团队所负责的、为用户交付可运行服务的系统后结束。图1-1展示了这个心智模型。

图1-1：四个关键指标背后的基础心智模型

为了清晰起见，让我们将这四个关键指标在模型中所度量的内容具象化：

部署频率

　　即随着时间的推移，从流水线末端流出的独立变更的数量。这些变更可能由一些“部署单元”（代码、配置或两者的组合）构成，例如，一个新特性或一个缺陷修复。

变更前置时间

　　即开发人员完成了代码/配置变更后通过流水线将其输出到另一端所需的时间。

综上，这一对指标主要用于度量开发吞吐量。上述指标不应与精益周期时间或精益前置时间相混淆，这种时间定义包含编写代码的时间，甚至有时在产品经理第一次提出新特性的想法时就开始计时了。

变更失败率

　　即从流水线流出的变更中造成正在运行的服务发生故障的变更的比例。（“故障”的具体定义将在稍后讨论。现在，只需把故障看作那些阻碍你所服务的用户完成其工作的东西。）

服务恢复时间

　　即从服务发生故障开始，到发现故障并修复故障，进而为用户恢复服务所需的时间[2]。

综上，第二对指标给出了对服务稳定性的指示。

这四个关键指标的作用在于它们的组合。如果你改进了开发吞吐量的某一个要素，但在这个过程中降低了服务稳定性，那么这就是一种不平衡的改进，这种改进无法获得长期的可持续收益。最根本的点就在于要同时密切关注这四个关键指标。能够实现可预测的长期价值的转型才能带来全面的积极影响。

现在我们明白了这些指标的来源，我们可以通过将通用的心智模型映射到实际的交付过程中来使问题讨论更具体。我将在下一节中展示如何实现这种“心智重构”。