SLO是SRE中提出的一个工程理论，指出SLO指定了服务可靠性的目标水平，是做出数据决策的一个关键指标，也是SRE的核心。

【资料图】

结合SRE中的可靠性工程，B站也落地了自己的一整套实践体系，如下图所示，最上方是我们跟研发的协作体系，研发可以看到SRE的几种角色，比如Oncall轮值、核心业务BP、PaaS平台专家以及专门负责可靠性工程开发的SRE。可靠性工程中对服务的质量运营就是通过SLO工程驱动的可观测、变更管理和报警治理。

可用性的指向对象很多，因此我们可能不清楚可用性的具体内容。实际上，可用性的度量可以是生产运行的一个服务或应用、应用下的某一个接口、某一个业务模块、某个团队或部门。

度量可用性其实很难，首先我们要解决“什么是不可用”的问题。怎样的请求属于失败，需要提前制定标准，比如一个请求失败是不可用，或一分钟内错误率超过某个阈值是不可用，由此才能推动后续实践。

传统的可用性度量大多是基于故障的度量，如mttr指标。但可用性的事故报告召回低，只有出现严重事故，才会生成故障报告。对于服务的某些短时间抖动，我们一般不会通过数据报告的方式复盘。

可用性的数据还应用于运营的场景。常见的运营需求包括报警能不能基于可用性完成；若出现生产故障，可用性损失的数据能否自动产出，是否需要产出年度、月度或季度的可用性报表。

随着微服务体系发展，指标和报警的数量攀升。当SRE针对具体问题进行故障排查时，由于指标过于丰富，我们容易不清楚排查重点或排查顺序。除此之外，每次出现事故都会加报警，导致难以区分报警工单和巡检，最终从报警的通道推送出来的基本都是噪音。

报警存在分层，IAAS、中间件、应用、业务、终端等层面都有指标，因此通知数量高达几万条。为了保证通知到位，各项通知逐渐趋于高速度、高频率，通知内卷化严重。

先看一下整个SLO的方法论，这个方法论比较简单。

SLO指定了服务可靠性的目标水平，是做出可靠性决策的关键数据，也是SRE实践的核心。

对于一些常见的SLO模型，SRE也给了一个例子，是一个名为VALET的模型，对应了5条指标，即容量、可能性、延迟、错误和工单。

在SRE中，一个实施SLO的理想流程如下：

首先，选择指标。以可用性为例，若指标属于请求驱动型，那么成功响应的请求比例除以总的请求，即可得到可用性量化指标。此外，该指标还能够度量服务请求的延迟与请求的质量。

其次，定义错误。比如，HTTP 500、504、503是错误，或404、429、403是错误？

最后，度量数据。通过应用的服务器日志、负载均衡或客户端进行度量时，SRE里推荐选择负载均衡度量，因为这一层的度量成本与客户端相较更低，并且可以度量从负载均衡到服务内部所有链路的数据。

数据度量完成后，即可进行SLO的定义，其具体做法与SLI类似。

即基于你的SLI指标，得出时间窗口内的允许错误预算。例如，可用性全年是99.99%，那么基于一年的时间窗口就可得知一年内99.99%的SLO允许的不可用时间是52分钟。

当错误预算消耗殆尽时，可以制定一个策略，比如要求研发冻结生产系统的日常迭代，除非研发要做紧急的bug修复，或需要优化生产的稳定性。

最后，需要一个仪表盘和报表来完成数据的展示和可视化，并持续改进SLO。

我们在2019年做了第一次尝试，按照这套体系去做整个SLO体系的度量和元信息的关联。当时的目标是做一个非常准确的度量数据，这个数据需要体现线上服务真实的可用性指标，比如能体现它全年的可用性是多少，同时也能及时发现线上的问题。但在实践了大半年或一年左右之后，这套逻辑就难以为继。

反思以上问题后，我们重新构建整个SLO生命周期的体系逻辑。

做指标度量，设置SLO，增加指标治理的步骤，提升指标的准确率。指标治理完成后，度量可用率、数据延迟和业务指标，使SRE和研发具备一致的观测能力。

基于这些指标做SLO的告警，将其与传统的告警区分，务必提供一个精确高效、透明分发的渠道。

