为ETL和报告应用程序定义SLI / SLO

Question

全,

我们刚刚开始SRE之旅，并试图为我们的应用程序定义SLI / SLO。它是一个ETL应用程序，其中1.feed(例如，开始一天，结束一天的数据提要)来自不同的上游，并加载了一些转换。2.一旦加载提要，就会有一些处理数据和填充其他表的作业。3.根据第1和第2点，将数据提供给下游应用程序和用户。

在这种情况下，我们认为用户体验是，

1. 特定区域下游应用程序在特定时间的数据可用性
2. 特定区域用户在特定时间的数据可用性

我们根据需要数据的时间来确定以上两点的时间。基于此，我们为我们创建了SLI，如果我们必须确保在正确的时间交付数据，我们至少需要1.5小时来调查、重新处理提要，即下游/用户的SLA - 1.5小时->我们认为这是SLI。

在测量同样的时候，我们捕获了有多少次我们无法得到SLO时间处理的提要，并将%，即95%的时间，我们应该能够在SLO时间之前交付数据。

这是定义SLI / SLO的正确方法吗？

如果我们查看SLI / SLO上的大多数文档/视频等，它们会更多地关注微服务响应，以及衡量它们的成功/失败或延迟等，但在ETL或报告应用程序方面却找不到任何东西。

我可能在上面的方法是错误的，因此期待一个专家的意见，以获得更多的理解。

提前谢谢你的帮助。

PS:找不到SRE的标记或它附近的任何实践，所以用DevOps标记了问题。

Answer 1

术语"SLI“、"SLO”和"SLA“具有适用于规模、领域和抽象范围的精确含义。虽然大多数文献都集中在微服务上，但这是因为微服务现在是“热门”的。要从根本上理解这些概念，请看每一个缩略词中的最后几个词：

• 指标是一种衡量手段。这是你看的东西，一张能回答问题的数据。“我们的反应有多快？”“ETL过程中发生了多少错误？”“我们的缓存命中率是多少？”
• 目标就是目标。这是你想去的地方。它们可以是有抱负的(例如，我们目前在ETL过程中每天有20个错误，但我们的目标是5)，或者它们可以是稳定的(例如，我们的响应时间是200 is，它不能降到250 is以下)。不存在与这些目标相关的强制执行或责任。
• 协议是具有法律约束力的意向书。如果一项协议被违反，经济(甚至是合法的)处罚就会受到威胁。例如，如果您同意每年的SLA为59个正常运行时间(99.999%)，一次超过5分钟的中断将破坏您的SLA，并可能构成违约。

希望这能帮上忙。