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

本文要点：

• 在数据驱动决策过程中，关于是要投资于服务可靠性还是要开发新功能的决策，可以使用SRE方法来完成。
• 可以使用一组由开发和运维服务的团队定义的服务水平指标（SLI）来衡量服务的可靠性。
• 为了能够基于SLI来衡量服务的可靠性，需要为每个SLI定义服务水平目标（SLO）。
• 为每个SLI定义的SLO确定了错误可用的预算——也就是每个SLI的错误预算——开发和运维服务的团队将跟踪这些预算。
• 在开发组织中引入SRE方法，并定义好SLI和SLO之后，就能极大地促进产品、开发和运维之间的协作。

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

简介

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

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

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

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

流程指标，而非人员KPI

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

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

站点可靠性工程（SRE）

运维中的一个核心问题是“如何可靠地运维产品”？

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

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

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

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

服务的SLI和SLO由服务的产品所有者、开发人员和运维工程师来定义。这样，我们可以让所有相关角色以可衡量的方式，就服务可靠性的重要程度达成一致。

严格的SLO意味着开发团队将花费更多的时间来保持服务处于可靠状态，这会减少他们实现面向客户的功能的开发时间。宽松的SLO意味着开发团队将花费更少的时间来保持服务的可靠性，这样就能花费更多的时间来实现面向客户的功能。

因此，定义好的SLI和SLO可以辅助数据驱动的决策，决定何时进行可靠性投资以及何时进行面向客户的功能投资。

当开发团队采用基于错误预算策略的方法来管理可靠性时，他们就在使用数据驱动决策来决定何时投资于可靠性，以及何时投资于面向客户的功能。此外，像这样的团队一直都能知道他们在生产中的服务是否处于已定义的SLO中，这是服务的用户满意度的一种代理指标。

相反，不遵循SRE（没有SLI、没有SLO、没有错误预算策略）的开发团队，难以了解他们的服务在生产环境中运行的可靠性。这样的团队通常会对用户报告的服务中断做出反应，并根据中断的严重性来决定对可靠性的投资策略。

启用SRE

引入SRE时需要与各个团队开多次工作会议。初始会议奠定了SRE体系的基础，例如SLI、SLO、错误预算、错误预算策略、警报和仪表板等。这样可以确保所有团队成员都跟上节奏。

之后的会议需要明确用户规范（团队正在优化这些用户的体验）、这些用户的典型工作流程、生成的服务端点调用链、服务端点的SLO定义以及启用警报等等。

对于SLI和SLO定义，我们使用微软Azure AppInsights启用了服务检测。我们一开始研究的是两个SLI：可用性和延迟。对于每个SLI，我们定义了一个SLO一般阈值（可用性为98％，延迟为500ms）。我们用这个阈值来确定是将SLO自动设置为阈值本身，还是在开发团队的工作区中手动设置SLO。低于定义的一般阈值的服务端点被认为是运行良好的，并会获得一个自动计算的，等于定义阈值的SLO。高于定义的一般阈值的服务端点需要仔细地手动设置SLO，需要经过PO、Ops和开发人员之间的一系列讨论后才能确定。

通过这一过程，我们会为足够快速且可用的服务端点自动设置SLO。对于其他服务端点而言，我们会与团队和利益相关者合作来手动设置SLO。这样，我们就能将开发团队的时间用在最棘手的领域。

我们的运维团队为所有服务端点提供了以下仪表板：

这些仪表板是根据微软Azure AppInsights中提供的SLO定义和服务日志自动生成的。

在左上角，我们可以看到服务的延迟SLI。延迟的目标SLO显示为水平线。每当服务打破延迟SLO时，就会消耗延迟错误预算。延迟错误预算随时间的消耗情况显示在右上角的图形上。当右上角的图形达到零时，延迟错误预算也就用完了。

在左下角，我们可以看到服务的可用性SLI。可用性的目标SLO显示为水平线。每次服务打破可用性SLO时，都会消耗可用性错误预算。可用性错误预算随时间的消耗情况显示在右下角的图形中。当右下角的图形归零时，可用性错误预算也消耗完毕。

至于警报，我们针对错误预算消耗率设置了警报。这样一方面可以确保我们及时发出警报，另一方面也不会给团队带来太多警报。

• 短期警报：在最近的一个小时中每10分钟扫描一次SLO违规情况。如果SLO在过去一个小时内被打破两次，则立即发出警报。引发警报后，这种警报会暂停一个小时。
• 长期警报：每24小时一次，查看最近24小时的SLI/SLO数据。如果最近24小时的错误预算比例被用完，则会引发一次警报。
• 错误预算已用尽警报：每当错误预算用尽时，就会引起一次警报。

