近年来，SLO（Service Level Objective，服务级别目标）的概念日趋流行。国外不少公司效仿 Google 的最佳实践落地 SLO，很多服务商也支持了 SLO（如 Datadog），甚至有创业公司专门聚焦 SLO 的产品化方案（如 NOBL9、Sloth 等）。
本文主要不是普及 SLO 概念，而是分析“跟风”SLO 方法时可能出现的错误，并介绍一种应用于故障处理场景、并且行之有效的“类 SLO”实践。
Google SRE 方法中所倡导的 SLO 实践，本文称之为 CSLO（Classical SLO，经典 SLO）。如果你对 SLI、SLO、SLA、Error budget 等基础概念还不熟悉，可以先看文末附录。
注：本文提到的故障处理，特指业务或服务出现明显异常，需要进行紧急响应和快速恢复的情况。
核心要点摘要
- CSLO 的核心不是“做几个百分比指标”，而是用 SLI、SLO 和错误预算（Error budget）驱动跨团队协同。
- 如果把 CSLO 原样用于服务稳定性保障和故障处理，容易遇到制定难、调整难、约束多的问题。
- 面向故障处理的 SLO 实践，应该先服务于故障发现和故障定位，再把团队协同作为附加收益。
- 更适合故障处理的做法是增加 BLO（Business Level Objective，业务层目标）：业务层负责发现故障，服务层 SLO 负责定位故障。
- BLO 层面的报警要追求实时、准确、快速；服务层 SLO 则应覆盖核心功能和核心模块，用三大黄金指标帮助快速收敛故障源。
先区分两类 SLO：协同型 SLO 和故障处理型 SLO
讨论 SLO 落地前，先要明确目标。
如果目标是跨团队协同，经典 CSLO 方法非常合适。它通过量化目标和错误预算，让研发、运维、产品等团队围绕同一套可靠性目标做决策。
如果目标是故障处理，尤其是故障发现和故障定位，照搬 CSLO 反而可能变得笨重。故障处理关心的是：业务是不是已经异常，异常来自哪个服务、系统、核心功能或核心模块。这个目标和团队协同相关，但不是同一件事。
本文介绍的实践可以概括为一句话：
用 BLO 发现业务故障，用服务层 SLO 定位系统故障，再用错误预算把稳定性影响转化为团队协同语言。
CSLO 的要点
先简单介绍一下 CSLO 相关的要点：
- CSLO 通常是一个量化的目标，用来表示某个 Service 可靠性要达到的程度；
- CSLO 基于这个量化目标计算出一个时间区间内服务可以接受的错误预算（Error budget）；
- 研发和运维等团队基于错误预算做出日常工作决策，或决定某个阶段的工作重点：SLO 达标时共同推进产品迭代，SLO 不达标或即将不达标时共同推进稳定性治理。
在 CSLO 中，错误预算的消耗被放在很重要的位置，是决策的关键；工作协同则是方法的重要目的。
CSLO 常见落地方法与问题
CSLO 涉及核心指标、用户视角的稳定性、可靠性目标、报警策略等概念和方法。这些内容同时也是服务稳定性保障所需要的。
因此，很多公司实际并不是把 CSLO 用于工作协同，而是把它用于服务稳定性保障和故障处理场景。
但直接将 CSLO 作用于稳定性保障，可能会出现如下问题：
- 制定和调整难：CSLO 首先要在多个团队间达成协议，这并不太容易。后续如果要调整，通常还需要再次协商，因此制定和调整难度都很大。
- 约束多：CSLO 方法注重错误预算的消耗，所有相关工作都聚焦于此，包括报警和报警策略；它强调从用户侧、从服务层选取核心指标，不建议所有功能和模块都纳入，指标要少而精。
SLO 的制定和调整方法，以及相关约束，用于达成 CSLO 的工作协同目标时是正确的。
但用于服务稳定性保障时，目的变了，方法就要跟着变。如果还完全遵照原来的方法去落地，就会发现束手束脚，难以达到理想效果。
总结起来，CSLO 应用于服务稳定性保障时，有可能出现的情况是：把坦克当交通工具，既笨重又难用。
面向服务稳定性保障的 SLO 实践
下面换一个思路，介绍一种把解决服务稳定性保障问题作为核心目标、把团队协同作为附加功能的 SLO 方法。
核心目的：故障发现和故障定位
面向故障处理的 SLO 实践，可以拆成三步：
- 将故障处理过程拆分，主要聚焦在故障发现和故障定位两个环节。
- 故障发现对应一套量化的核心业务指标。这套核心业务指标的核心功能，是量化业务异常并通过报警发现故障。
- 故障定位下沉到服务（Service）或系统层面。在这个层面，通过三大黄金指标量化全部核心功能和核心模块的健康状态，并通过设置简单目标值来辅助快速收敛故障源范围。
这里的三大黄金指标包括：
- 请求成功率：服务请求是否大量失败；
- 流量：业务或服务请求量是否明显异常；
- 响应延迟：服务响应是否明显变慢。
业务指标：通常是指业务运营相关的指标，如电商业务的在线用户数、订单量、支付量、在线商品数、GMV 等。
这两个层面的量化，理想情况下的效果是：
- 凡是出现了明显影响业务或用户体验的故障，故障发现层都能及时产生报警；
- 凡是故障发现层产生了报警，故障定位层都出现飘红，准确指向系统中的故障源。
如果以上任一效果没有达成，则说明需要对指标的选取、指标的准确性、指标的覆盖面或报警的准确性进行优化。
实践流程总览
| 环节 | 目标 | 典型指标 | 判断方式 | 产出 |
|---|---|---|---|---|
| 故障发现 | 尽快发现业务或用户体验异常 | 订单量、支付量、在线用户数、GMV、核心请求成功率等 | 实时报警、同环比对比、智能检测或阈值判断 | 明确“业务是否异常” |
| 故障定位 | 快速收敛故障源范围 | 请求成功率、流量、响应延迟 | Dashboard 飘红、目标值达成状态、指标相关性分析 | 明确“哪个服务或模块异常” |
| 稳定性协同 | 把故障影响转化为团队可讨论的语言 | 可用性目标、故障时长配额、错误预算 | 周期内预算消耗情况 | 决定继续迭代还是加强稳定性治理 |
这套方法的关键，是不要把所有目标都压到同一个 SLO 上。业务层要负责发现故障，服务层要负责定位故障，错误预算要负责团队协同。
附加功能：基于稳定性配额的团队协同
用于发现故障的核心业务指标首先要能够量化故障，既然这些指标已经量化了故障，那就可以基于这个量化来制定稳定性的目标（SLO）和配额（Error budget）。
计算公式：
全年可用性目标 =（365 * 24 * 60 - 全年故障时长配额）/（365 * 24 * 60）* 100% = 99.**%
全年故障时长配额 = 365 * 24 * 60 *（1 - 全年可用性目标）= x 分钟
对比来看，这个方法和 CSLO 有以下几点相同和不同。
相同点：
- 都对服务或业务的健康状态进行了量化；
- 都基于量化实现预算配额管理，并基于此在各团队间产生协同。
以上两点即是 CSLO 的核心方法和目标。
不同点：
- 这个方法抽象了一个业务视角的目标。这一层准确来讲可以叫 BLO（Business Level Objective，业务层目标），而不是服务层目标 SLO。
- 在故障处理场景里，BLO 的核心目的是发现故障，而不是团队协同。
- BLO 层面的报警追求实时、准确、快速地发现故障，不考虑错误预算消耗的问题，更不基于错误预算来产生报警。
- 服务层 SLO 不再服务于团队协同决策，而是服务于故障定位。
- 服务层 SLO 的量化指标不局限于单个指标，使用相关的三大黄金指标更好，因为这有利于做相关性分析。
- 服务层 SLO 的覆盖面不再需要“克制”，而是要覆盖全部核心功能和核心模块。
- 服务层 SLO 不强调报警实现，可以改用 Dashboard 上的实时飘红效果来标识目标达成状态，而不是错误预算消耗。这样做的目的，是引导快速收敛故障源。
以上异同的核心是：多了一个 BLO 层。
这一层的核心目的不是做团队协同，但它覆盖了 CSLO 的核心目标和特点，也会有相同约束，例如目标和配额的调整需要协商。服务层 SLO 则没有这些约束，因此可以更灵活、更自由地服务于故障定位。
BLO 与服务层 SLO 如何选择指标
虽然故障发现这层建议用业务指标，但如果替换成 CSLO 的服务指标，只要能从服务角度、用户角度在整体上准确量化一个服务的健康状态，也未尝不可。
真正的问题是：使用业务级别的指标，或服务级别的指标来量化和发现故障，会有什么不同？
| 对比维度 | 业务级别指标 | 服务级别指标 |
|---|---|---|
| 观察视角 | 业务运营者或公司老板的视角 | 用户视角 |
| 指标形态 | 通常是一个“量”，如实时下单量、支付量 | 通常是一个百分比，如用户请求成功率 |
| 报警难度 | 常需要同环比对比或智能检测来发现异常 | 常可通过简单绝对阈值报警 |
| 采集点 | 通常来源于线上服务的数据库等存储 | 可能来自服务网关、App、PC 端等多个采集点 |
| 数据准确性 | 如果直接采自业务存储，通常准确性较高 | 可能受用户端、服务端网络异常或服务攻击等问题影响 |
哪类指标更适合做故障发现
使用哪类指标做故障发现，要看自己的服务和环境。
启动阶段，很可能偏向于采集容易的指标；随后再向数据准确性演进。最后的效果可能全部是业务指标，可能全部是服务指标，也可能是二者兼而有之。
这里很认同 CSLO 的实施理念：先落地，后优化，逐步迭代。
对于做服务稳定性保障的同学，还有一个普遍痛点：难以说清楚稳定性工作对业务的价值。因此，强烈建议首选业务指标来做故障的量化和管理。
这样可以将稳定性的影响和业务挂钩，使服务稳定性保障工作对业务的直接影响被量化。稳定性对业务的间接影响是巨大而不可估量的，但直接影响可以通过数据持续观察：它是在变好，还是在变坏。
面向故障处理的 SLO 产品形态
以下内容有一定的广告嫌疑，但确实能更好地理解这种 SLO 实践。
Flashcat 北极星：对应故障发现的 SLO/BLO 系统
北极星对应的是故障发现层。它面向业务层目标，用核心业务指标量化业务异常，并帮助在故障真正影响业务或用户体验时尽快发现问题。
Flashcat 灭火图：对应故障定位的 SLO 系统
灭火图对应的是故障定位层。它面向服务层目标，用请求成功率、流量、响应延迟等指标展示核心功能和核心模块的健康状态，通过实时飘红帮助定位故障源。
FAQ
1. SLO 一定要按 Google SRE 的 CSLO 方法落地吗？
不一定。CSLO 适合用错误预算驱动团队协同，但故障处理更关注发现和定位。如果目标是服务稳定性保障，可以保留 SLO 的量化思想，同时调整指标层次、覆盖范围和报警策略。
2. BLO 和 SLO 的区别是什么？
BLO 是业务层目标，关注业务指标是否异常，例如订单量、支付量、在线用户数等。SLO 是服务层目标，关注服务或系统的健康状态，例如请求成功率、流量、响应延迟等。在本文的实践里，BLO 主要用于故障发现，服务层 SLO 主要用于故障定位。
3. 错误预算还重要吗？
重要，但它不应该绑架故障发现和故障定位。错误预算更适合用于稳定性配额管理和团队协同，而不是直接决定故障报警是否触发。
4. 故障发现层应该优先选择业务指标还是服务指标？
如果能拿到准确的业务指标，建议优先选择业务指标，因为它能把稳定性影响和业务结果直接挂钩。如果业务指标暂时不好采集，也可以先从服务指标开始，后续逐步向更准确、更贴近业务影响的指标演进。
5. 服务层 SLO 为什么不强调少而精？
因为这里的服务层 SLO 主要用于故障定位，不是用于跨团队协同决策。定位故障需要覆盖核心功能和核心模块，覆盖面过窄反而不利于快速收敛故障源。
结论
本期文章分析了 CSLO 落地的可能问题，并介绍了服务稳定性保障中的 SLO 实践。
面向故障处理时，SLO 的关键不是机械复制 CSLO，而是围绕“如何更快发现故障、如何更快定位故障”重新组织指标体系。业务层 BLO 负责发现故障，服务层 SLO 负责定位故障，错误预算负责稳定性配额和团队协同。这样既保留了 SLO 的量化优势，也避免了把协同型方法生硬套到故障处理场景里。
后面还将全面介绍服务于故障处理场景的监控产品，介绍如何将最佳实践和经验沉淀到平台，如何联动企业内部已有的各种监控平台做到 1+1>2，如何降低故障处理门槛并加速故障处理效率。
合作进步
都看到这里了，相信你对监控体系的建设，对SLO的实践，对服务稳定性保障是感兴趣的。
我们正在招募更多的企业用户和我们一起完善云原生监控体系，一起打造极致的、面向数字化服务故障处理场景的监控产品。
如果您的企业对这方面有需求，欢迎通过以下方式联系我们，体验我们的产品。期待和热衷探求新知的你，和优秀的企业伙伴共同进步！
联系方式：
微信：myrainhua
邮箱：contact-us@flashcat.cloud
附录：CSLO 相关概念
基础术语
- SLI：Service Level Indicator，服务级别指标，是量化 SLO 的具体指标；
- SLO：Service Level Objective，服务级别目标，通常可以理解为 SLI + 目标值；
- SLA：Service Level Agreement，服务级别协议，即 SLO 目标跌破后的行动约定；
- Error budget：错误预算，用于量化一定时期内可以容忍产生的错误量或失败量；
- SLA = SLO + 目标值跌破后的协议行动；
- Error budget =（100% - SLO）x 时间总量或请求总量。
CSLO 主要特点
- 通常是一个百分数（0~100%），如用户请求的成功率要达到 99.9%、用户请求在 100ms 内完成的占比要达到 90%；
- 强调从服务和用户视角来定义 SLO，关注 Service 所提供的核心功能是否达标；
- 用于量化 SLO 的指标不应过多，但要能代表服务整体健康状态，覆盖用户的核心流程；
- 核心目标是基于错误预算做团队协同。
CSLO 主要理念
- 量化目标，用数据说话；
- 合适就好，不能盲目追求过高甚至完美的稳定性目标，要考虑必要性和投入产出比；
- 设定 SLO 的目的是以量化方式驱动科学决策，而非定责。
