SLICK: Facebook 基于 SLO 的可靠性保障实践

定义服务的 SLI 和 SLO，通过全局系统呈现、处理所有服务的 SLI/SLO，从而帮助 SRE 实践在系统中的落地。本文介绍了 Facebook（Meta）在这方面的实践。原文：SLICK: Adopting SLOs for improved reliability^[1]

我们需要与使用我们应用程序和产品的人们和社区不断保持联系，从而为他们提供足够的支持。我们希望将可靠性方面的经验提供出来，与我们支持的更大的社区建立信任关系。在像 Meta（Facebook 的新名字）这样大规模、快速发展的环境中，有成千上万的工程师在频繁部署代码、创建特性原型，并对更改进行迭代，因此保障可靠性的工作尤其具有挑战性。我们需要对每个产品、功能和服务有明确的期望，从而可以更好的为使用我们服务的用户提供可视化的体验，并分析系统之间的任何瓶颈或复杂的交互。

我们开始研究服务水平指标（SLIs，service-level indicators）和服务水平目标（SLOs，service-level objectives），将其作为期望的设置，并根据这些期望度量服务的性能。为了提供工具支持，我们构建了 SLICK，这可以看作是一个专门的 SLO 商店。有了 SLICK，我们能够集中 SLI 和 SLO 定义，从而轻松找到和理解另一个服务的可靠性。SLICK 可以利用高留存率，以及其他工具无法找到的关键服务指标的完整粒度数据，为服务开发团队提供洞见，并将 SLO 与公司的其他各种工作流集成起来，以确保 SLO 成为日常工作的一部分。

在 SLICK 出现之前，SLO 和其他性能指标存储在定制的仪表板、文档或其他工具中。如果想要定位团队的 SLO，可能需要花费一个小时的时间来搜索或要求人们找到相关的数据。此外，之前的系统并没有以完整的粒度长时间（超过几周）保留这些指标，这使得对 SLO 进行更长时间的分析几乎是不可能的。有了 SLICK，我们现在能够：

1. 以一致的方式为服务定义 SLO

2. 精度高达分钟级别的度量数据，最多可保留两年

3. 对 SLI/SLO 指标有标准的可视化和洞见

4. 定期向内部小组发送可靠性报告，允许团队基于这些报告进行可靠性检查

可发现性（Discoverability）

SLICK 定义了一个标准的模型，帮助公司里的每个人用同样的术语讨论可靠性。这使得新的服务开发团队能够无缝遵循公司范围的标准，在服务的早期设计阶段就考虑到服务需要达到的可靠性期望。

只要知道服务名，SLICK 就可以帮助我们定位特定服务的可靠性指标和性能数据。SLICK 通过构建内置的服务索引来实现这一点，该索引链接到带有标准可视化的仪表板，以分析和评估服务的可靠性。因此，只需单击一下，就可以知道服务当前是否满足用户的期望，如果有任何问题，就可以马上开始寻找答案。

SLICK 的 SLO 索引搜索示例

长期洞察（Long-term insights）

服务可靠性的问题非常复杂。在某些情况下，单个错误的部署或某一段代码的变更可能就会导致服务突然退化。而在其他情况下，有可能随着服务的发展，不断累积微小的不可靠因素。

SLICK 允许服务所有者使用最长可达两年的完整粒度的度量和性能数据。SLICK 中的存储过程每小时运行一次数据管道，捕获所有 SLI 时间序列数据，并将它们存储在分片的 MySQL 数据库中。然后分析这些内容，形成可消费的洞见。这使得每个人——从工程师到 TPM 到领导——都能够了解随着时间的推移，可能会出现的服务可靠性的退化，而这些信息在之前很有可能会被忽视。

工作流（Workflows）

为了放大价值并帮助我们使用新的长期洞见来推动决策，SLI 和 SLO 需要使用一种人人都能理解和使用的语言来规划和评估影响。为了实现这一点，我们将 SLO 集成到公共工作流中。

当大规模事件发生时，通过查看实时工具中的 SLO，服务开发团队可以评估其对整体用户体验的影响。另一方面，当发生重大事件时，也可以基于 SLO 来驱动处理流程。我们首先使用 SLO 作为公司内部事件的标准，其他系统可以使用这些标准来获得用户看到的问题的警报。

从本质上说，将 SLI 和 SLO 集成到其他工具中，可以方便的将尚未引入的服务引入到 SLICK 中，从而以易于访问和易于使用的方式获得有效的见解。

SLICK 引入（SLICK onboarding）

服务开发团队通过 UI 或者编写一个简单的配置文件来支持 SLICK，该文件遵循带有服务名称等信息的 DSL，可以查询 SLI 时间序列以及相应的 SLO。

在用户测试并提交配置之后，SLICK 会自动将服务添加到索引中，然后生成特定于服务的指示板，并开始收集数据以进行长期观测。除了这个配置文件，其他所有集成都是开箱即用的。

使用 SLICK

1）仪表板

SLICK 仪表板为服务开发团队提供了监控实时 SLI 数据以及基于高留存率、长期数据的历史趋势的能力。

左边以完整的粒度说明了 SLI 时间序列。右侧显示基于时间的 SLI 值的每周聚合和 SLO 的相对差距。

