本文要点

数据驱动决策可以支持软件交付中的三大活动：产品管理、开发和运维，以提高软件交付组织的有效性、效率和服务可靠性。
在产品管理中，假设可以用来确保产品决策的有效性；在开发领域，持续交付指标可用于确保开发流程的效率；在运维领域中，SRE的SLI和SLO可确保生产中服务的可靠性。
同时使用假设、连续交付指标和SRE的SLI/SLO，可以使软件交付组织同时优化有效性、效率和服务可靠性！
引入假设、持续交付指标和SRE的SLI/SLO，对组织来说意味着重大的转变，这一变化应逐步推广开来，还应获得实操培训活动的支持。
通过使用假设的可测量信号、持续交付指标的值和SRE的SLO违规计数，可以对有效性、效率和可靠性做出数据驱动的优先级权衡。

数据驱动型决策系列概述了数据驱动型决策如何支持软件交付中的三个主要活动——产品管理，开发和运维。

数据驱动决策系列

数据驱动决策系列文章概述了数据驱动决策如何支持软件交付中的三大活动——产品管理、开发和运维。

全系列包括四篇文章，每篇文章讨论了一个可以应用数据驱动决策的领域：

在产品管理中，假设可以用来确保产品决策的有效性。
在开发中，持续交付指标可用来确保开发流程的效率
在运维中，SRE的SLI和SLO可用来确保生产中服务的可靠性。
在这个文章系列中，我们还将展示如何同时使用假设、CD指示器和SRE的SLI/SLO，使软件交付组织能够同时优化有效性、效率和服务可靠性。

该系列中的所有文章都列在Vladyslav Ukis的InfoQ个人资料中。

简介

软件产品交付组织需要愈加频繁地交付复杂的软件系统。软件交付工作涉及的主要活动包括产品管理、开发和运维（这里我们的确指的是活动，而不是在谈各个部门，后者是我们不推荐的说法）。在每项活动中，都必须快速做出许多决定以推进交付。在产品管理中，决策主要涉及功能优先级。在开发中，它关联的是开发流程的效率。在运维中，它主要针对的是可靠性。

可以根据团队成员的经验来做出决策。另外可以基于数据做出决策。这将带来更加客观和透明的决策流程。尤其是随着交付速度的提升和交付团队数量的增加，保持透明的组织就能让所有人无需耗时的同步会议，也可以一直走在同样的轨道上。

在本文中，我们探讨了如何使用 SRE 中的数据支持运维中的活动，以及如何使用这些数据实现快速的数据驱动决策。反过来，这会提高产品开发组织的透明度并削弱其官僚风气，最终就能取得更好的业务成果，例如用户对软件更高的参与度和更高的应计收益等。

我们报告了持续交付指标在西门子医疗公司开发活动中的应用案例，这是一个由分布于三个国家的 16 个软件交付团队组成的大型分布式软件交付组织。

决策数据

为了以数据驱动的方式指导产品交付组织，我们需要一种使用数据来表达产品管理、开发和运维这些主要的产品交付活动的方法。

为了以数据驱动的方式引导开发活动，我们需要一种使用数据来表达开发工作中主要活动的方式。这种数据需要被视为当下发生的事情的流程指标，而不是用于员工评估的人员关键绩效指标（KPI）。这是很重要的，因为如果这种指标被用于员工评估，那么员工可能倾向于以对自己有利的方式来调整要评估的数据。

重点在于，产品交付组织的领导者要将这种数据视为流程指标，而不是评估员工KPI 的方法，以实现稳定的数据质量和数据评估流程。

产品管理指标

在产品管理中，核心问题之一是“要构建什么？”。软件功能构建完成却不使用的话就完全是浪费，因此这一点很重要。

为了解决“要构建什么”这个问题，产品交付团队会做一些小实验以探索客户的需求，在生产中进行实验是最理想的。每个实验都需要相关的测量数据，用于证实或推翻最初的假设。这个流程是假设驱动开发（Hypothesis Driven Development，简称 HDD）的主题。《如何实现假设驱动的开发》这篇文章对这个问题进行了很好的阐述。本质上，在 HDD 中，一个实验被称为假设，并用功能/结果/可测量信号来描述：

假设：

我们认为这个<功能>；

会导致这个客户<结果>；

在生产中，看到这样的<可测量信号>时，就可以知道我们成功了。