保留错误预算，但将其与SLO报警相结合，用于找出服务故障的共性因素，并与研发共同进行稳定性的治理。

做报表和仪表盘，使业务能综合观察到日、周、月、季、年的历史可用率报表，能看到错误预算消耗，包括可用率的排名等内容。

建立整个SLO的生态数据，一定要把SLO的指标扩展到上层的使用平台，比如CI、CD、压测平台或内部的多活管控平台。只要是服务变更的核心平台，就可以把服务SLO的指标扩展到平台上，使研发在平台中就能看到服务实时的可用性指标，也可以用这个指标完成变更预检、发布观测、智能阻断等。

整个模式建立在CMDB元信息、微服务框架、可观测能力、报警中心、事件中心以及AIOps能力的基础上。

进行指标可用性的度量最常见的两种模式：一是度量请求成功率，二是度量服务的可用时间。

请求成功率：只要定义什么是错误，就能知道错误率，从而就能得出请求成功率。它的计算非常简单，你只要找出错误的code，再做治理，最后统计出错误code即可。

可用时间：这个计算会更为复杂，首先要度量什么是不可用时间。比如，一分钟服务的错误率大于20%时，就认定这一分钟不可用，那么统计出不可用的时间，算出总时间，即可得到服务的可用性。

根据我们之前的实践经验，对以上两种方式的选择主要考虑指标的准确度。哪个指标有价值，哪个指标能发现线上问题，哪个指标对业务价值大，就用哪个指标。而对报警的精确度来说，基于时间的统计方式的错误率是固定的，错误率不达标也不代表用户不受影响，所以通常会选择基于请求成功率。线上问题发现率的统计也是基于请求成功率，这对业务价值最大。

运用请求成功率最核心的一点就是要完成错误的标准化和错误的识别。

在一个网络链路中，会出现很多错误。比如，基于TCP/HTTP的一个简单模型来看，Client发SYN包的时候，Server有可能遇到网络不可查或者网络超时等情况，然后Client会发送SYN Retry。当把数据包发过去之后，对端的端口可能挂了，数据包也会Reset。

例如，在读缓存或者读DB这些强依赖或者依赖一个下游服务不可用时，服务会出现请求正确性的错误，虽然在一定的时间内将请求处理完毕，但相应的数据出现错误。

因此在这条链路中，基于Client和Server的视角都可能出现不同类别的错误。不管是基于SLB的Client的视角，还是基于服务上下游调用的Client的视角，对下游服务的熔断、下游服务网络不可达、下游服务应用无响应或者响应超时，以及下游服务虽响应但返回了一个错误的内容等这些情况，都是不可用的场景。

而基于Server的视角，只有这种场景能通过Server的视角度量出来：Server返回请求，但请求返回的是错误内容，如业务错误code码。

SLB视角：HTTP 5xx

当错误的类型定义清楚后，就要定义我们的Code码，而从负载均衡的视角来看，比如说我们的基本是5xx。

Server视角：业务Code -5xx

我们参考HTTP 5xx对业务的Code码做了一个-5xx的定义，比如服务内部错误，导致内部业务逻辑无法处理，会把错误return出来，一般会出现一个-500或-504。

如果因为调用下游服务超时而导致整个链路的耗时消耗完毕，服务无法处理，会抛一个-504；如果服务接了限流的框架，限流时会抛一个-509。

Client视角：业务Code -5xx

最终对服务的度量集中在两个维度：

从SLB的层面看负载均衡中所上报的服务的5xx错误量、服务的QPS以及服务的耗时。SLB层面若产生了5xx的Code码，那就代表应用访问超时、容器OOM或者进程Panic等不可用，这都是一些非常严重的故障。

另一层面是在服务本身的Metrics层面上报。我们的服务可能分为HTTP的协议和gRPC的协议，不同的协议可能是不同的Metrics，所以最终会在SLB层面去度量SLO，然后在服务层面度量HTTP和gRPC的请求。

我们在度量服务本身的Metrics时，发现它出现了一些-5xx的Code码，这个对应的场景就是应用HTTP Code 200，但因依赖下游服务、读取DB、CACHE失败等系统错误时，则会在应用Metrics侧上报业务Code的错误指标。