一旦错误预算在四周的周期内被SLO不达标情况消耗殆尽，我们便要求团队遵循其自定义的错误预算政策。例如，团队的错误预算政策可以声明，将事件审核中的积压项目优先级提升到其他所有工作之上，直到完成为止。

在诸如PagerDuty或OpsGenie之类的工具支持下，我们的未来工作将引入有效的事件审核和On Call Rotas，并会使用SRE推动我们的文化进步。本着DevOps的理念，它确实有助于将产品、开发和运维整合在一起。

采用

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

所有团队都对SRE活动表示欢迎，因为他们希望通过SRE获得更多的生产洞察力，并在他们向客户展示自己的成果之前找出失败的部分。

这些团队针对所有环境的所有服务都启用了微软Azure AppInsights中的日志记录。这使团队能够自动获取有关服务延迟和可用性的数据。

下一步，团队面临着定义非常具体和详细的用户配置文件的挑战，这是为了针对那些特定的用户群体来设置SLO。如果服务处于已定义的SLO中，则这些细分用户群会感到满意。如果服务处于定义的SLO之外，则这些细分用户群会感到不快。

一开始，一些团队提出的是比较宽泛的用户配置文件，例如“放射科医生”或“物理学家”。我们要求团队区分得更加具体，以便更好地理解用户的意图。基于用户意图，我们就可以推断出典型的用户工作流程。最后，根据用户工作流程，我们可以得出服务端点的典型调用链。

同时，一些团队基于技术方面的考虑，快速指出了一些对几乎所有用户工作流都非常重要的服务端点。对于这些服务端点，我们定义了更严格的延迟和可用性SLO。

这些团队很快就理解了SLI/SLO仪表板和警报逻辑。

一些团队开始安排人员轮班响应警报。这也是为将来在SRE活动中引入随时待命服务做好准备。

我们从团队那里得到的一个非常普遍的要求，是在可用性和延迟之外再添加其他SLI。这里，我们需要找到适用于所有团队的SLI，以便用通行的方式扩展我们的SRE基础架构。这也会让运维团队在基础架构的创建和维护中付出的努力得到最大的回报。团队一般会需求下面这些SLI：

• 死信（Dead Letter）队列长度
• 证书过期

除此之外我们还了解到，一方面按团队要求提供自定的SLI会大有裨益，另一方面这也将占用我们运维团队的能力，影响他们提供必要的SRE基础架构扩展的工作。不过，我们可以让团队在向自定义SLI迈出第一步的时候，先不提供SLI/SLO/错误预算语义。我们一开始可以基于日志查询为团队提供生产环境中客户SLI状态的信息。只需每天两次将信息推送到专用的Slack频道即可。这总比运维时两眼一抹黑要强得多。之后，我们可以扩展SRE基础架构来逐个支持自定义的SLI。

最后一点，我们的运维团队现在负责所有与SRE基础架构相关的调整工作。一开始这没什么问题。但等到开发团队熟悉了基础架构之后，我们会让他们自己来做更改，而不必等待运维团队介入。

优先级

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

• 生产中最快/最慢的错误预算消费者（按服务端点）
• 就延迟SLI而言最快/最慢的服务端点
• 就可用性SLI而言，最多/最少可用的服务端点
• 每个定义的SLI都要考虑这些数据

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

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

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

未来的主题

我们可以基于SRE的SLI/SLO想到几个未来的主题。

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

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

小结

总而言之，如果团队使用SRE优化自己的运维流程，那么团队便能够以数据驱动的方式逐步优化其工作方式，这样随着时间的推移，他们就能以可靠得多的方式运维各项功能。

数据驱动的SRE有助于使软件交付组织的决策过程中的政治化和透明化。最后，它支持组织提高业务业绩，例如用户对软件的参与度和收入。

本文是“软件产品交付组织的数据驱动决策”系列文章的一部分。本系列概述了数据驱动的决策如何支持软件交付中的三大活动——产品管理，开发和运维。以后的文章将探讨开发和运维中的数据驱动决策，以及产品管理、开发和运维中的数据驱动决策组合。

致谢

有许多人为本文背后的思想做出了贡献。Philipp Guendisch概念化并实施了SRE基础架构、SLI/SLO仪表板和警报。感谢“teamplay”中的整个团队引入和采用本文中的方法。

作者介绍：

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

原文链接：

Data-Driven Decision Making – Product Operations with Site Reliability Engineering