在功能实施开始之前，功能的假设定义就已经完成了。产品交付团队声明他们希望把哪个<功能>放入产品以实现特定的客户<结果 >。定义的<可测量信号>在生产中变得可见时，就能知道这个客户<结果>已经实现了。也就是说，产品交付团队把重点放在其提供给客户的价值上，而不是仅仅计算交付给生产的功能有多少。

有关假设的更多信息，请参见：数据驱动型决策如何支持软件交付（一）：用假设进行产品管理

开发指标

现在，我们已经将产品管理流程的重点放在了用户的价值（有效性）上，我们希望在构建功能时能够确保其有效性。因此，开发活动中的一个核心问题就变成了“如何有效地制造产品？”

通过分析软件开发团队的价值流，可以衡量开发流程的效率。价值流具体来说就是代码→构建→部署，可以在团队的部署管道上看到。

价值流中价值流动的速度是可测量的。同样，也可以测量价值流的稳定性。所谓的稳定性和速度这两大持续交付指标做的就是这些事情。这些指标是在Steve Smith的《测量持续交付》中定义的。

稳定性持续交付指标分为构建稳定性和部署稳定性。速度的持续交付指标分为代码吞吐量、构建吞吐量和部署吞吐量。

构建稳定性指标包括构建失败率和构建失败恢复时间。

部署稳定性指标包括部署失败率和部署失败恢复时间。

代码吞吐量指标包括主分支提交前置时间和主分支代码提交频率。

构建吞吐量指标包括构建前置时间和构建频率。

部署吞吐量指标包括部署前置时间和部署频率。

有关CD指标的更多信息，请参见：数据驱动型决策如何支持软件交付（二）：持续交付指标助力产品开发

运维指标

现在我们已经使用假设让产品管理流程专注在了用户的价值（有效性）上，并且使用持续交付指标让开发流程专注在了效率上，我们还希望在运维产品时能够确保可靠性。也就是说，运维中一个核心问题是“如何可靠地运维产品？”

产品在生产中的可靠性由许多指标反映，包括可用性、延迟、吞吐量和正确性等。在站点可靠性工程（SRE）中，这些指标称为服务水平指标（SLI）。部署到生产中的每个服务都有一组 SLI，这些 SLI 共同反映了服务的可靠性。

在 SRE 中，每个服务的每个 SLI 都会分配一个目标。该目标称为服务水平目标（SLO）。例如，可以为服务的可用性 SLI 分配一个 99.5％的 SLO。这意味着开发和运维服务的团队运维服务时，会努力实现在 99.5％的情况下都可用的目标。

反过来说，对于 99.5％的可用性 SLO 而言，所谓的错误预算为 100％-99.5％=0.5％。这意味着我们可以预计，在 0.5％的情况下该服务将不可用，并会公布这个期望值。错误预算是在服务中产生错误的预算。在需要停机（预期停机）、遇到错误（意外停机）或因依赖项失败而无法继续服务（意外停机）时，都会消耗错误预算。

运维服务的开发团队会跟踪在给定时间范围（例如四周）内剩余的错误预算。一旦错误预算消耗完毕，团队就会制定一个自定义的错误预算策略。错误预算策略的内容，可以是要求服务上的功能停止工作，并且仅执行可靠性工作，直到服务返回其 SLO 之内为止。

有关SRE的更多信息，请参见：数据驱动型决策如何支持软件交付（三）：站点可靠性工程助力产品运维

指标框架

上述这些指标在单独使用时，可分别对产品管理、开发和运维流程进行单独的优化工作。

但是，产品交付组织如果能将这些指标合并到一个用于数据驱动决策的总体指标框架（Indicators Framework）中，就可以更好地全局优化组织的整体价值流。如下图所示。

功能假设（Feature Hypotheses）的定义，让组织可以根据来自生产中的可测量信号测量产品管理流程。持续交付指标使组织可以测量开发团队中开发/测试/部署活动的稳定性和速度。生产中运行的每个服务的SLI和SLO的定义，则让组织可以测量运维流程。

功能假设、持续交付指标和SLI/SLO是相互依赖的。

假设用于确保产品决策的有效性。持续交付指标用于确保开发流程的效率。SRE的SLI和SLO则用于确保生产中服务运维的可靠性。

也就是说，如果同时使用假设驱动的开发、持续交付指标和SRE，我们就能同时影响产品组织的有效性、效率和可靠性！

