如何将SLO出售给工程总监

我们最近在Brex开始了服务水平目标（SLO）之旅，并认为与该社区分享我们的经验非常有价值。该博客是经过编辑的内部备忘录，旨在使SLO熟悉其受众，解释SLO文化的价值，并描述我们将如何实施和推广它们。

为了成功扩大我们的客户群，三个方面对于维持和进一步提高信任至关重要。

只有当我们有一种准确的方法来衡量我们的服务时，才能实现所有方面。最好通过定义和捕获服务级别目标（SLO）来实现。

借助SLO，我们将能够通过降低可靠性来估计服务可靠性对业务的影响，并决定可以更快地迭代哪些服务，从而准确地理解和控制所承担的风险。

将High Reliability与High Velocity项目区分开来，并在每个允许的风险容限范围内尽可能快地进行迭代。

尽管早期的Brex被构建为模块化整体结构，但我们已经开始进行一些努力来使我们的服务脱钩，提高核心系统的可靠性并提高总体开发速度。但是，能够实现这些目标的关键因素是能够从用户的角度跟踪我们的系统的运行状况，以便根据项目类型做出数据支持的决策。

简而言之，SLO是量化指标的商定目标，它可以从用户的角度确定我们的服务表现如何。

关键用户旅程，SLI，SLO，SLA和错误预算是Google SRE引入并在整个技术行业广泛使用的软件风险管理的关键概念。以下是简短定义：

服务水平指示器（SLI）是一种度量，用于从用户角度确定系统是否正常或可用（即“成功请求的百分比”或“操作延迟”）

服务水平目标（SLO）为基于SLI的系统定义了运行状况或可用性目标（即“ 99.5％的请求成功”或“ 99％的请求或少于200ms”）

服务级别协议（SLA）通常与付费客户就一组SLO订立具有法律约束力的合同（即“如果对您的服务的请求成功率不到99.5％，则将退款）”

从SLO得出的错误预算是服务可能违反其目标SLO的每个时间段（通常为7、28、30或90天）的时间。

服务记分卡：一种量化服务运营质量的方法。它通常使用检查或措施，例如：

用相应的高/低SLO准确描述了高可靠性/高速度项目。

作为Brex的一名员工，我可以立即了解我们的产品是否按预期运行，如果没有按预期运行，则哪些区域出现问题。

作为Brex客户，我可以访问状态仪表板，该仪表板清楚地描述了Brex产品的当前状态。

在我们的主要关键用户之旅中捕获SLO，将使可靠性和可用性与一美元的业务价值联系在一起。随着我们业务的增长，随着时间的推移，可用性的不断提高将对业务产生更大的影响。

让我们看一个简单的示例，在线电子商务业务，以及一旦客户将商品放入购物车并准备为订单付款时发生的付款流程的可靠性。 SLO定义为成功处理了发起的付款的99％。如果我们不处理付款，则客户将收到错误消息，就本示例而言，我们假设他们会放弃订单。

出于练习的目的，我们假设它们在这30天内平均分配。

我们希望其中的1％无法正确处理，因此每个月的收入为10,000美元。

专门花费工程资源“加9”可能不值得。

现在，如果我们将GMV每月增加到1000万美元，那么我们每个月就会损失10万美元的收入。

在此示例中未捕获的部分是客户信任，我们每次不正确地拒绝交易都会削弱客户信任。这很难量化，但随着我们扩大客户群，肯定会产生放大的影响。

实施SLO的目的是就我们在哪些系统上投入工程资源以及如何做出明智的决策。

因为我们可以将特定的SLO与业务价值联系在一起，所以这将使正在计划项目的产品经理和工程经理知道要分配多少资源用于技术债务/提高可靠性，以及多少用于特性开发。

这也将是明确区分数据和区分高可靠性和高速度服务的关键：

在设计阶段，SLO和SLA是能够理解不同外部服务（AWS RDS，AWS DynamoDB，Amazon MSK）以及内部服务（事件基础架构，其他依赖项）的可用性含义的关键。 SLO明确定义了工程师在依赖其他系统时可以做出的假设。基于可用性水平，一项新服务应使用SLO / A丰富环境实现，从而有助于做出决定。

“如果不了解哪种行为对服务真正重要，以及如何衡量和评估这些行为，就不可能正确地管理服务，更不用说好了。”-Google SRE

传统上，警报和客户报告用于了解服务是否正常运行。尽管这有助于发现故障，但并不能说明随着时间的推移，我们是否能为客户提供良好的服务。警报可以帮助我们减轻风险，而不是衡量风险。

正确定义的SLO将通过提高开发人员发布新更改以及与其他服务进行交互的信心来提高开发人员的速度，原因如下：

明确定义的SLO将确保系统具有定义明确的功能并跟踪其性能。

SLO有助于确保基础系统的性能随着系统的发展而保持一致。

SLO与测试相似，但在生产中会在运行时：它衡量我们的关键用户之旅是否按预期运行。

通过设置两个级别的SLO（一个外部级别，一个内部级别，更严格的内部级别），我们可以防止问题变得对用户可见。

通过根据关键用户之旅实时捕获我们系统的运行状况，它将使我们能够向内部团队提供详细的状态页，以帮助快速了解所报告的用户问题。

在第一阶段中，专注于一个知名的高可靠性团队和一个知名的高速团队来定义和实施一组初始SLO。这是建立融洽关系并开发工具和文档以帮助后续团队的好机会。

切记在设计文档模板中添加SLI / O部分以创建自增强过程！

在第二阶段中，确定要定义SLO的服务/功能的子集，并与管理层合作确定这项工作的优先级。第1阶段的输出应有助于其他团队为这项工作提供自助服务。这将继续增加组织的知识和实践，并慢慢建立文化。

SLO是一种文化转变。这是关于从用户的角度了解我们的系统，确保我们构建的产品能够提供用户应得的服务质量。它与衡量和跟踪重要事项有关。

所有团队都了解他们的服务功能，SLO就是将其正式化。它很容易上手，一开始很难正确解决，并且需要反复进行，直到我们了解跟踪的内容和方式以及SLI如何与用户感知的服务质量相关为止。

而已！此备忘录的一个版本用于成功获得支持并安排在整个工程组织中创建SLO的时间。在以下文章中，我们将讨论SLO旅程的进展，障碍和经验。

确保您能够为早期采用者提供紧密支持，并在最初的几个试点团队中逐步推广。以客户为中心。

尽早推出SLO将使可靠性和风险管理文化逐渐扎根，并为成功管理客户群的大规模增长奠定基础。 SLO是增强您的工程组织在可靠性和风险管理方面的成熟度的强大工具：请使用它们！ 您对SLO充满热情吗？ 还是对在快速的环境中构建可靠的产品感兴趣？ 快来加入我们在Brex！