SLO 新解，一种行之有效的故障处理方法

近年来 SLO（Service Level Objective）的概念日趋流行，国外不少公司效仿 Google 的最佳实践落地 SLO，很多服务商也支持了 SLO（如 Datadog），甚至有创业公司专门聚焦 SLO 的产品化方案（如 NOBL9、Sloth 等）。

本文主要不是普及 SLO 概念，而是分析"跟风"SLO 方法时可能出现的错误，并介绍一种应用于故障处理场景，并行之有效的"类 SLO"实践。

为方便本文区分，Google SRE 方法中所倡导的 SLO 实践，我们称之为 CSLO（Classical SLO）。

注：本文提到的故障处理，特指业务或服务出现明显异常，需要进行紧急响应和快速恢复的情况。

CSLO的要点

先简单介绍一下 CSLO 相关的要点：

• 通常是一个量化的“目标”，用来表示某个 Service 可靠性要达到的程度；

• 基于该"量化目标"计算出一个时间区间内服务可以接受的错误预算（Error budget）；

• 研发和运维等团队基于"错误预算"做出日常工作的决策，或某个阶段的工作重点，如是共同推进产品迭代还是共同推进稳定性治理，SLO 达标则是前者，SLO 不达标或即将不达标则是后者；

其中错误预算的消耗被放在很重要的位置，是决策的关键，工作协同是方法的重要目的。

CSLO常见落地方法

CSLO 涉及核心指标、用户视角的稳定性、可靠性目标、报警策略这些概念和方法，这些同时也是服务稳定性保障所需要的。

因此很多公司实际未必将 CSLO 的方法应用于工作协同，而是用于服务稳定性保障和故障处理场景。

但直接将 CSLO 作用于稳定性保障，可能会出现如下问题：

• 制定和调整难：CSLO 首先要在多个团队间达成协议，这并不太容易，要调整则通常需要再协商，因此制定和调整难度都很大；

• 约束多：CSLO 方法注重“错误预算”的消耗，所有相关工作都聚焦于此，包括报警和报警策略；强调从用户侧，从服务层来选取核心指标；不建议所有的功能/模块都纳入，指标要少而精；

SLO 的制定和调整方法，以及相关的"约束"用于达成 CSLO 的"工作协同"目标时是正确的。

但用于服务稳定性保障，目的变了，方法就要跟着变，如果还完全遵照原来的方法去落地，就会发现束手束脚，难以达到理想的效果。

总结起来 CSLO 应用于服务稳定性保障，有可能出现的情况是：把坦克当交通工具，既笨重又难用。

服务稳定性保障中的SLO

下面我们变换思路，介绍一种把解决服务稳定性保障问题作为核心目标，把产生团队协同作为附加功能的 SLO 方法。

核心目的：故障发现和故障定位

1. 将故障处理的过程拆分，主要聚焦在故障发现和故障定位两个环节；

2. 故障发现对应一套量化的核心业务指标，这套核心业务指标的核心功能是量化并报警发现故障；

3. 故障定位则下沉到服务（service）/系统层面，在这个层面通过三大黄金指标（请求成功率、流量、响应延迟）量化全部核心功能和核心模块的健康状态，通过设置一个简单的目标值来辅助快速收敛故障源的范围；

业务指标：通常是指业务运营相关的指标，如电商业务的在线用户数、订单量、支付量、在线商品数、GMV 等。

这两个层面的量化，理想情况下的效果是：

• 凡是出现了明显影响业务或用户体验的故障，故障发现层都及时产生报警；

• 凡是故障发现层产生了报警，故障定位层都出现飘红，准确的指向系统中的故障源；

如果以上任一效果没有达成，则说明需要对指标的选取、指标的准确性、指标的覆盖面或报警的准确性进行优化。

附加功能：基于稳定性配额的团队协同

用于发现故障的核心业务指标首先要能够量化故障，既然这些指标已经量化了故障，那就可以基于这个量化来制定稳定性的目标（SLO）和配额（Error budget）。

计算公式：

• 全年可用性目标 =（3652460 - 全年故障时长配额）/ （3652460） * 100% = 99.**%

• 全年故障时长配额 = 3652460 * （1- 全年可用性目标）= x 分钟

对比来看，这个方法和 CSLO 有以下几点相同和不同。

相同：

• 都对服务的健康状态进行了量化

• 都基于量化实现了预算配额管理，并基于此在各团队间产生协同

以上两点即是 CSLO 的核心方法和目标。

不同：

• 抽象了一个业务视角的目标，这一层准确来讲可以叫BLO（business level objective，业务层目标），而不是服务层目标 SLO；

• 在故障处理的场景里，BLO 的核心目的是发现故障，而不是团队协同；