所以我们建议的这三种方法如果同时应用，就能成为一种非常强大的组合。

它让我们能够以数据驱动的方式同时做出以下系统性决策：

产品管理——构建什么？
开发——如何有效地构建它？
运维——如何可靠地运维它？

引入组织

确定了指标框架后，我们很清楚，只有给团队提供足够的支持，把它引入拥有 16 支开发团队的组织才会产生效果。

我们首先引入了假设。六个月后，我们引入了SRE。又过了六个月，我们向组织引入了持续交付指标。我们使用了分阶段的方法来引入这些变化，这样组织每次只需关注一种变化即可。

就引入这些转变的准备工作而言，假设是最简单的。它扩展了我们的业务功能模板，并为每个团队带来了一个研讨会。

在准备引入站点可靠性工程（SRE）的过程中，我们为两个基础SLI（可用性和延迟）实现了基础架构。这一基础架构能够为每个团队的每个服务生成SLI和错误预算仪表板。最重要的是，它能够在所有部署环境中针对错误预算消耗发出警报。除了这一基础架构，我们还同各个开发团队一起举办了许多研讨会，以：

使团队成员熟悉SLI、SLO、错误预算和错误预算策略这些SRE概念
为可用性和延迟SLI定义初始SLO
微调警报
针对团队所有的服务提出其他一些相关的SLI
设置待命名单，以及时有效地响应警报

为了准备引入持续交付指标，我们实现了一个工具，可以用它来处理持续集成和部署环境中来自部署管道的数据。经过数据处理后，该工具可以直观地展示团队的部署管道，以及管道环境中的稳定性和速度瓶颈。这样，团队就可以立刻注意到这些瓶颈，并讨论如何解决它们。

被组织采用

我们将推荐的指标框架引入了一个由 16 个开发团队组成的组织中，这些团队负责的是“teamplay"——这是西门子医疗团队提供的一项医疗领域的全球化数字服务（有关“teamplay”的更多信息，请参见《西门子医疗团队在teamplay中采用持续交付方法》）。

在下面提到“团队”时，我们指的是开发团队。他们定义了假设、软件开发方式和SLO。他们还使用了来自假设的可测量信号、持续交付指标和SLO违规计数的结果数据。此外，我们还有一小支中央运维团队，为开发团队提供SRE基础架构。SLO违规计数也是运维团队的一阶数据。

指标框架引入后，这些团队对假设和SRE表现出了非常浓厚的兴趣。持续交付指标的主题需要更多的解释，因为它引入了一种通过价值流分析的视角来审视软件开发的新方法，而这在软件领域并不那么常见。

假设定义流程可以帮助团队在规范制定流程中尽早敲定功能的范围。它为将来的用户故事映射和BDD场景定义奠定了良好的基础。可测量信号的定义要求开发人员学习有关如何使用生产监控并从中获取见解。为了推动数据驱动决策，团队开始应用可测量信号，并根据其值，针对未来的功能实现步骤做出相应的决策。

引入SRE需要花费大量时间，因为它需要“将运维世界带入开发领域"。每个团队都参加了许多研讨会，直到他们开始重视SLO违规所导致的错误预算消耗警报为止。这里的下一步是引入待命职责。为了推动数据驱动决策，团队需要评估哪些服务消耗错误预算的次数最多/速度最快，并且优先考虑改善可靠性，而不是开发新功能。

SRE数据也开始用在了数据驱动的预算分配决策中。我们的某些服务没有足够的开发人员来照料，所以无法提供较好的服务质量。团队很难劝说高层为自己增加员工人数，因为其他部门也有自己的切实理由，表明对他们增加投入是有利的。一旦获得了服务的SRE数据，团队就能证明服务的可用性和延迟表现是不够好的。团队可以使用数据来证明当前的服务质量对客户的负面影响，从而争取更多的人员配备。

持续交付指标一开始是由少数几支团队开始采用的。这里的第一个见解是，不同团队的工作方式大不相同，并且直到他们看到工具显示出来的数据，才意识到管道的稳定性和速度瓶颈。一个团队查看了他们的所有瓶颈，并发现了部署失败率中最大的那个。但是，部署失败恢复时间很短。为了推动数据驱动决策，团队将部署失败率瓶颈的分析工作放在了优先位置，并且在一天之内就可以显著减小瓶颈。简单的部署检查可以确保各个环境都部署了必要的资源，以使应用程序能够正常运行，从而降低了部署失败率。时间一长，团队就不再经常需要从部署失败中快速恢复了。