通过这两种指标的度量，就能度量出服务所有的故障场景。

除了可用性的度量外，我们还对服务的延迟指标做了度量，此延迟所指的不是接口的延迟，而是存储和数据层面的延迟。因为我们做了同城双活，同城双活中有很多数据同步的场景，比如数据库的同步和缓存的同步等。数据若产生延迟，将严重影响用户体验。

技术指标有时无法发现业务指标层面的问题和故障。

我们以前遇到过一些案例：如用户频繁掉登录，最后发现是APP上误踢登录；还有用户充值失败，最后发现是业务逻辑的bug。

最终我们的度量方式是多对象，多SLI指标，多SLI实现。

度量对象的第一层级就是业务，业务通过大数据的一些流式实时计算以及数据库的Binlog来做度量，它用于度量在线人数、播放量、评论、弹幕、登录和营收等指标。

我们还度量了业务的某些核心功能。例如，无论是发弹幕评论还是登录，都有对应的服务端的API，它面向用户侧的公网访问。我们会把这些API度量出来，然后通过服务端的技术指标来观察这些功能的可能性。因为业务指标的度量更多是一个吞吐量的变化，通过服务端的技术指标对这些接口做度量，观察公网接口，最终将成功或失败的结果反馈给用户，由此能度量出核心功能的可用性。

生产系统中有成千上万的API，不可能度量出所有的API，所以我们有一个兜底策略，即对所有的应用都使用这套可用性的度量指标。针对接口，我们可能会在SLB、API GW这种偏外网的入口层面做接口的度量，应用方面则会在Promethues埋点，同时也会度量它用到的存储组件的延迟指标。在实践中，我们发现技术指标召回的问题远远大于业务指标召回的问题，因为业务指标一旦产生问题，就代表生产已经发生了非常明显的故障。

由于不是每一个服务都直接对用户提供公网功能，很多服务可能时内网服务，或是下游依赖的服务，产生不可用问题的时候就会被SLO发现，同时发出告警。但最终用户可能没有感知，因为上游链路很长，很有可能在某一个链路就被熔断或者被降级，所以服务的故障不代表最终用户的故障，服务维度的技术指标所召回的问题远远大于业务指标召回的问题。

前文也提到了告警的问题，例如，每次出事故都加告警、报警狼来了、全是噪音以及报警准确率低等，令人无从下手……问题在哪？我们在做SLO告警时慢慢发现了根因。

做故障复盘时之所以要加告警，是因为发现这个服务的CPU产生抖动、服务磁盘的使用率过高、磁盘满了都会导致服务出异常。每一个因最终都有可能影响服务的稳定性，但是SLO是真正代表服务的可用性的指标，它是一个果，只要你有了这个果，就能做到兜底，无需再加各种因。

我们以往的报警没有区分系统错误和业务错误，也没有清晰定义出研发需要关注的错误，导致每天可能有几万条报警，研发难以一一查看。如果Code码不是200就报警，那么这种报警就没有任何意义。

最终我们以SLO告警作为核心，规划新的报警治理。

研发只需要关注应用告警，包括SLO的告警和影响SLO的常见因素，最常见的三种是依赖错误、中间件异常、容量。我们可以通过HPA的策略解决容量问题，比如全部覆盖HPA，在CPU超过50%或者60%的扩容情况下，就不会每天收到大量报警。

以数据库不可用为例，以往研发可能会收到业务的数据库不可用的告警，或者缓存。如果产生了主从切换，或缓存的某一个节点宕机，研发可能会收到业务用到某一个缓存不可用而宕机的告警，但是现在的思路则是，研发无需再关注中间件层面的告警，只需通过自己应用侧埋点的指标就可以发现中间件的问题。

服务可以上报对缓存的一个依赖指标，它会上报出对缓存的每一次请求是否成功，耗时多少等情况。如果缓存出现问题，按业务指标直接上报出来即可。如果缓存发生了主从切换，但是最终对服务的SLO没有任何影响，那么研发完全可以无视这个事件。同时，难免有些业务未能达成此类最佳实践，研发也可以按需去订阅下层的告警。