2）周期性报告

SLICK 为工程师提供了 SLO 性能总结报告的能力，这些报告会定期发布给内部团队。报告为服务开发团队提供了一种简单的方法来关注回归并进行回顾，我们经常看到服务开发团队在这些帖子的评论中讨论可靠性问题。

一周内的 SLO 性能的 SLICK 示例报告。

3）CLI

SLICK 提供了命令行接口，使服务所有者能够执行某些操作，比如回填数据、根据需要生成报告，或者测试对 SLICK 配置的更改的效果。

SLICK 架构

总体架构

• SLICK 配置（SLICK CONFIGS）：使用 SLICK 的 DSL 编写的配置文件，由用户提交到 SLICK 配置存储区。

• SLICK 同步器（SLICK SYNCER）：将对 SLICK 配置所做的更改同步到 SLICK 配置元数据存储的服务。

• SLICK UI：为每个服务生成的 SLICK 仪表板，SLICK UI 还提供了前面提到的索引。

• SLICK 服务（SLICK SERVICE）：提供 API 的服务器，能够回答诸如“如何为特定的可视化计算 SLO？”这样的问题。服务器允许我们抽象出关于数据存储和分片的所有细节，使调用者能够轻松找到所需数据。

• SLICK 数据流水线（SLICK DATA PIPELINES）：周期性运行的流水线，以便长期获取 SLI 数据。

数据获取详细设计（Zooming in on the data ingestion）

SLICK 每小时运行一次数据流水线，这些流水线通过查询 SLICK 的配置元数据来查找所有 SLI。流水线对被监控的数据集执行所有需要的查询，以获得以分钟为粒度的当前时刻每个 SLI 的原始时间序列数据。

然后，流水线参考 SLICK 分片映射确定每个 SLI 的数据应该存储在哪里，然后将数据批量插入到适当的分片中。

此外，可以执行数据质量检查，从而使我们对数据流水线的操作方式充满信心，并快速捕获真正的错误。数据质量检查针对一组确定性测试时间序列运行，用处理真实 SLI 序列同样的方式处理这些确定性时间序列，也就是说，对它们执行流水线，将它们插入到分片数据库中，最后，将数据库中的行与预期的时间序列进行比较，以验证系统的行为。

Meta 应用 SLICK 的 SLO 的当前状态

在 2019 年创建了 SLICK 后，我们发现到 2021 年，全公司已经有超过 1000 个服务接入了 SLICK。我们还看到其他许多公司在可靠性方面的成功案例，下面会分享其中的一部分。请注意，出于保密原因，下面图表使用了模拟数据，我们删除了日期并略微修改了数值，但图表的整体形状保持不变。

LogDevice：回归检测和修复示例

LogDevice^[2]是我们的分布式日志存储系统。服务开发团队可以通过 SLICK 对读可用性进行回归检查，并且可以基于这些数据修复回归发现的问题，并通过 SLICK 确认修复恢复了读取可用性的服务级别。

LogDevice 可靠性(读可用性)。此图不按比例绘制，仅供讨论之用。

后端 ML 服务可靠性示例

2020 年，Meta 公司一个关键后端 ML 系统开始出现显著的可靠性退化，而这是一个影响到我们终端应用用户的 ML 服务。

SLICK 数据显示，该服务始终没有达到 SLO 要求，服务开发团队能够识别这种回归，并帮助启动了可靠性评估，从而帮助他们调查、发现和修复可靠性问题的根本原因。团队解决了根本原因，服务回到了满足 SLO 的状态。

后端 ML 服务可靠性(可用性)。此图不按比例绘制，仅供讨论之用。

我们的收获

在推进 SLO 的过程中，我们走过了很长的一段路，并从中吸取了一些经验教训：

• 长期跟踪能力非常有价值，能够帮助我们了解趋势，从而使我们可以计划一段更长时间的可靠性工作。

• SLO 必须处于工程文化的中心，无论是在战略可靠性规划还是日常沟通中。

• 引入 SLO 有助加强我们服务的整体可靠性。

SLICK 团队将继续致力于平台的发展以提供更多的价值。我们特别希望在以下领域进行投资：

1. 使服务的 SLO 与其依赖项的 SLO 保持一致。这将允许团队理解他们的依赖关系如何影响他们的性能，还能帮助我们揭示调用栈中服务之间不匹配的期望值，而这些不匹配因素有可能触发级联失败。

2. 为服务开发团队提供如何提高服务可靠性的反馈和建议。我们希望利用在提高可靠性方面的经验，为服务开发团队提供可操作的见解，以帮助他们提高可靠性并满足 SLO。

3. 进一步发展 SLICK 的覆盖范围。我们希望在 SLICK 上搭载更多的团队和服务，为了做到这一点，SLICK 需要保持可靠性和可扩展性（满足我们自己的 SLO）。

References:

[1] SLICK: Adopting SLOs for improved reliability: https://engineering.fb.com/2021/12/13/production-engineering/slick/

[2] LogDevice: https://engineering.fb.com/2017/08/31/core-data/logdevice-a-distributed-data-store-for-logs/

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。微信公众号：DeepNoMind