• BLO 层面的报警追求实时、准确、快速的发现故障，不考虑错误预算消耗的问题，更不基于错误预算来产生报警；

• 服务层（SLO）的差异则包括：

• 不再服务于团队协同决策，而是服务于故障定位；

• 量化的指标不局限于单个，使用相关的 3 大黄金指标更好（有利于做相关性分析）；

• 覆盖面不再需要“克制”，而是要覆盖全部的核心功能和核心模块；

• 不注重这层的报警实现，取而代之用 dashboard 上的实时飘红效果来标识目标达成状态（而非错误预算的消耗），起到引导收敛故障源的作用即可；

以上异同的核心是：多了一个 BLO 层，这层的核心目的不是用来做团队协同，但覆盖了 CSLO 的核心目标和特点（会有相同的约束，如目标和配额的调整需要协商等），而将 service 层的 SLO 则没有这些约束，会更为灵活自由。

方法演进和分析

虽然故障发现这层建议用"业务指标"，但其实这层如替换成 CSLO 的"服务指标"，只要能做到在整体上从服务角度、从用户角度准确的量化一个服务的健康状态，也未尝不可。

那使用业务级别的指标，或服务级别的指标来量化和发现故障会有什么不同吗？

• 视角不同：服务级别是从用户的视角来看，而业务级别是从业务的运营者，或公司老板的视角来看；

• 指标形态不同：用户视角的量化指标通常是一个“百分比”，如用户请求的成功率。业务视角的量化指标通常是一个“量”，如实时的下单量；

• 报警难度不同：百分比类的指标通常设置一个简单的绝对阈值就可以准确报警，但"量"相关的值则需要通过类似同环比对比或智能检测来发现异常；

• 采集点不同：业务指标的数据通常来源于线上服务的数据库等存储中。而服务指标的数据采集点可能有很多，比如服务网关、app/pc 端等；

• 数据准确性：业务指标如果是直接采自业务的存储，通常数据准确性极高，不会因为用户端和服务端的网络异常、服务攻击等问题影响其准确性；而服务指标则可能刚好相反；

使用哪类指标来做故障发现更适合自己的服务和环境呢？

很可能启动的时候偏向于采集容易的指标，而后向数据准确性去演进，最后的效果可能全部是业务指标，可能全部是服务指标，也可能是二者兼而有之。很认同 CSLO 的实施理念：先落地，后优化，逐步迭代。

就做服务稳定性保障同学一个普遍的痛点：难以说清楚稳定性工作对业务的价值。则严重推荐首选业务指标来做故障的量化和管理。

这样可以将稳定性的影响和业务实现了挂钩，使服务稳定性保障工作对业务的“直接”影响进行了量化（间接影响是巨大而不可估量的），能够从数据上证明稳定性对业务的支持是在持续变好还是变坏。

面向故障处理的SLO产品

以下是上面这个方法相配套的产品案例。

Flashcat 北极星 - 对应故障发现的 SLO/BLO 系统

Flashcat 灭火图 - 对应故障定位的 SLO 系统

结束语

本期文章分析了 CSLO 落地的可能问题，并介绍了服务稳定性保障中的 SLO 实践。

后面还将全面的介绍服务于故障处理场景的监控产品，介绍如何将最佳实践和经验沉淀到平台，如何联动企业内部已有的各种监控平台做到 1+1>2，如何降低故障处理的门槛加速故障处理的效率。

作者原文首发地址：https://mp.weixin.qq.com/s/dA-7o-7wv0x24pDf0TXJag

关于快猫星云

一家云原生智能运维科技公司，秉承着让监控分析变简单的初心和使命，致力于打造先进的云原生监控分析平台，结合人工智能技术，提升云原生时代数字化服务的稳定性保障能力。快猫星云团队是开源项目夜莺监控的主要贡献者、项目管理委员会核心成员。

• 官网：http://flashcat.cloud
  

• 产品 demo：http://demo.flashcat.cloud/
  

关于夜莺监控

一款开源云原生监控分析系统，采用 All-In-One 的设计，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力，已有众多企业选择将 Prometheus + AlertManager + Grafana 的组合方案升级为使用夜莺监控。夜莺监控，由滴滴开发和开源，并于 2022 年 5 月 11 日，捐赠予中国计算机学会开源发展委员会（CCF ODC），为 CCF ODC 成立后接受捐赠的第一个开源项目。

• 夜莺监控项目文档站点：https://n9e.github.io
  

• 欢迎大家在 github 上 star 夜莺项目：https://github.com/ccfos/nightingale
  

• 加入夜莺交流社群请添加微信：flashcats

• 点击阅读原文即可访问夜莺的 github