看完这篇 SLO 质量运营体系，秒变 SRE 达人！

SLI 是整个 SLO 工程的基础，根据谷歌的指导思想，SLI 通常是两个数的比值：好事件数量 /总事件数量。

• 请求驱动型服务：状态码 200 请求数/总请求数

• 数据驱动型服务：离线任务 30 分钟内完成的任务数/总请求数。

• 业务指标：1分钟下单成功数/总下单数

在选择 SLI 时，遵循两个原则：

• SLI 指标体现目标的稳定性：比如业务有 HTTP Client 和 HTTP Server 两个指标， HTTP Client 用来统计服务调用下游依赖的指标，度量应用稳定性显然没有 HTTP Server 更合适。
  

• 优先选择和用户体验强相关的指标：用户能明显感知到的指标，像应用 rpc 连接数，db 连接数这类指标也不合适，用户能直观感受到的还是可用率、延迟这类指标。

单个 SLI 规范有多种实现方式，主要从质量、覆盖范围以及实现成本三个方面来考虑。

这里举个例子，比如统计接口在 100 毫秒内返回的比例，我们可以从移动端、网关、服务指标、日志这四种方式获取到。

如果从移动端度量，实现成本会比较高；从服务日志度量，因为有采样，显然也不满足覆盖范围这个条件。所以在选择 SLI 时，还要根据实际情况多维度去选择。

介绍完 SLI 的一些基本概念和选取标准，下面介绍我们的 SLI 是如何选择的。首先是应用 SLI，在线类业务都是请求驱动型，最简单的实现成本就是通过负载均衡上的指标来度量，但这样会有覆盖度不全的问题，部分内网服务是不经过负载均衡的，内网服务之间大部分都是直接 rpc 调用。

所以从整个请求的完整链路来看，我们将系统按层级划分，SLB网关应用层，都可以拿到对应的错误数、可用率、延时指标。在不同的层级去分别定义，通过这种方式各补，可以完整覆盖全部故障场景。

当然，我们在实施过程中也遇到了很多问题，其中最常见的就是业务接入时，发现框架不统一，指标不统一，甚至有些服务没用框架，各种五花八门的指标，给我们的指标采集阶段带来了不小挑战，那么我们是怎么解决的呢？

通过对框架指定模板，模板关联SLI，针对一些未用公司开发框架的业务，也支持了自定义指标的方式。

应用 SLI 的度量粒度还是比较粗的，统计的是整个应用纬度的指标，应用的具体接口才是业务功能的直接提现，所以我们通过核心场景的 SLI 来精细化度量。

整体实施流程是 SRE 先梳理公司的核心业务，从公司的核心业务中挑选出代表业务功能的 API，我们从可用率、错误数、延时、吞吐这几个方面去度量核心场景。

梳理完核心场景，采集到指标数据后，对多个核心场景的指标聚合到业务纬度。比如 APP 播放这个业务下定义了三个核心场景，通过这三个核心场景的数据聚合，最终产出 App 播放这个业务的指标数据。

虽然我们已经定义了应用 SLI 和核心场景 SLI，但还有一些case是捕获不到的，比如端上异常导致的踢登陆态，代码 bug 导致的充值失败等等，技术指标只能发现服务端所有不可用问题，需要通过业务指标来补位核心场景的逻辑异常。

业务指标常见的实现方式有两种，一种是通过大数据流式实时计算，另一种是订阅数据库的binlog，拿到分钟订单数，分钟发送弹幕数等等。

在生产环境中，我们通常会发现由基础组件导致的异常（数据库、LB、Mq）往往会导致线上大规模服务的异常，而且恢复时长往往需要按小时计，所以我们补齐了基础组件的SLI，来帮助快速发现问题。

组件 SLI 分为几类：

• 流量接入型：DCDN、SLB、APIGW，可以度量可用率和延时。

• 存储型：MySQL、Redis、KV、ES 等，我们度量整个集群的可用状态及在线节点数等。

• 流水线型：消息队列、离线任务等，可以度量任务延时情况。

SLO（服务等级目标）指定了服务可靠性的目标水平，是衡量可靠性的工具，SLO对SRE稳定性方向的工作开展具有指导性意义。

SLO 在制定的时候有两点需要特别注意：

• 一是时间窗口的选择；是选择滚动窗口还是自然窗口？滚动窗口与用户体验更接近，通常四个星期会是一个很好的通用间隔；自然窗口与工作计划结合得比较密切。通过自然窗口内的数据来指导下个 Q 的稳定性工作方向。滚动窗口+自然窗口相结合是一种很好的实现方式。

• 二是整个目标应该如何制定？可以先基于时间窗口的历史周期数据计算出一个推荐值，由 SRE 和研发，产品共同制定，并且在实施过程中不断调整优化，如果业务做了一些架构升级或稳定性相关工作，业务的 SLO 会得到提升。

有了 SLO 之后我们可以统计错误预算，计算燃烧率。错误预算用于测量实际性能与预期性能之间的差异，通常是按滚动窗口进行更新。通过预算消耗燃尽图能很直观的看到预算消耗趋势和当前剩余预算。

燃烧率的定义是错误预算的消耗速度，计算方式是当前错误率/基准错误率，也就是1-SLO，燃烧率如果越高，代表线上故障越严重， SRE 需要及时去干预处理。

除了报表展示之外，SLO 另一个核心价值就是告警。在评估告警策略时，我们通过精度、召回、检测时间、重置时间四个方面来考虑。这里列举了6种告警规则。

