如何为系统可靠性的量化提供依据

SLA 即 Service Level Agreement，也就是服务等级协议，它指的是系统服务提供者（Provider）对客户（Customer）的一个服务承诺。

而 SLO 就是 SLA 的具体目标管理办法，它由一系列相关的指标 SLI （Service Level Indicator）来进行衡量。SLI 和我们之前讨论的 Metric（指标）有所不同：不是所有的 Metric 都是 SLI，SLI 应该更靠近使用产品和服务的最终用户，用于衡量提供给最终用户的服务水平，具体包括可用性、响应时间等等。

有了 SLI，我们就可以检测在每个检测周期内各个 SLI 是否满足要求，从而计算整体的 SLO 情况了。SLO 具体来说，指的是在一个时间窗口内，各项 SLI 预期的累计成功百分比。这个时间窗口可以根据业务的需要来定义，一般来说为 30 天。

举个例子，过去 30 天（总计 43200 分钟），如果发生异常的时间为 2 分钟，则 SLO 的状态为 （43200 - 2）/ 43200 * 100% = 99.995%。这里有一个对应的概念叫做错误预算（Error Budget），它指的是初始状态时 100% 可靠性和 SLO 目标之间的差额。

始终保持 100% 的可靠性是不可能的。SLO 可以帮助你在产品创新（这将帮助你为最终用户提供更大价值，但有一定破坏稳定性的风险）和可靠性（这将使最终用户在使用产品和服务的时候感到满意）之间找到正确的平衡点。你的错误预算决定了，在你的服务质量下降到真正影响最终用户正常使用之前，开发工作能承受的不可靠性的程度。

随着你的基础架构越来越复杂，为每个数据库、消息队列和负载均衡器设置外部 SLO 变得越来越麻烦。相反，我建议你将你的系统组件组织成几个主要类别（例如，响应 / 请求、存储、数据管道），并在每个类别中指定 SLI。在选取 SLI 的时候，请记住：“所有 SLI 都是指标，但并非所有指标都是好的 SLI。” 这意味着，虽然你可能要跟踪成百上千个指标，但你应该关注最重要的指标：最能捕捉用户体验的指标。

可以使用下指标作为参考。

• 响应或者请求类型的服务。
  • 可用性：服务成功响应的请求比例。
  • 延迟：响应请求需要多长时间，超过某个阈值的请求比例。
  • 吞吐量：可以处理多少个请求。
• 数据存储类型的服务。
  • 可用性：数据是否可以按需访问，可以成功读取和写入的比例。
  • 延迟：读取和写入需要多长时间，超过某个阈值的比例。
  • 耐用性：用户所需要的特定数据是否存在。
• 数据管道（Pipeline，将输入的数据进行转换并进行输出，例如从多种来源收集日志并生成报告）。
  • 正确性：进入管道的产生正确的值的记录所占的比例。
  • 新鲜度：新数据或处理结果需要多长时间出现。

无论一个指标对你的内部团队有多重要，如果它的价值不直接影响用户满意度，那么它作为 SLI 就没有用处，反而可能带来告警的风暴，淹没了更加重要的信息。

此文章为3月Day11 学习笔记，内容来源于极客时间《深入浅出可观测性》，推荐该课程。