在设置SLO告警时，需要精确的计算逻辑避免无效告警。这方面我们使用了SRE中提到的错误预算窗口、消耗率、多消耗率报警及多窗口的计算策略。

传统的分发和协同一般通过短信或者IM工具，比如钉钉、企业微信等渠道。并且传统的报警都是面向于某一个应用，发送给权限人，但由于元信息平台人员的权限一般不会因为组织架构调整或者是研发的职责调整而出现变更，所以难以精确识别出关注应用告警的研发人员。比如，一个服务产生问题，可能收到报警的有三四十人，其中真正关心服务的人员可能只有两三个。

我们做了一个智能诊断的平台，结合可观测，使研发能够在5分钟内定位问题。

导出SLO告警的数据，分析每个团队的处理效率。结合研发反馈的告警有效性，将这些数据用于运营分析，以此了解告警的预算消耗、告警触发的原因。告警准确率高、低噪音、故障高召回、智能快速诊断、公开透明、高效协同是这一套机制运转下去的前提。

SRE提出了两个概念，第一个概念是错误预算，第二个是消耗率。

错误预算对风险识别、故障定级和稳定性决策十分重要。如果要做变更，比如生产要做网络割接、或某个服务要变更维护，一定会对服务产生影响。过去对服务的严重程度是以时间来度量，现在转而查看它会消耗多少的错误预算。

基于你制定的SLO（包括错误预算和消耗率）制定报警策略，若目标错误率大于SLO，就可以告警。

缺点：假如这个服务每时每刻的错误率刚好都是0.1%，若一分钟报警一次，一天能报1440次，但这个服务的可用率刚好还是99.9%，满足SLO的要求。

增加时间窗口。例如，报警策略是消耗30天的窗口的5%，即36小时，把36小时的错误预算消耗完毕后，再发出一条告警。这种告警也不太合适，原因有二，其一，假设以一个36小时的窗口来做计算，那么报警触发后，在36小时的滑动窗口的一段时间内，会持续发出告警；其二，假如错误率刚好是0.1%，刚好是SLO阈值的临界点，那么就要达到36小时才能触发告警。

可以增加单个报警的持续时间，比如SLO低于阈值10分钟之后发出告警，或者低于SLO阈值一小时后发出告警。

缺点：不论服务是100%不可用，还是0.1%不可用，都是在10分钟后发出告警，报警的灵敏度与服务的错误率无关。针对此问题，SRE提出了消耗率的概念。

严重故障：1小时消耗月度2％(14.4h)的预算消耗，发出紧急报警。

轻微故障：6小时消耗月度5％(36h)的错误预算，发出紧急报警。

兜底策略：3天消耗月度10％(3d)的预算，发出故障工单。

以一小时的窗口做报警计算为例，若5分钟时错误已经告警，那么接下来的55分钟也会继续发出告警。因此这个策略增加另一个窗口，在报警和恢复时检查是否仍然达到错误预算消耗速率。

这需要两个条件，一是必须把一个小时的错误预算消耗完毕，二是在接下来检测的时间窗口内错误率仍很高，应对的场景是服务的可用率马上归零，又马上恢复。这种场景下报警可立即触发，并立即恢复。

由于错误预算和消耗率理解起来太复杂，所以用时间窗口、可用率和错误量的概念替代错误预算和消耗率。我们将服务进行线上分级，按照服务的等级分梯度设置报警条件，紧急窗口用于发现严重事故，非紧急的窗口用于处理一些低速流血的问题。

比如，紧急窗口用于发现服务的平均可用率低于某个值，同时错误量最近一分钟大于某个值，这就是紧急的报警窗口。非紧急窗口是指服务一天的可用性刚好低于SLO，制定好报警策略后，此时报警能够发现线上的紧急问题和非紧急问题。

我们借助事件中心的分发能力，重新做了一套告警分发协同的机制。

这种方式可以实现对人员的精确识别，并拥有一个高质量的协同群渠道。整个报警采取公开、透明、协同的处理方式，补充了传统报警方式缺失的能力。但需要注意，不能用一些误报率很高的报警运行这套机制，这种低质量的告警推送到群内会产生刷屏现象。

步骤如下：