一是基于目标错误率，这种方式的优点是任何威胁到 SLO 事件都会触发，召回率良好。劣势在于如果告警计算周期是1分钟的话，极端情况下每天会收到1440条告警，如果不做任何处理，仍然是满足 SLO。

二是基于错误预算窗口，比如消耗了最近 30 天错误预算的 5% 告警，这种报警规则完全宕机 2.16 分钟就可以发出报警，但是告警会一直持续，直到 36 小时之后才会恢复，这个弊端是告警会一直重复发生。

三是增加报警持续时间，如果业务有抖动，就增加报警持续时间。这种方式有一个明显弊端，线上服务完全不可用和错误数很少的情况（比如 0.2%），都是持续10分钟后发出报警。那么报警的灵敏度与当前服务错误率没有什么直接关系。另一个弊端是如果业务频繁抖动，持续时间的计数器会被重置，可能永远发不出告警。

四是基于消耗率，比如1小时消耗掉当月36小时的错误预算，这时消耗率是36。这种也有一个比较明显的弊端，如果当前的消耗率是 35，不会发出报警，但是当消耗率为35时，理论上只需要 20.5 个小时就可以消耗掉整个错误预算。

五是多次消耗率告警，我们可以配置不同的消耗率的报警，如果线上故障比较严重，可以立即发出报警。如果可用率下跌不是很严重，但是持续时间很长的话，我们也可以顺利地发出报警。缺点是会存在重复报警的问题，短窗口和长窗口内消耗率会存在同时满足告警阈值的情况，需要做告警抑制。

六是多窗口多消耗率告警，这里增加了一个短窗口的概念，通常推荐值是长窗口的 1/12，短窗口用于在报警和恢复时检测是否达到了错误预算消耗速度。但是这种方式弊端在于整个报警表达式复杂且参数多，整个计算逻辑复杂，配置成本较高。

传统运营通常需要技术支持，响应研发的各类报警需求，有来自系统层面的磁盘、内存、CPU、网络等告警，有应用层面的进程数、进程是否存在、端口是否异常等，以及业务层面的日志关键字告警，接口是否返回200等。

通过SLO来驱动能有非常好的运营效果，因为这个标准由研发与 SRE 共同制定；稳定性相关的数据是统一进行采集、计算、聚合、展示的，通过数据运营去驱动，指导SRE和研发稳定性相关的工作的开展。

总结一下：通过SLO进行质量运营，覆盖范围更广，实现成本更低。

围绕 SLO 去质量运营的一个重要手段就是报表能力。通过不同的时间维度来统计错误预算的消耗率，以及按照日、周、月、季等多维度聚合出业务的可用性报表。每周会进行 SLO 达标率统计，如果有业务 SLO 不达标，由 SRE 和研发共同跟进处理。

除了质量运营，SLO 工程能否再继续挖掘价值？B站围绕 SLO 建设了 GOC（全球运行中心），整体目标是防止能预见的问题；对不能够预防的问题能快速恢复；已发生的问题不再重复。GOC 的定位是管理整个故障的全生命周期。对线上事故的要求是1分钟发现、5 分钟定位、10分钟解决故障。

B站目前故障发现有三种渠道，第一种最常见的基于SLO告警，比如播放服务可用率严重下跌肯定会对线上服务有影响，这时候可以升级为故障。

第二种是通过业务 KPI 指标，比如分钟订单数、分钟在线直播数，这些指标如果有明显的下跌，那肯定也是代表现在线上有异常。

最后是通过客服舆情的方式，客服在收到大量用户进线时判断，如果是需要技术来解决的，会录入故障平台进行跟进处理，

另外就是通过微博舆情监测，每次影响面大一点的故障都会上微博热搜。

传统的故障处理流程是 SRE 收到客服反馈，或者收到线上 SLO 告警，手动进行故障通告，应用协同群拉起，这种传统的故障处理方式满足不了 1-5-10 的要求。因此，我们实现了故障预定义。

一个业务下支持定义多种故障场景，一个故障场景里包含了多个应用及核心场景，这些应用及核心场景都在一个规则组下，规则组会按照优先级进行告警抑制，最终同一个业务下面如果有多条 SLO 告警的话，最终只会触发一个故障。如果当前故障场景下有高等级的告警发生的话，我们会进行故障升级。

故障发生时，通过故障预定义可以提前确定故障范围及影响面，做到应急群一键拉起、自动故障通告，SRE在收到告警之后可以直接去处理故障。

故障处理过程中，SRE 会进行故障进展同步，故障的根因定位，止损的预案执行。

故障恢复后，对事故进行定级定损，组织相关业务进行故障复盘，确定一些改进项以及改进时间，持续跟进，验收完成情况，通过故障演练的方式模拟本地异常的根因，确保同类事故不会再次发生。

在 “1，5，10” 目标中最难实现的就是5分钟定位问题，那么我们的故障定位是怎么做的呢？首先通过全网可用性大盘（包含了公司的整个核心业务和重要业务），如果业务发生了可用性的下跌，卡片会飘红，我们能非常直观的看到目前故障的影响面，通过点击卡片能下钻到具体的受损业务中，业务报表分为两块，一块是应用的 SLO，另一块是核心场景的 SLO，点击异常卡片可以继续下钻，到最终的根因分析页面，通过服务指标，上下游事件变更，业务日志、全链路多维度分析，最终推荐出结果。

近期好文：

明明大厂都在裁员，为什么运维还是这么难招？