作者：京东物流 冯志文

背景

又到一年的 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 分为如下几类

3）SLO 实践应用

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

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

选择目标 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.服务是针对消费者还是企业？

七、 技术指标 &业务指标

正如上面说的 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 消息

说明和警告

•请求指标是在负载均衡器上测量的。此度量可能无法准确度量用户请求未到达负载均衡器的情况。

•我们仅将 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