Twitter如何采用SLO

这是由两部分组成的系列文章中的第二篇。点击这里观看对Brian、Carrie、JP和Zac的采访的第一部分，了解更多关于Twitter SRE之旅的信息。

之前，我们看到Twitter的SRE如何转变他们的工程实践，以推动规模化的生产准备。服务级别目标(SLO)和错误预算的概念一直是这种转变的关键，因为SLO塑造了组织围绕可靠性做出面向数据的决策的能力。(请阅读此处，了解SLO的定义以及它们如何改变Evernote。)。今天，Twitter团队已经投资于集中式工具来测量、跟踪和可视化SLO及其相应的错误预算。

然而，成功实施SLO说起来容易做起来难。由于多种原因，许多组织在采用方面一直举步维艰。常见的障碍包括让利益相关者买入，不知道要衡量什么(以及如何衡量)，以及对如何使SLO具有可操作性感到困惑。

虽然Twitter的工程团队已经围绕可观察性和可靠性奠定了非常坚实的基础，但在SLO开始在组织中获得更广泛的采用之前，它经历了几个重要的突破，而且旅程还在继续。

在SLO之前，工程师们已经使用服务水平指标(SLI)多年了。SLI借鉴了Twitter在其可观察性堆栈中对基础设施和投资的广泛工具。他们的可观察性堆栈为通过其分布式服务生态系统中的成功率、延迟和吞吐量等指标衡量服务健康状况提供了基础。例如，团队将监控面向用户的HTTP服务的成功率，他们通过查看HTTP 500错误与总请求数来计算成功率。

多年来，将SLI与警报和随叫随到的轮换相集成一直是其工程团队的核心实践。此外，他们对事件管理和邮寄的关注使他们能够不断从其不断发展的生产生态系统中学习。

一个重要的转折点是将SLO的概念嵌入到finagle中，finagle是Twitter的RPC库，由核心系统库(CSL)团队维护。正如在上一篇文章中提到的，finagle提供诸如负载平衡、断路器、故障检测器等可靠性功能，并将其填充到运行的每一款软件中。2018年，CSL团队在Twitter内部版本的finagle中将SLO作为一流实体，创建了一个与服务边界捆绑在一起的基础性API构建块，他们称之为目标。这是变革性的，因为它允许团队开始定义服务到服务的交互和建模，而不仅仅是警报，从而创建团队现在可以用来通知运行时决策的编程定义。

Twitter团队通过可以使用SLO特性的项目和用例的建议来支持该实现，并且最初交付了SLO的配置和实时的每实例测量。

在最初阶段，该功能的采用受到限制。服务所有者可以配置SLO，但由于缺乏与启用SLO自动关联的工具和好处，因此在其他优先事项的背景下几乎没有动力这样做。

看到这一点，团队投入了后续工作。他们开始在SLO之上为服务所有者构建集成和解决方案，例如基于SLO的负载减轻，因为它们提供了比CPU节流等相关指标更有用的环境。通过试点这样的改进，采用的胃口开始增加。

在考虑如何定义SLO时，Twitter团队通常首先考虑哪些功能是关键的，并确保它们得到了很好的工具和理解。

确定最能反映关键用户体验的信号非常重要。服务成功率的一些信号可以提供颜色，但解释起来并不那么简单。例如，在分析数据中心内的服务错误率时，客户端可能会重试这些请求，从而使其成为一个错误的数据点，无法推断真实的用户成功率是多少。

一旦团队在顶层设置了合理的SLO，就会向下驱动边界所依赖的服务。每个服务都有大量的服务依赖项，因此所有上下游服务的延迟和成功SLO都必须在定义的边界上下文中协同工作。SLO支持更全面地测量整个调用路径。

错误预算的引入标志着Twitter采用SLO的另一个关键转折点。错误预算使SLO变得可操作，并提供了一个不同的视角来理解随时间推移的服务，因此它们是最初交付SLO之后的一个重要后续功能。

错误预算着眼于随时间推移的SLO，因此允许团队通过提供服务如何在不同的时间范围内实现目标的历史视图来开始跟踪性能。传统的指标观点往往目光短浅，可能会掩盖有价值的趋势和机会周围的信号。错误预算不再是绘制数百个指标的仪表板，而是一个强制功能，用于选择几个最重要的指标，并更深入地了解它们如何以及为什么随着时间的推移而变化。