优先级

我们的团队需要更多和 SRE 的 SLI/SLO 相关的经验，这样才能一直都使用手头的数据作为优先级决策的输入。这些数据有不同的形式：

来自假设
- 积极/消极测试的假设
- 来自可测量信号的意外见解
来自持续交付指标
- 大多数/中间/最不稳定的管道，表现为
  - 失败率
  - 恢复时间
- 最快/中间/最慢的管道，表现为
  - 管道环境之间的前置时间
  - 环境中各个活动之间的间隔时间
来自SRE
- 生产中最快/最慢的错误预算消费者（按服务端点）
- 就延迟 SLI 而言最快/最慢的服务端点
- 就可用性 SLI 而言，最多/最少可用的服务端点
- 每个定义的 SLI 都要考虑这些数据

既然有了数据，开发团队（尤其是产品所有者）就必须考虑这些数据，以制定最佳的优先级决策。优先级决策的权衡包括：

投资于功能以提高产品效率和/或
投资于开发效率和/或
投资于服务可靠性

就是说，错误预算策略需要成为一个具有约束力的文档，该文档的优先级应高于其他事项。

为了实现数据驱动的优先级制定流程，最好创建一些仪表板，以简化优先级决策流程的方式显示团队的假设、CD指标和SRE中的所有数据点。

未来的主题

我们可以基于假设、持续交付指标和SRE的SLI/SLO来考虑几个未来的主题。

如上所述，为促进数据驱动的优先级决策流程，我们需要探索如何在组合仪表板中可视化来自团队的假设、CD指标和SRE的所有数据点。这将是我们下一步工作的主题。

另外，或许我们可以使用机器学习技术，基于部署管道上先前环境中的稳定性和速度数据来预测管道环境中的稳定性和速度表现。

我们也可以考虑结合持续交付指标和SRE的不同输入来创建团队整体分数。这样做的好处还有待观察。

此外，我们可以研究SLO违规与功能假设实现之间的相关性。我们目前的推测是，如果用户工作流是用经常打破SLO的服务来执行的，那么用这种工作流评估的假设不会得到正面的检验结果。

总结

总而言之，如果团队优化了他们的：

产品管理流程（使用假设来优化），
开发流程（使用持续交付指标来优化）和
运维流程（使用SRE来优化）

那么团队就可以用数据驱动的方式逐步优化他们的工作方式。这样随着时间的推移，团队就可以达到以下状态：

构建的功能被用户广泛使用
有效地构建功能部件，避免其价值流（也就是部署管道）中的重大瓶颈
以明显可靠的方式运维功能

最后，本文提出的总体指标框架，旨在为软件交付整体流程的持续改进提供一种全面的数据驱动方法。它能削弱软件交付组织决策流程的官僚风气，并让决策流程更加透明。最后，它能提升组织的业务表现，例如用户对软件的参与度和软件的营收。

致谢

有许多人为本文背后的思想做出了贡献。以下人员直接参与实施了文中所介绍的基础架构和工具。

Kiran Kumar Gollapelly，Krishna Chaithanya Pomar和Bhadri Narayanan ARR帮助创建了持续交付指标工具。
Philipp Guendisch提出了概念，并实现了SRE基础架构、SLI/SLO仪表板和警报。

感谢“teamplay”中的整个团队引入和采用本文中的方法。

作者介绍：

Vladyslav Ukis先后毕业于德国 Erlangen-Nuremberg 大学以及英国曼彻斯特大学的计算机科学专业。他一毕业就加入西门子医疗，并一直致力于软件架构、企业架构、创新管理、私有和公共云计算、团队管理和工程管理。最近几年，他一直在西门子医疗数字生态系统平台和应用（Siemens Healthineers Digital Ecosystem Platform and Applications）“teamplay”上推动持续交付和 DevOps 转型。

原文链接：

Data-Driven Decision Making – Optimizing the Product Delivery Organization

相关阅读：

数据驱动型决策如何支持软件交付（一）：用假设进行产品管理

数据驱动型决策如何支持软件交付（二）：持续交付指标助力产品开发

数据驱动型决策如何支持软件交付（三）：站点可靠性工程助力产品运维

创作场景

数据驱动决策如何支持软件交付（四）：优化产品交付组织