没有SLO就没有SRE？来看看B站SRE对SLO的实践总结（下）

木雁之间

本期作者武安闯哔哩哔哩业务SRE负责人2016年加入B站，深度参与B站微服务拆分、云原生改造、高可用建设、SRE转型和稳定性体系落地等业务。当前主要关注B站在线业务的SRE稳定性体系建设和推广，对SRE的实践有深入的探索与思考。01 背景在上篇文章《没有SLO就没有SRE？来看看B站SRE对SLO的实践总结（上）》中，详细介绍了我们在实践SLO体系时的思路，落地方式和遇到的问题。在没彻底理解SLO及其价值的情况下，我们就尝试建设SLO体系，走了很多弯路。反思阶段我们也认清了SLO的价值。本篇我们就来讲述我们新认知下的SLO体系建设思路。02?业务分级优化等级分级还是分为L0-L3四个级别L0：公司级核心业务，一般是公司级基础服务或公司核心业务场景，如APP推荐、视频播放、支付平台及强依赖业务等，同时需满足1.满足DAU > xx W2.满足日均营收>? xx W3.虽未达到上述要求，但业务属于公司战略级方向L1：部门级核心业务，一般是L0业务体验中依赖的主要业务、核心的二类业务，如视频播放页的一键三连功能、核心二类业务动态等L2：用户可直接使用的其他业务，如播单、分享、专栏等L3：其他后台类业务或对用户体验无影响的业务分级模型优化对业务（产品）定级创建应用（也可叫服务，下文不再区分）时，用户打标这个应用对此业务的重要程度即可：核心、重要、普通。此数据非定级使用用户只需要在创建业务时做一次业务定级即可大大简化我们的业务分级模型，不再对应用和API分级，减少大家的心智负担和运维、运营成本。03 SLI选择与计算在线业务常见的微服务调用链路如下从上述链路图中可以看出，可用率、延迟有如下两种指标应用通过SLB代理时，使用SLB Metrics计算出应用可用率、延迟等SLI：如服务A、服务B应用Server侧上报指标数据，计算出应用可用率、延迟等SLI：每个微服务都有这个指标上报，适用所有服务上篇中我们有提到，我们只度量了面向用户的公网服务。这导致我们的SLI覆盖率很低，大量的内网应用没有SLI，那SLO报警也就无从做起了。现在补充了HTTP/gRPC Server Metrics后，就能覆盖到所有应用，同时也能覆盖到所有的服务不可用场景应用访问超时，容器OOM、进程Panic等不可用，会在SLB侧上报错误指标应用HTTP CODE 200，但因依赖下游服务、读取DB、CACHE失败等系统错误时，会在应用Metrics侧上报错误指标当应用无法上报Metrics时，可以认为应用已彻底不可用除可用率、延迟指标外，应用数据层面的新鲜度指标也特别重要。当数据发生延迟时，应用Server侧并不能直接感知到数据是延迟的，要通过其对中间件的Metrics指标来度量。应用对中间件的常见依赖如下图可度量的数据新鲜度指标如下应用对消息队列服务的写入和消费延迟指标：数据消费延迟会导致用户缓存数据不更新应用所使用DB的主从同步延迟指标：数据同步延迟会导致用户缓存数据不更新Canal作为数据同步组件的同步延迟指标：数据同步延迟会导致用户缓存数据不更新多活场景下DTS组件的同步延迟指标：数据同步延迟会导致多机房DB数据不一致?3.1 应用SLI选择与计算可用率SLB Metrics度量出的应用请求错误量（HTTP 5XX）、请求成功率HTTP/gRPC Server Metrics度量出的应用请求错误量（非业务逻辑错误，如因下游依赖、DB、Cache请求失败导致的应用系统级错误，在我们的微服务框架中，这类错误code一般是-5xx）、请求成功率延迟SLB Metrics度量出的应用分位延迟HTTP/gRPC Server Metrics度量出的应用分位延迟新鲜度应用对MQ写入、消费的Metrics来度量消息延迟应用所使用DB主从同步延迟Metrics如果使用到Canal组件来更新缓存，那需要度量Canal对DB的消费延迟和对MQ的写入延迟Metrics多活场景下DTS组件的同步延迟Metrics上述Metrics以应用维度采集计算存储，在应用视角我们就能看到应用的核心SLI，基于这些SLI指标再来做可用率和新鲜度的SLO报警，报警准确率可以大大提升。假如我们已经度量了评论应用的SLI指标，当触发SLO报警时，我们知道评论应用出问题了，但并不知道是发评论还是读评论功能出问题。为了提高我们SLO的业务精度，我们需要再对业务的核心功能做度量?3.2 业务核心功能SLI选择与计算在上一篇中我们提到：应用的API是业务功能的直接体现，通过度量API的SLI就能反映出业务某个功能的情况。所以我们需要对核心API做SLI度量?3.2.1 定义业务功能在SLO系统录入业务对应的业务核心功能，如发送评论、拉取评论从API GW平台获取API信息，关联到定义的业务功能?3.2.2 API SLI选择与计算可用率SLB Metrics度量出核心API的请求错误量（HTTP 5XX）、请求成功率HTTP/gRPC Server Metrics度量出核心API的请求错误量、请求成功率延迟SLB Metrics度量出核心API的分位延迟HTTP/gRPC Server Metrics度量出核心API的分位延迟吞吐核心API每天的请求总量和单位时间的请求速率注：吞吐只在核心API上度量，不在应用上度量。因为应用有多个API，包含很多不重要的API，对用户感知很低，度量吞吐意义并不大新鲜度因为应用Server侧并不能直接感知到数据是延迟的，是通过应用对中间件的Metrics指标来度量，所以API维度并无新鲜度指标上述Metrics以API维度采集计算存储，这样在业务核心功能视角我们就能看到各种SLI指标情况，以此来了解业务功能目前的运行情况。?3.3 业务SLI选择与计算我们已经有了应用SLI、业务核心功能的SLI，难道还不够吗？为何还要建设业务SLI呢？原因如下业务核心功能SLI是从技术指标计算出来的，如发评论功能的可用率和数据延迟。前面我们有提到错误的请求是指系统依赖导致的错误而非业务逻辑错误，所以此技术指标并不能代表业务逻辑上的成功率业务SLI的核心价值是NOC/技术支持团队在Oncall时的关注指标，或构建业务场景监控时从业务指标到技术指标的下钻串联，更偏向运营层面业务指标是需要从业务系统获取，如业务DB或数仓平台。所以只能覆盖公司级核心业务指标，如点播播放：播放量、在线人数社区：发送评论量、评论弹幕量登录：平均登录量、各渠道登录量…可以看出，业务SLI其实更侧重于业务吞吐数据指标，有了这个指标后，我们可以做以下两方面的工作建设重大事故发现：当业务SLI指标异常而触发报警时，可以认为线上发生了重大事故。在很多公司，NOC团队的核心就是关注业务指标的健康度情况业务观测运营：从业务吞吐指标到业务功能技术指标再到应用技术指标，从上往下构建业务-技术全链路监控能力和可视化能力业务指标数据收集成本较高，需要按业务系统case by case来建设。我们的思路是让业务部门自建业务数据，再由SLO系统同步、汇聚、清洗后做运营大盘与报警04 SLO与报警?4.1 应用SLO应用维度我们度量了可用率、延迟、新鲜度，可设置对应的SLO如下可用率 >= 99.99%响应99分位延迟 = 99.99%响应99分为延迟