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

见贤思齐

本期作者武安闯哔哩哔哩业务SRE负责人2016年加入B站，深度参与B站微服务拆分、云原生改造、高可用建设、SRE转型和稳定性体系落地等业务。当前主要关注B站在线业务的SRE稳定性体系建设和推广，对SRE的实践有深入的探索与思考。01 背景最近几年，Google SRE在国内非常流行。Google SRE方法论中提出了SLO是SRE实践的核心，SLO为服务可靠性设定了一个目标级别，它是可靠性决策的关键因素。那如何选择和计算SLI，如何设置SLO，如何实践落地呢？本文就来讲讲B站SRE在实践SLO时所走的弯路和总结的经验。02 Google SRE中SLO的定义服务水平目标（SLO）指定了服务可靠性的目标水平。由于SLO是做出以数据为依据的可靠性决策的关键，因此它们是SRE实践的核心。上文是Google SRE《站点可靠性手册》中的原文。那为什么需要SLO呢，我们摘取原文中的核心观点：工程师稀缺，需要把时间投入到重要服务的核心问题上SLO是做出工作优先级排序和可靠性相关工作的关键SRE的核心职责不仅是自动化和处理故障，日常工作都要按照SLO来开展没有SLO，就没有SRE为了采用基于错误预算的可靠性工程方法，同样摘取原文中的核心观点：服务的利益相关方认可此SLO服务正常状态下可以达到SLO的要求组织认可错误预算并在决策中发挥作用有完善的SLO流程否则，SLO合规性成为一个KPI或报告指标，而不是决策制定工具。请记住这句话，因为我们的弯路就走到这里了。03 Google SRE中SLO的实施在《站点可靠性手册》第二章“实施SLO”中，Google详细讲述了如何实施SLO，大致流程如下：1. SLI选择对于请求驱动型服务，SLI一般选择可用性（成功响应的请求比例）、延迟、质量2. SLI计算SLI的计算可以使用应用服务器日志、负载均衡监控、黑盒监控、客户端插件等数据源一般选择负载均衡监控，因为其代表一个用户请求在整套系统所有模块处理耗时和所有网络传输耗时的总和，且和客户端插件相比，实施成本较低3. SLO定义基于计算出来的可用性、延迟数据，来定义合适的服务SLO服务可用性：例如，全年可用性 > = 99.99%服务延迟：例如，99%的请求= 99.99%，L1 API可用性>= 99.99%，L0 API 99分位延迟= 99.99%5. 错误预算我们在一开始尝试SLO时，并没有去重点建设错误预算。只是使用了基于服务分级的SLO错误量和可用性报警6. 记录SLO和错误预算我们提供了平台化能力去支持定义SLO时的审核和记录7. 仪表盘和报表API仪表盘与报表业务仪表盘与报表上面一套SLO体系建设完成以后，我们对L0、核心L1业务都做了SLO定义、SLI指标和计算。核心API和业务都具备了SLI报表能力，我们的可用性有了可视化的图表，一切似乎非常美好...但仍存在问题。05 遇到的问题1. 业务定级业务抽象认知不一，产品范围可大可小L0、核心L1业务在SRE的关注下定级基本准确，但其他业务定级就一言难尽了2. 应用定级应用数量远多于业务，定级难度更高老应用等级更新延迟于业务重构或产品迭代除L0、核心L1应用外，其他应用等级准确率低3. 接口定级?接口数量又远多于应用，定级耗时耗力，维护成本高，当时公司还没有API GW平台同上，接口等级更新延迟于业务重构或产品迭代4. SLI计算当服务因上下游调用依赖导致请求失败时，API的HTTP CODE可能是200，真实的错误被封到了业务错误码中。SLB作为通用的负载均衡，不会去解析HTTP Body这就导致一个问题：服务故障了半个小时，但今天的可用性却是100%，可用性SLI指标没受到任何影响，SLO也完全符合要求如果我们改用应用上报的Metrics（内部使用Prometheus），可以解决此问题。但当应用不可用，无法上报Metrics时，也会获取不到数据，导致SLI数据不准确我们试过推研发把业务错误码中的系统错误（调用依赖类的系统错误，而非业务逻辑错误）改为HTTP CODE，但成本极高，跟微服务的标准也不相符5. 业务SLI需要筛选出影响业务核心功能的API，这些API的SLI数据再聚合到业务，其他API的SLI数据不影响业务SLI?业务迭代导致API变更，原API SLI不再代表业务功能，导致业务SLI数据没价值6. 总结一下遇到的问题分级模型过于理想，定级成本高业务SLI关联关系、API SLI元信息更新不及时，数据准确率低无法通过一条Metrics计算到的可用性SLI来覆盖业务全部故障场景部分部门的业务只提供内网服务，不直接对用户，导致没有SLI数据SLI数据好像除了当报表外，也没什么价值最后压死我们SLO体系的稻草是一个业务需求：把业务的可用性SLI作为业务年度可用性总结报表，替代基于故障时间计算出的业务年度可用性。此需求我们认为是合理的，因为我们度量了业务可用性SLI，那算出的可用性当然可以作为业务年度总结报表来使用了。但我们在实际使用数据时遇到了一个问题：假设某业务正常情况下一天的总请求是24W，此业务某天故障了半个小时，这半个小时在未故障时的请求量是1W，故障时因为用户或链路上的重试导致接入层负载均衡收到的故障请求为2W基于请求成功率算出的当天业务可用性：( 1 - 2W / ( 24W + 1W) ) * 100% = 92%，假设此业务一年内其他时间日请求不变，每天都是100%可用性，则此业务全年可用性为：1 - (2W / ( 25W + 24W * 364))? =?99.977%基于故障时间算出的当天业务可用性为：( 1 - 0.5 / 24 ) * 100% = 97.916%，假设此业务全年其他时间每天都是100%的可用性，则此业务全年可用性为：( 1 - 0.5 / 24 / 365 ) * 100% =?99.994%可以看出，两种计算方式得出的可用性差距极大。为了解决这个问题，我们想到了一种数据补偿机制：基于故障时段的同环比数据对故障损失数据去重，尽量向故障时间数据靠齐。去重后基于请求成功率数据结果为：忽略重试增加的1W请求量，则当天业务可用性：( 1 - 1W /? 24W ) * 100% = 95.833%，假设此业务一年内其他时间日请求不变，每天都是100%可用性，则此业务全年可用性为：1 - (1W / ( 24 * 365))? =?99.988%此方式虽然依旧无法跟基于故障时间的可用性数据对齐，但已经非常接近了，我们认为加上了数据补偿机制之后，统一用这个计算标准的话，业务的可用性SLI是可以作为业务年度可用性报表使用的。想法又一次非常美好...实际运作起来时，我们发现成本太高了。当发生了影响业务核心功能的事故，我们就要对故障数据去重，然后修订故障当天的SLI数据。需要有人去盯着事故报告的损失，跟研发一起核对损失数据，再修订SLI数据.....最终，因为我们执着于提升SLI的准确率，导致整个SLO系统无法运转......此时我们的SLO体系开始停滞和崩溃.....06 反思我们开始反思问题出在了哪里，SLO的价值到底是什么？SLI度量的对象到底是什么？是业务吗，还是应用？Google 基于错误预算做了消耗率报警，我们的SLO除了做报表外好像没啥价值？想清楚这些问题后我们才意识到之前为什么走偏了。SLO是可靠性决策的关键因素，但不是非有不可在没有SLO、SLI之前，我想大家的稳定性工作也能分的清楚优先级，比如基于事故复盘来决策高可用工作方向，如服务降级、熔断、中间件高可用、多活容灾等SLO的价值绝对不是报表，而是及时报警，发现影响SLI指标的异常SRE中有一章专门讲基于SLO的报警，但在我们的实践中却忽略了这个方向，执着于提升SLI指标的准确率应用每天都有无数的报警通知，如CPU、内存、磁盘、调用超时、请求错误、请求重试等，产生了大量噪音。但哪些报警会影响到可用性SLI需要SRE和研发关注呢？我想这就是SLO的核心价值之一了错误预算策略是诗与远方如果业务某个季度发生事故，把这个季度的错误预算耗尽，SLO已不符合预期，SRE也不能冻结这个业务的变更至于调整业务团队的短期目标，从业务迭代转到专注于可靠性问题还是可以的。但这个目标一般是事故驱动达成的共识如果让国内互联网公司产品迭代停止三个月，我想没有哪个公司会同意SLI度量的核心是业务功能和应用，而不是聚合业务SLIAPI是业务功能的直接体现，通过度量API的SLI就能反映出业务某个功能的情况业务功能不可能全部枚举出来，接口也不可能全部定级和计算SLI。但应用是有限且标准的，基于应用的Metrics即可算出所有应用的可用性SLI业务核心功能的SLI通过API SLI已度量出来，是否要聚合成一条代表业务SLI的指标其实并不重要。比如在业务报表页面展示业务多个功能的API SLI数据可能会更直观业务SLI的核心价值是NOC/技术支持团队在Oncall时的关注指标，或构建业务场景监控时从业务指标到技术指标的下钻串联，更偏向运营层面07 总结本文详细介绍了我们在实践SLO体系时的思路、落地方法以及遇到的问题。我们在没彻底理解SLO及其价值的情况下，就尝试建设SLO体系，走了很多弯路，反思阶段我们也认清了SLO的价值。下一篇会讲述在新认知下的SLO体系建设思路，敬请期待～往期回顾：2021.07.13 我们是这样崩的