在我们的场景中，只垂直做服务的故障，就会发现根因定位边界很清晰。基于业务指标、应用指标、中间件指标以及服务的容量指标，就可以发现服务的故障点。因此，我们只需要做故障定界，无需立刻定位服务的根因。在当前的微服务架构下，只要知道服务故障点的位置，就可立刻止损。

我们在群里推出了一条SLO的告警，并在告警卡片里会推送一个SLO的诊断链接，然后直接@服务所负责的或做过变更的研发。研发直接点开链接就可以快速地做故障的定界，确认接口和服务的错误类型。

在根因分析方面，我们会观察它依赖的资源、依赖的下游服务或者依赖的中间件，使研发能快速得知具体的服务故障点。故障定界后，研发做止损，最后服务恢复，完成故障修复。针对SLO的故障场景，上文提到用于生产的实际模型，可以达成1分钟报警、研发5分钟完成故障定界两个目标。

只要把告警发到群里，研发都会处理，因为告警非常准确，一旦发生就代表服务出问题。与研发唯一的分歧是SLO告警出来后表示服务不可用，但是这个服务没那么重要，研发会基于上游容忍自己服务错误的原因，将其判断为误报。

这种场景下报警仍然准确，但需要抑制服务的一些报警条件或者触发条件，降低敏感度。

要建设整个SLO的生态，就要把SLO与变更检测相结合。我们把实时的SLO指标如可用率、错误、QPS、延迟SLO扩展到容器平台之类的上层平台，服务在发布和变更时集成了SLO的指标大盘，研发可以实时看到自己服务的可用率和错误量。在多活的管控平台中，多活切量时也有服务SLO指标的观测，我们可以用这些指标做变更的预检，观察服务整体的健康情况。

在发布中也可以做观测和智能阻断，一旦发现服务的指标出现了可用性的下跌，可以智能阻断该次变更。

Q1: BiliBili是度量了每个服务的SLO吗？

A1：对，我们度量的对象有三种，第一是业务，第二是通过API来度量业务的某一个功能，第三是使用这套指标针对每个服务做一个度量。因为生产的API非常多，不可能把所有API都度量出来。面对服务没有任何指标的情况，就无法进行度量，但只要有指标就可以度量出来。

Q2: 如果想度量一个系统的可用率，这个系统由50个微服务组成，是取平均值吗？

A2：不是的，取平均值并无意义。首先要看是中间件还是一个业务系统。假设是一个业务系统，比如登录系统，里面可能有10个微服务，可以把登录相关的核心接口定义出来，用它们的可用率度量这个登录系统的可用率，把所有的错误量、请求量全部相加，累加之后再去算整体的可用率，而不应该取平均值。因为如果服务某一个功能的可用率很低，平均之后这个数据就会失真。

比如有一个服务每天的请求量是1万，今天的可用率只有90%，另一个服务每天的请求量可能只有100，这两个数据一旦平均，数据失真就会特别严重，所以不建议取平均值。

Q3: oncall人员会收到所有的告警吗，若收不到，有问题无法触发oncall人员，如果收又会被告警轰炸，这种情况怎么办？

A3：首先告警体系本身是分级的，处在不同层级的人关注的告警不一样。例如存储中间件的同学会关注中间件的指标，SRE可能会关注应用的指标，也会关注部分中间件的指标，而研发关注的也是应用本身的指标和部分中间件的指标，相关人员需要接收自己有权限的服务报警。

至于告警轰炸问题，传统的告警加的是因。只要这个指标的波动有可能影响服务的可用性，我们就会添加一堆告警，这种情况下属于告警轰炸。但如果能把服务的SLO指标清晰定义并度量出来，用这个指标做报警，由此很多基于因的报警都可以慢慢下线。

Q4:这套体系是否只针对业务开发，对SRE 有没有告警降噪的案例？

A4：不是的，这套体系针对业务开发和SRE，双方共同关注告警。至于告警降噪的案例，我们这套告警上线后，对应用的其他告警做了策略的调整，包括告警的下线。比方说有一个APP接了限流框架，触发限流的告警，每天的告警数量可能有几万条。SLO告警上线后，我直接取消了这个告警。因为服务触发限流之后，只要达到一定的错误率，就会被SLO报警所触发，然后按照企微协同，再到SLO的根因定位的一套机制处理限流告警，所以无需一些基于因的度量告警。

