开发者社区 > 博文 > 11.11大促背后的技术保障:SLA与SLO的深度解析与实践案例
分享
  • 打开微信扫码分享

  • 点击前往QQ分享

  • 点击前往微博分享

  • 点击复制链接

11.11大促背后的技术保障:SLA与SLO的深度解析与实践案例

  • fe****
  • 2024-11-27
  • IP归属:北京
  • 100浏览

    背景

    又到一年的11.11大促日,最近很多团队邮件上下游确认SLA,你是不是还没搞明白服务质量SLA、SLO等概念?本文通过理论知识以及基于SLO告警治理的实践经验分享。详细介绍如何设置SLO、有效的告警泛滥治理、以及如何根据SLO的指标来优化服务性能和可靠性。

    问题(1)

    首次接触到了SLA(服务等级协议)的概念,其中承诺的响应时间是200毫秒。而服务接口的TP99(即99%的请求完成时间)超过了100毫秒,上游的超时配置却是2000毫秒。这之间存在何种联系呢?我感到有些困惑。后来在工作中逐步搞清楚了SLA的概念。

    问题(2)

    年初还有一个疑问一直困扰着我。例如,我负责的系统中的一个API接口的可用率是99.99%,那么在部门中,包含了N个系统和M个接口,部门的季度可用率是99.98%,这个数字又是如何计算出来的呢?统计的规则又是什么?我请教了XXX同学,给我解惑答疑,非常感谢!

    问题(3)

    比如我在XXX云购买了100台云主机,在10:00-10:05这5分钟内,有10台机器出现故障,导致API的对外可用率只有90%(在这5分钟内,总请求数为1万,失败的请求数为1000)。如果一个月30天,每天发生一次这样的5分钟,那么这可用率到底是多少呢?


    带着以上的这些问题,研究了服务质量的指标:SLI(服务水平指标)、SLO(服务水平目标)和SLA(服务等级协议)。如果你也对上面的问题感兴趣,并且想找到答案,欢迎阅读本文,以下是我的研究成果,供大家参考,如果有不对的地方,还请大家指正。

    一、服务质量术语

    如果你不了解你负责的系统内部的各种行为的重要程度,并且无法度量这些行为是否正确的话,就无法正确的去运维系统,更不用说稳定可靠的运维了。不管是对外服务还是内部API,都需要制定一个针对用户的服务质量目标,并且努力去达到这个目标。

    在这个过程中,我们需要根据历史经验,主观判断以及对服务的理解来定义一些 服务质量指标(SLI),服务质量目标(SLO),服务质量协议(SLA)以及这些指标的预期值和应对计划。

    1)服务质量指标SLI(Service Level Indicator)

    定义:该服务的某项服务质量的一个具体量化指标

    常见的SLI包括:

    1. 可用率(成功响应的请求比例)
    2. 请求延迟的99%(TP99请求处理耗时)
    3. 吞吐量(每秒请求量)
    4. 持久性(数据能够保存的完整时间,常用于数据存储系统)

    2)服务质量目标SLO(Service Level Objective)

    定义:服务的某个SLI的目标值或者目标范围。

    SLO的定义是SLI《目标值,或者 范围下限《SLI《范围上限。

    设置服务水平目标(SLO)的好处主要体现在以下几个方面:

    1. 对于客户端而言,SLO提供了一种可预期的服务质量,这使得客户端的系统设计可以更加简单和稳定。客户可以根据SLO来规划和调整自己的业务流程,减少不确定性带来的影响。
    2. 对于服务提供者而言,SLO带来的好处包括:
      1. 可预期的服务质量:SLO可以帮助服务提供者明确服务质量的标准和目标,从而更好地管理和优化服务。
      2. 更好的成本/收益取舍:通过设定合理的SLO,服务提供者可以在资源投入和服务质量之间找到一个平衡点,实现更有效的资源利用和成本控制。
      3. 更好的风险控制:当资源受限或出现故障时,SLO可以帮助服务提供者更好地控制风险,避免服务质量下降对业务造成的影响。
      4. 故障时更快的反应和采取正确措施:SLO可以作为一个参考标准,帮助服务提供者在故障发生时更快地发现问题并采取正确的措施,减少故障恢复时间。

    选择一个合适的SLO是非常复杂的过程,难点是可能无法确定一个具体的值。比如对外API,每秒查询数量QPS指标由用户决定的,我们并不能针对这个指标设置一个SLO。但是我们可以指定请求TP99时间小于20ms.确定这个目标可以鼓励开发者优化代码性能.


    3)服务质量协议SLA(Service Level Agreement

    定义:指服务和用户之间的一个明确的,或者不明确的协议。描述了在达到或者没有达到SLO之后的后果。这些后果可以是财务的(赔偿)或者其他的。

    区别SLO和SLA的一个简单方法是问:“如果SLO没有达到时,有什么后果?”,如果没有定义明确的后果。那么我们肯定是在讨论一个SLO,而不是SLA。

    Google搜索服务是没有公开SLA的一个典型服务。

    4)云服务级别协议CSLA(Cloud Service Level Agreement

    详见第三章节


    二、SLO实践案例

    我们可以SLO实践案例来指导我们的稳定性建设。

    1)服务分级&核心接口分级

    分级规则

    1、根据业务影响,应用分为0-3级

    2、应用里面的接口再次细分0/1级,因为很多历史原因,很多0/1级系统内部N个接口,但M个接口是非核心的。或者2级应用里面有N个0级接口。关注核心接口的健壮性(是否可用率治理完成,是否可降级,是否配置合理的限流值)

    分级用途

    • 基于服务等级,要求核心服务遵守对应标准(比如代码评审,上线发布,变更流程,大促管控)。
    • 报警基于服务等级来做分级
    • 不同等级稳定性要求SLO不一样,如具备熔断降级能力等。

    注意事项

    1、全链路应用定级不统一:比如整个链路既有0级应用,也有1级别应用,还会存在很多3级应用

    解决方案:推动下游更新应用等级

    如下图,通过工具扫描0/1级依赖的下游等级应用是3级,

    2、接口定级不统一:比如某个历史接口,A部门从自身角度出发认为接口不重要,但上游,上游强依赖,有时候出现线上故障后才知道该接口的重要性

    解决方案:需要链路追踪,从用户视角(用户购物、物流一线操作业务)看影响,但这个有时候挺难的,尤其是历史接口,链路太长

    3、接口可用率不准确:比如内部异常被catch吃掉了,没有反应到接口最外层,比如服务故障了半个小时,但ump可用率还是100%

    解决方案:进行代码可用率治理,让API可用率是真实的。

    2)SLI实践应用

    选择能代表业务核心功能的API,按上面的业务分级模型对这些API定级,一般只度量L0、L1等级的业务和其接口。那么应该定义哪些指标?为什么定义这些指标?这些指标是服务最重要吗?

    比如UMP打点监控指标有:

    1)方法性能:TP50,TP90,TP99,TP999,TP9999,MIN,MAX,AVG

    2)方法可用率

    3)方法调用次数

    这些监控指标我们都需要作为SLI吗?答案肯定不是。只有理解用户对系统的真实需求才能真正决定哪些指标是否有用。指标太多会影响重要的指标,指标太少又会导致重要的行为被忽略。一般来说,3-5个具有代表性的指标对系统健康度的评估和关注足够了。

    根据常见的服务SLI分为如下几类

    类别
    描述
    SLI类型
    API服务
    比如时效下传控制
    可用性(能否正常处理请求,请求成功率)
    延迟(请求花费的时间是多少,一般关注TP99,黄金链路关注TP999、TP9999)
    吞吐量(可以处理多少请求)
    限流(是否可以限流,配置多少限流)
    降级(服务是否可以降级)
    消息队列
    比如JMQ
    吞吐量(处理了多少数据)
    延迟(数据从生产到消费需要多少时间)
    限流(是否可以限流,配置多少限流)
    存储量(消息可以存储量积压多少)
    存储服务
    比如mysql
    延迟(读写数据需要多少时间)
    可用性(是否可以随时访问数据)
    数据持久性(数据能保留多久)

    3)SLO实践应用

    我们应该从用户最关心的方面入手,而不是目前可以监控度量什么着手(当然目前UMP监控度量的维度已经很多,部分指标可作为SLI)。制定适当的SLO的第一步是讨论SLO应该是什么以及应该涵盖什么。SLO为服务的客户设置了目标可靠性级别。

    为了更清晰的定义,SLO应该具体支持他们是如何被度量的,以及其有效条件。例如:99%(在1分钟时间范围内的请求汇总)的JSF-API调用会在200ms内完成(包括全部后端服务器)

    服务名称
    业务描述
    接口名称
    TP99
    可用率
    吞吐量
    限流
    XXXXXXXXcom.jd.*.*.*
    200ms
    99.95%
    5W/s
    5W/s

    选择目标SLO策略建议

    1. 不要追求完美:不要以当前的运行状态为基础选择目标,而应该从全局触发,刚开始可以制定一个宽松的目标(前提满足用户),逐步收紧。比如目前API的TP99是8ms,对外SLO的TP99是10ms,如果后期接口内部逻辑改造,需求变更等导致API的tp99是20ms,则不满足SLO。
    2. 留出一定的安全区:对内使用更高的SLO,对外使用稍低的SLO。这样可以留出一些空间来响应需求等。缓冲区buffer可以保护我们不会对用户产生直接影响。

    您第一次尝试SLI和SLO不一定正确。最重要的目标是进行适当的测量并建立反馈环路,以便您进行改进。随着SLA的变更,系统架构不断的迭代演变(比如之前SLA的TP99是1000ms,你采用mysql架构存储数据,后面变成面向20ms,这时候的mysql架构就不适合了,需要演变为比如redis缓存等形式)

    4)SLA实践应用

    研发需要和业务产品同事综合考虑,目前内部通过邮件达成协议。外部云厂商则通过合同达成协议(保护未达到SLO的补偿条款)

    三、云服务协议(可跳过)

    对本章节内容不感兴趣的,可跳过

    1)国家标准:信息技术 云计算 云服务级别协议基本要求


    2)京东云主机服务等级协议(SLA)

    3)阿里云服务器 ECS服务等级协议

    4)AWS&Google云产品服务协议


    四、API 网关服务等级协议

    下面分别介绍不同厂商的API网关服务的可用率定义

    1)京东云API 网关服务等级协议(SLA)

    2)阿里云API 网关服务等级协议(SLA)

    3)亚马逊云API网关服务SLA


    五、基于SLO告警治理实践

    SLO是可靠性决策的关键因素。应用每天都有无数的报警通知,如CPU、内存、磁盘、可用率、MAX,tp99,tp999等,产生了大量噪音。但哪些报警会影响到可用性,需要SRE和研发关注呢?这就是SLO的核心价值之一了。

    告警设定的目标:根据SLO对重要的事件做出可操作性的告警。

    告警设定的依据:基于服务质量指标(SLI)和错误预算,对每一个消耗大量错误预算的事件发出重大事件的告警通知。

    参考上面设定的SLO配置的报警信息如下:

    1)API告警配置

    我们可以通过设置合理的阈值和规则,过滤掉那些不必要的告警信息,从而避免告警噪音对开发运维团队的干扰,让他们更加专注于真正的问题。

    •通过UMP实现3个黄金监控指标(可用率、调用量、TP99)

    在配置报警机制时,我们可以综合考虑可用率、TP99以及调用量等因素来进行评估。通过这些指标的综合评估,可以帮助我们更全面地了解系统运行情况,从而及时发现潜在的问题并采取相应的措施。

    建议在进行报警配置时,可先采取较为严格的策略,即先紧后松,逐步调整到最佳状态。这样可以确保在最开始阶段就能够及时发现问题,避免出现重大故障。但随着系统的逐渐稳定,我们也可以根据实际情况适当放宽报警阈值,以提高系统的可用性和效率。

    需要注意的是,在进行报警配置时,我们需要结合具体的业务场景和系统特点来进行调整和优化。不同的系统可能存在不同的风险点和瓶颈,因此我们需要根据实际情况来制定相应的报警策略,以保证系统的稳定性和可靠性。

    比如SLO:分钟级TP99是200ms,但你日常TP99在80ms,根据日常接口的行为,电话critical报警一定得配置<=200ms,warning可配100ms或者150ms等不断调整到最佳状态

    critical告警方式:咚咚、邮件、即时消息(京ME)、语音
    可用率:(分钟级)可用率 < 99.95% 连续 3 次超过阈值则报警,且在 3 分钟内报一次警。
    性能:(分钟级)TP99 >= 200.0ms 连续 3 次超过阈值则报警,且在 3 分钟内只报一次警。


    warning告警方式:咚咚、邮件、即时消息
    可用率:(分钟级)可用率 < 99.99% 连续 3 次超过阈值则报警,且在 30 分钟内报一次警。
    性能:(分钟级)TP99 >= 100.ms 连续 3 次超过阈值则报警,且在 30 分钟内只报一次警。
    调用次数:当方法调用次数在 1 分钟的总和,连续 3 次大于 2000000 则报警,且在 3 分钟内只报一次警


    备注:语音critical告警配置调用次数一般意义不大,因为如果你接口的可用率没问题,并且你的TP99也在预期内,按调用次数高又有什么关系呢。但warning配置调用次数有一个好处,比如你配置了JSF限流,目前JSF限流是触发了会报警,你可以在UMP或者Pfinder增加调用次数的阈值报警,比如设置为限流值的80%开始报警,这样可提前发现限流导致的风险点。同时通过调用次数也可知晓流量增长趋势

    2)MQ告警配置

    需要根据MQ延迟(数据从生产到消费需要多少时间)配置对应告警和应急预案

    •生产者T(1)监控:生产者到MQ的时间监控

    •消费者T(2.1)监控:通过MQ的积压报警配置进行监控。

    •消费者T(2.2)处理逻辑监控:配置处理逻辑的UMP报警。

    正常场景: T(3) > T(1) + T(2.1) + T(2.2)   其中T(3)包含读最终数据的耗时

    积压报警的配置需要结合上述耗时公式,并且经过压力测试来确定。

    假设在积压20,000消息的情况下,现有服务能力能够在N毫秒内处理完成,并且满足[ T(3) > T(1) + T(2.1) + T(2.2) ]的条件。那么,报警阈值可以设置为积压20,000消息以下,例如10,000 warning,15000 critical报警以预留处理时间。

    例如,若[ T(3) = 2000ms ],日常[ T(1) ]的最大值为20ms,在积压20,000消息的情况下[ T(2.1) = 980ms ],[ T(2.2) = 1000ms ]。

    3)定时任务告警配置

    由于定时任务跟常规的JSF-API接口或者MQ不一样,定时任务是在规则约定的时间内执行,如果UMP是定时任务,最重要的一点就是确定好监控时段。只有正确地配置了监控时段,才能确保UMP在预计时间段内正常执行,这样一旦UMP未能在预计时间段内执行,就会自动触发报警机制,及时发现并解决问题。

    比如xxx是每天的1点执行

    我需要监控1点是否执行了

    六、问题解答

    通过阅读本文,相信你已经知道如何解答文章开始的3个问题了

    1)SLA、TP99、超时时间的关系?

    1. TP99没什么好说的,看接口的UMP打点即可,比如这图接口的TP99是10-15ms。

    1. 由于上游是下单前黄金链路,对性能要求较高。SLA(其实是SLO)我们对外承诺的TP99(分钟)是20ms,预留6ms的buffer
    2. 超时时间设置:超时时间可以设置在TP99(业务要求高的参考TP999、TP9999、MAX)(包含网络延迟)的基础上加上一定的缓冲时间。其中缓冲时间需要根据经验或监控数据等日常行为统计学,增加一个安全缓冲时间。例如,如果下游接口的TP99是200ms,您可能将超时时间设置为300ms到400ms。
    3. 重试次数设置:
      • 下游接口必须支持幂等,方可重试
      • 重试策略:根据业务场景和下游接口的稳定性来决定重试次数。一般来说,重试次数不宜过多(1-3次),以避免加重系统负担,同时要考虑重试后是否会不满足你对外的SLA指标,尤其下游出现超时严重的时候。
      • 指数退避:使用指数退避策略,每次重试的间隔时间逐渐增加(例如,第一次等待1ms,第二次等待2ms,第三次等待4ms)。
    4. 实施和监控:监控实际的重试情况和超时情况,定期评估重试和超时策略对系统性能的影响。调整策略以适应实际情况。

    请注意,设置超时时间和重试次数是一个需要平衡多个因素的决策过程。它需要考虑系统的稳定性、响应时间、资源使用和用户体验等多个方面。此外,任何重试策略都应该避免可能导致级联故障或资源耗尽的情况。

    2)团队系统可用率是怎么计算的?

    问题2:系统中的一个API接口的可用率是99.99%,那么在部门中,包含了N个系统和M个接口,部门的季度可用率是99.98%,这个数字又是如何计算出来的呢?

    如A系统为黄金流程生产系统,因系统出现服务故障,导致生产业务无法操作,故障时长为A,影响业务占比率为B,则最终可用率故障时长为 C=A*B;

    可参考问题3的计算公式

    比如黄金链路故障时长150分钟,影响业务占比10%,折合系统不可用时长=15分钟。

    则月度系统可用率=1-(故障总时长/统计周期总时长)*100%=1-(15/30*24*60)=99.96%

    3)云主机&网关API可用率

    问题3:比如在XXX云购买了100台云主机(按照云主机SLA),其中在10:00-10:05这5分钟,有10台机器有故障,导致API对外可用率是90%(5分钟之内总请求数1W,失败请求数1000)。一个月30天每天发生类似的5分钟1次。请问对用户来说可用率是多少?

    从2个维度来解答

    1. 从提供基础服务的云服务等级协议来解答(这个不同云厂商基本是一致的)。
    2. 从面向用户的API角度来解答 (不同厂商定义公式不一样)

    任何产品都不是,也不应该做到100%可靠,因为对用户来说99.999%和100%的可用性大部分没有本质的区别。那多少合适呢?可靠性目标需要考虑的因素:

    1. 服务可靠性要达到什么程度,用户才会满意?
    2. 如果可靠性不够,是否有其他替代选择?
    3. 服务的可靠程度是否会影响用户对服务的使用模式?
    4. 是否直接关系到收入?
    5. 服务是针对消费者还是企业?
    厂商
    服务可用性义
    可用率
    AWS
    “可用性”每5分钟计算一次,是API Gateway处理的请求中未因错误而失败的请求百分比,如果你再5分钟内为请求,则任务100%可用
    “每月正常运行时间百分比”是指月度账单周期中所有5分钟时间段的可用性平均值。
    服务可用性=(1-服务周期内Σ每5分钟错误率/服务周期内5分钟总个数)x1 = (1-0.1*30/12*24*30)=1-3/8640=0.9996=99.96%

    七、技术指标&业务指标

    正如上面说的SLA定义了服务可用性、性能等技术指标。那么业务指标到底要解决什么问题?解决技术指标(可用率,tp99)看不到的问题。关注的是数据的正确性和完整性

    SLA的技术指标和业务监控的数据正确性通常是相互关联的。技术指标不可用,则肯定业务指标会不可用。相反如果业务指标不可用有异常,不一定技术指标不可用。例如,如果一个系统的可用性低于SLA中定义的阈值,那么这可能会影响到业务流程的正常运行,从而导致数据错误或丢失。因此,为了确保业务连续性和数据准确性,SLA和业务监控通常需要共同考虑和管理。

    八、「以终为始」SLA指导11.11大促备战

    SLA可以作为一个强有力的工具,指导11.11大促的备战工作,明细如下:

    1.明确服务目标:上下游明确SLA(服务性能TP99、可用性、峰值QPS)等方面的承诺。这些目标应该与11大促的业务需求相匹配,例如峰值流量下的系统稳定性和快速响应能力。

    2.制定备战计划:根据SLA的要求,制定详细的备战计划,包括资源配置、系统优化、灾难如何快速恢复等。例如,如果SLA要求系统在高峰期的可用性达到99.99%,那么备战计划就需要考虑如何实现这一目标,你的容错方案、降级方案、应急预案等。

    3.军演全链路压测和容量规划:为了确保在大促期间满足SLA的要求,需要进行性能压测&军演全链路压力测试和容量规划。通过压测高流量场景,验证系统的性能和稳定性,并根据测试结果调整资源配置和系统优化策略。

    4.监控和警报系统:建立一个全面的监控和警报系统,实时跟踪服务的性能和健康状况。如果某个指标超出了SLA的阈值,系统应该自动触发警报,通知相关团队采取行动。

    5.优先级管理:在大促期间,根据SLA的重要性和影响范围,设定问题的优先级,确保最关键的服务得到优先处理。

    6.团队协作和沟通:SLA要求各个团队之间的紧密协作和高效沟通。建立跨部门的协作机制,明确每个团队的职责和SLA目标,确保所有团队都朝着同一个目标努力。

    7.持续改进:11.11大促结束后,回顾整个过程,分析SLA的达成情况,找出改进的空间。将这些经验和教训应用到下一年的备战中,持续提升服务质量。


    附:1)SLO文档示例

    服务概述

    常见的有API,MQ消息

    API
    SLI
    SLO
    可用率
    根据负载均衡器指标衡量的成功请求的比例=成功请求量/总请求量
    99.95% 成功
    延迟
    根据负载均衡器指标衡量的足够快的请求的比例。
    “足够快”的定义是 < 200 ms,或 < 500 ms。持续时间小于或等于“0.2”秒的“api”请求 计数除以所有“api”请求 计数
    TP99(99%请求延迟时间 < 200 ms)
    积压量(MQ考虑)
    根据MQ消息的积压量统计,积压量= 吞吐率 * 时效
    按峰值计算吞吐量:比如小时峰值360万/ 3600 =‬1000/s (大于此值开始发生积压,)

    说明和警告

    • 请求指标是在负载均衡器上测量的。此度量可能无法准确度量用户请求未到达负载均衡器的情况。
    • 我们仅将HTTP 5XX状态或者约定的API Response里的Code错误编码消息视为错误代码;其他一切都算成功。

    2)云服务级别指标


    如果文中有任何不足之处,恳请各位不吝赐教,留言指正。谢谢大家的阅读和反馈!


    相关文献

    1、Google SRE 三部曲

    2、国家标准全文公开系统《信息技术 云计算 云服务级别协议基本要求》

    3、京东云服务协议:https://docs.jdcloud.com/cn/product-service-agreement/cloud-hosting-service-terms

    4、AWS:什么是 SLA(服务等级协议)?https://aws.amazon.com/cn/what-is/service-level-agreement/

    5、Google Cloud:Compute Engine Service Level Agreement (SLA)https://cloud.google.com/compute/sla

    6、阿里巴巴服务等级协议:https://help.aliyun.com/document_detail/56773.html

    7、华为云服务等级协议:https://www.huaweicloud.com/declaration/sla.html

    8、腾讯云服务等级协议:https://cloud.tencent.com/document/product/301/103169


    1、Amazon_API_Gateway_SLA:https://d1.awsstatic.com/legal/amazon-api-gateway-sla/Amazon_API_Gateway_SLA_2022-05-05-ZH_CN.pdf

    2、京东云API网关服务等级协议(SLA):https://docs.jdcloud.com/cn/product-service-agreement/api-gateway-level-agreements-sla

    3、阿里云API 网关服务等级协议(SLA)https://terms.alicdn.com/legal-agreement/terms/b_end_product_protocol/20230914095615293/20230914095615293.html