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

作者：京东物流 冯志文

背景

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

问题（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	可用率	吞吐量	限流
XXXX	XXXX	com.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/3024*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.130/1224*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