一个重要的注意事项是，在错误预算耗尽时，团队不会规定一组固定的操作。虽然错误预算可能是一个强大的工具，但真正的价值必须引起工程和产品团队的共鸣。

在“情境，而不是控制”(由Netflix创造)的概念下，它非常强调用可视化和洞察力来授权善意的、有能力的团队成员，使他们能够做出更好的决定。以同样的方式，Twitter SRE应用正在进行的实验来了解其他团队成员认为什么是有价值的度量。他们明白，错误预算更多的是为团队成员提供良好的工具和环境；没有一种策略是万能的。

例如，一个团队假设错误预算将帮助通知自动部署何时可以继续，具体地说，如果错误预算耗尽，是否暂停部署。但他们发现，有时暂停或阻止的部署可能包含针对增加的错误的修复。因此，“如果没有错误预算就进行块部署”的简单规则很快就开始瓦解。被阻止的部署本身可能会降低出错量或错误率，甚至可能保护SLO，并使其在剩余的持续时间内得到满足。

请记住，它们不一定是规定性的，错误预算为服务所有者考虑如何确定工作优先级提供了非常有用的建议。它们创造了一条重要的“跑道”，用来提高或降低创新的速度。例如，过快的错误预算耗尽可能是对当前待命或即将到来的冲刺的缓解工作进行优先排序的信号。或者，没有使用足够的错误预算可能会促使团队更快地迭代特性工作，或者进行更多的实验。

虽然该团队还处于采用SLO的早期阶段，但他们已经在几个方面看到了SLO的巨大潜力和价值。

Twitter拥有数百项(如果不是数千项)服务，这使得它的基础设施成为一头难以理解的复杂野兽。Twitter指挥中心(TCC)的现任成员已经在那里呆了足够长的时间，他们一般都知道大多数服务是什么，以及服务是如何“拼凑在一起的”。然而，他们知道，最终他们会达到一个点，那就是这变得不可能，没有人能理解这一切是如何工作的。通过现在投资SLO来帮助指导讨论，目标是当它们达到未知的复杂性时，它们将已经设置好以编程方式管理服务度量。

上下文是关键。仪表板可以很容易地拥有数百个图表，这些图表可以转换为数千个指标。团队可能会在多个数据中心收到数十或数百条有关其服务的警报。这些仪表板、指标和警报对运行这些服务的人很有帮助，但对于其他任何人来说，它们都是非常高的上下文和信息过载。

SLO创建了与共享环境进行更直接对话的能力。团队可以将重点放在四五件重要的事情上，而不是查看仪表板上的一百张图片。如果这些服务中的任何一个不是绿色的，其他人都可以理解某些事情是不正确的，而不需要了解关于这项服务的任何其他信息。

通过使SLO成为一流实体，服务可以在编程级别表达它，而不仅仅是测量它。这使团队能够使用SLO作为构建块进行系统改进。例如，该团队正在探索finagle中的背压是否可以取而代之以SLO为基础。

使用finagle，服务可以通过编程方式检测它们何时加载(通常使用第二类信号，如CPU)，然后发出信号将流量重定向到另一个实例。与依赖二级信号实现反压力不同，服务可以直接知道它是否趋向于SLO违规，以便发出反压力信号并减轻自身的负载。

Twitter团队的SLO目标之一是在大型活动期间优雅地降低服务质量，以确保核心功能始终可用。与全有或全无的故障模式不同，该团队的目标是在保留核心功能的同时，通过剥离外围功能来优雅地降低服务质量。

Twitter团队对利用SLO实现选择性断路器模式以提高整体系统可靠性感兴趣。服务所有者可以决定哪些上游服务是核心功能所必需的，哪些只是附加功能或花哨功能所必需的。对一个服务不是很重要的上游服务可能对其他服务很重要。消费服务可以实现断路器，以检测并停止向经历高错误率的服务发送流量。

在Twitter，责任的导向是队友对他们未来计划做的事情负责。由于有效运营的最重要方面之一是无懈可击的文化，因此SLO从不与单个绩效指标捆绑在一起。相反，我们的目标是定义或实现更多SLO，以获得更大的可见性和理解，而不是指责团队没有达到这些目标。