Q5:线上压测流量、测试用户的误告怎么处理？

A5：测试用户可以通过生产一种灰度或者染色的方式来处理，即对用户流量做一些打标。我们可以在指标上报的时候加上这种标签，这个操作在我们的系统种称为染色，这个请求带有一个颜色标签，那么在它的指标中，染色的标签可以识别并被上报。

我们在测试环境做SLO指标度量和报警的时候，就不会再看染色的流量，而是只看基准版本的流量。如果生产的问题很严重，可以用类似的方式，即只看你基准版本的流量，不看染色的流量，或者将两个流量的报警场景区分开。

Q6:如何探测SLO是否已经达到阈值？

A6：SLO的计算本质上还是通过Promethues计算，只是报警触发的窗口即错误预算窗口和消耗率这两个概念太难理解，所以我们换成了一个服务的可用率加一个计算的时间窗口，本质还是Promethues来做计算。

Q7:刚开始进行SLO建设，如何说服研发团队配合?

A7：我们内部也经常遇到这种场景，这个部门出现了一个事故，但没有报警，就会问能不能用SLO告警覆盖，感觉SLO是万能的，然后我们就找研发团队去聊如何做SLO告警。其实它的前提是首先要定义你的SLI指标，要看这个业务系统要度量什么。对在线服务来说，可用率是最核心的度量指标。但可用率这个指标怎么度量，有哪些上报的指标可以度量出来？举个例子，可以通过负载均衡的指标来度量，服务如果没有接Promethues的埋点SDK，就无法通过服务度量。但服务会打日志，可以通过日志来度量。本质来说还是要有指标，这是第一步。第二步，指标一定要能呈现并上报服务产生的错误。

只要满足这两个条件，就能做这套系统。它需要服务标准和微服务框架的配合，微服务框架中要有这套指标和错误，然后才能度量出一个非常精确的SLO系统。其实研发的配合就是在第一步做指标治理这一方面，后续整个运营机制主要由SRE来建设。这套系统对研发来说，能帮助他发现现象问题，且报警非常准确，能让他快速定位线下问题，这样他一定会主动配合你使用这套系统。

Q8:怎么解决抖动告警？比如每隔几分钟 5xx错误？

A8：这也是一个很常见的生产的报警模式，分两种情况看，一种情况是报警很严重，服务已经不可用，必须处理。

另一种情况就是你可以容忍服务短时间内一个5xx，因为这个服务最近可用性很不好，研发和我们都知道。那可以调整报警策略，抑制每几分钟产生5xx的条件，比如可以把报警窗口放大，把5分钟的窗口放大到10分钟的窗口，5分钟的可用率存99.9%，你可以把它降为99%，通过新的报警策略去抑制它。

还有一个方法是先静默一段时间，服务最近的可能性下跌是一个已知的事实，等把服务的可能性优化之后，再打开报警窗口。

Q9:收到告警之后如何知道具体是哪个错误造成的？

A9：可以通过故障定界实现。SLO告警本身只是告警，所以必须与SLO的诊断、可观测相结合。因为可观测观测的是因，它就是用于发现服务的哪些指标产生了波动，这些指标可能会影响服务的可用性。但可观测并没有告知结果，并没有告诉你服务的可用性下跌，这就是可观测和SLO的区别。

可观测帮助找出原因，SLO让我们知道结果，所以SRE里面第二本书的第四章，提及SLO报警的时候，介绍了一个实践：你有一个SLO的大盘，这个大盘使你得知服务的SLO产生影响，接下来应该告诉研发，服务的黄金指标有哪些，并基于可观测做成一个大盘，那么这个大盘就可以让研发在收到告警之后，快速定位错误的原因，做故障的定界。

武安闯

哔哩哔哩 SRE负责人

先后负责中间件运维、在线业务保障和SRE稳定性工程，《2021.07.13 我们是这样崩的》文章作者。从0到1带领运维向SRE转型，建设B站稳定性体系，主导建设SRE转型、SLO工程、容量管理体系、高可用架构、多活容灾等专项，当前专注于SRE稳定性体系规划建设和落地实践。