最近参与了部门消息服务的架构升级和稳定性保障，以此文简单总结下当建设和负责维护中间件稳定性时必备的SLA基础知识，一并调研了目前国内外商业化的云消息中间件产品SLA相关情况，最后附上个人在维护消息中间件和支持不同业务场景时的一些通用性粗浅思考，有不恰当的地方欢迎大家探讨交流。

一、SLA基础概念

无论你是一名个人云开发者，正在众多云服务提供商的套餐和支持方案中进行比较和选择；或是作为企业的采购负责人，评估外部供应商提供的服务系统是否满足企业业务需求和发展目标；亦或是公司内部服务平台的技术运维人员，需要评估系统的实际性能和边界条件，以判断其是否能够满足内部业务部门的要求并提供相应的保障承诺.......所有这些场景都离不开一个关键概念：服务等级协议（SLA，Service-Level Agreement），而你打开任意一家云服务厂商的官网，你都能在产品页面中找到一份公示的SLA。

在上述场景中，显然具备三个核心组成要素，即围绕SLA的上下游存在着两类角色，分别是服务提供方（SP，Service Provider）和服务客户（SC，Service Consumer），如下图所示：

【图1】 SP -> SLA -> SC

形式上来说，SLA是指系统服务提供者对客户的一个可量化服务承诺和协议，它是将服务质量评估从经验模型向量化模型转变的关键工具。SLA通常明确列出了服务可用性、数据可靠性、响应时间等服务特性指标及其定义，服务提供方基于这些指标对客户做出量化承诺。此外，SLA 中还详细说明了服务提供方未满足承诺时的补偿操作（后果），例如提供额外支持、优惠折扣或钱款赔偿。通常，SLA 是在客户和外部服务提供商之间达成，但同一公司内的不同部门也可以相互签订 SLA，此时未满足SLA承诺的后果一般不涉及经济赔偿，而侧着于业务责任划分。

需要注意的是，SLA 的生命周期并不像图 1 所示的那样呈现单向、一次性或静态的特征。相反，它是一个双向、持续且动态的反馈和调整过程。在这个过程中，客户的需求可以通过 SLA 反向推动服务提供者进行系统设计和迭代决策。实际上，围绕 SLA 的生命周期，图 1 可以进一步优化为图 2 所示的形式：

【图2】 SLA生命周期

为了完全理解上图，我们需要了解一些SLA中的特别概念：

1.1 SLA常见概念

SLI（Service Level Indicator）服务等级指标：SLI指定了SLA中所提供服务某一维度的可量化指标，且必须具有清晰严谨的定义和计算方式。比如，对于某一网站的单实例服务器，一个简单的SLI定义是由客户端所发出合法的请求得到正常响应的百分比，合法的定义是请求参数和资源类型能够被服务端约定的协议解析成功，正常响应的定义是请求结果中不包含超出协议约定的错误或非预期数据。

SLO（Service Level Object）服务等级目标：SLO明确了SLA中所提供服务某一维度的期望状态，是围绕SLI构建的目标。SLO是客户感知和判断服务质量最为直观的方式，常见的说法如“XX 可用性达到几个 9”就是一种 SLO。规范来说，SLO有指标范围和实现时间要求，这意味着在特定时间窗口内（通常是服务周期），涉及的 SLI 必须达到预定的指标标准，并且在该时间段内的实现比例应达到预期。如果未能达到SLO，则应触发SLA中定义的后果，一般为对SLA中服务提供方的惩罚以及对客户的补偿方案。

【eg】，在单实例工作负载小于 10,000 TPS 的条件下，指定服务的平均请求响应时间应小于 85 毫秒，且响应有效率需超过 95%。承诺在一个月的服务周期内，这些指标的达成时间比例应超过 99.9%。若未满足上述服务等级目标，则将提供相当于服务费总额 20% 的代金券作为补偿。

因此，可以简单理解为：SLA = SLO + 后果 = SLI + 实现指标和时间占比要求 + 后果。可以看出，服务SLA是众多云厂商获取客户青睐和信任的有效竞争手段和必要承诺。通过明确服务质量的量化指标、期望目标以及未达成目标时的补偿措施，SLA 有助于建立客户与服务提供商之间的信任关系，并在竞争激烈的市场中提升服务商的竞争力。

【图3】 服务SLA的重要性

此外，部分云厂商也提出了一些其他概念：

SLA规则：是在SLA指标（SLI）的基础上，添加了判断条件，以触发告警或停止压测。这些规则可以帮助在服务性能偏离预期时及时识别问题，确保服务稳定性。

SLA模板：是SLA规则的集合，可包含一个或多个SLA规则。SLA模板通常与行业、业务类型绑定。通过使用 SLA 模板，组织可以快速应用符合其特定需求的服务等级协议规则集，从而提高管理效率和一致性。

SLA拓扑，也称为SLO拓扑，指的是当服务足够复杂，链路中涉及多个子服务及其SLO，评估和计算整体服务 SLA 所需的依赖路径关系。

1.2 SLA基本要素组成

基于以上概念，当你作为某项服务系统的提供方起草一份规范的对外SLA时，通常需要包含但不限于以下内容：

协议概述：概述中应明确 SLA 的起始和结束日期、参与协议各方的详细信息，以及所涉及服务的简要说明。例如，协议可能会详细列出服务提供商和客户的联系信息和角色定义。

服务描述：这一部分应对 SLA 涵盖的所有服务进行详细描述，包括关键概念定义。例如，可以包括服务的周转时间、支持的技术和应用程序、计划的维护周期，以及相关流程和程序。

服务等级目标：明确协议中关于特定服务等级指标（SLI）的目标，例如服务可用性或平均响应时间。协议双方同意使用数据支持的关键服务指标来评估这些目标的达成，例如保证 99.9% 的服务可用性。

故障恢复流程：详细说明故障告警和恢复流程，概述供应商在发生服务故障时应遵循的机制和流程。这部分可能包括约定的响应时间（RTO）和恢复时间目标（RPO）。例如，故障报告后 1 小时内开始响应，4 小时内完成数据恢复。

安全标准：协议须明确约定双方采取的安全标准和措施，例如数据私密性、权限控制和安全审查流程，以确保服务的安全性。

排除条款：此部分描述双方商定的所有排除和豁免情形。例如不可抗力事件或第三方故障导致的中断不在服务承诺范围内。

惩罚与补偿：此部分明确规定未能履行 SLA 义务时的后果，例如给予客户相应的服务费退款或代金券作为补偿。

终止流程：双方可能会在某个时间点想要终止协议。除了任一方要求的通知期以外，SLA 还会清楚地规定允许终止或使协议失效的各种情形。

变更与审查流程：服务提供商能力、工作负载和客户要求会随着时间的推移而变化，因此需要定期审查服务商提供的 SLA 。有关服务商或客户要求的任何重大更改，需要被记录在协议当中，确保透明与合规，从而SLA 能够整合服务提供商产品或服务的最新功能来满足当前的客户需求。

签名：该协议由双方授权的利益相关者审查文档中有关各事项后进行签署，在协议生效期间约束所有相关方遵守协议条款。

1.3 SLA常见指标

1.3.1 服务可用性（Availability）

在各类系统服务的 SLA 中，服务可用性是最常见的指标之一。服务可用性指的是服务提供商在特定时间段内保持其服务可供使用的时长。这一指标通常以特定时段（称之为服务中周期）来衡量，并需要明确界定何为"服务不可用"。例如，SLA 可能规定服务提供商的系统在每天内必须保持 99.5% 的可用性，这意味着每24小时，服务不可用的总时长不应超过 7.2 分钟。在计算服务可用性之前，先介绍如下几个定义：

平均故障间隔时间（MTBF）：是指服务相邻两次故障之间的平均时间

MTBF = 总运行时间 / 故障次数

平均故障修复时间（MTTR）：是指服务发生故障后，从故障发生到恢复完毕的平均时间‌。

MTTR = 故障恢复总时间 / 故障次数

平均正常运行时间（MTTF）：是指服务在无故障状态下能够持续运行的平均时间。该指标通常只用于不可修复的系统，也即代表了服务的期望寿命。

从而，可以计算得出服务可用性，图 3 给出了一个简单的例子：

Availability = MTTF /（MTBF + MTTR）

【图4 】可用性计算简化案例

在大多数云产品的对外SLA中，一般以服务周期为评估单位，因此服务可用性采用了一种对客户更直观的表达方式来申明：

服务可用性 =（服务周期总时间 - 服务周期服务不可用时间）/ 服务周期总时间 * 100%

其中，服务不可用的具体定义取决于不同产品的SLA声明。基于以上计算原则，服务可用性SLO中服务周期选取与不可用时长的关系可由下表列出：

1.3.2 数据可靠性（Reliability）

通常针对存储系统设置，指的是数据在存储、传输和处理过程中保持准确性和完整性的能力。被视为可靠的数据将承诺不会丢失、损坏或被未经授权的修改。更细致的又可以分为数据持久性、数据一致性、数据可用（访问）性等等：

数据持久性：指的是数据在存储后能被长期保存的能力，不会因为断电或系统崩溃等问题而丢失。

数据一致性：指的是在数据存储和处理过程中，数据在多副本或多系统之间的状态保持一致的能力。

数据可用性：指的是用户能够访问和使用数据的能力，与服务可用性类似。高数据可用性意味着系统即使在系统发生部分故障或维护期间，在需要时也总是能够提供数据访问。

【eg】，某云服务厂商的对象存储服务承诺可提供99.9999999999%（12个9）的数据持久性，这意味着，存储一万亿个对象大概只会有1个文件是不可读的。一般来说，数据可靠性可宽泛定义为数据在系统中确认存储成功后不丢失/不损坏的概率。
影响数据存储的原因可分为三类：

硬件级故障：例如磁盘损坏、电源故障、内存故障以及网络设备失效等

软件级故障：例如消息队列中的实现bug/死锁可能导致数据未能正确传递或处理，在某些情况下，消息可能未实际写入内存或磁盘，但系统已经向客户端发送了成功确认（ACK）

人为故障：例如错误配置、数据误删除、运维误操作或执行脚本不当等

数据可靠性计算相对服务可用性计算复杂很多，需要依据专门的量化模型计算。如果仅考虑硬件级故障，可参考如下模型来量化一个存储系统的年度数据可靠性：

Reliability = Func(N，R，MTTR，CopySets，D，AFR)

其中，N是存储系统磁盘的总数；R(Replications)是单块磁盘配置的副本数；MTTR为磁盘故障平均修复时间；CopySets（副本数据复制组）是分布式存储系统中对一份数据的所有存储副本的分组集合，这里取CopySets的模，例如一份数据写入到了p1，p2，p3盘，那么{p1, p2, p3}就是一个CopySet，当该CopySet损坏，则这份数据丢失。CopySet可以用于衡量数据副本存储的离散分布程度，且满足：

N/R <= |CopySets| <= C(N, R)

其中C是组合计算符，当数据存储分布越分散随机，那么同时损坏 R 个盘时会完全丢失某份数据的概率就越高，而 |CopySets| 越接近N/R，那么发生损坏时丢失的数据量越高，恢复时间和成本也会攀升，因此CopySet的生成策略十分考验技巧；D(Distributions)是预设的故障概率分布模型，常见有二项分布、泊松分布等；AFR（Annualized Failure Rate)是磁盘的年故障率，其定义为：

AFR = 1 / (MTBF / (24 * 356)) * 100%

从模型组成因子的定义直观来看，AFR、MTTR和CopySets的模与数据可靠性负相关，而磁盘总数和副本数与可靠性正相关。但实际情况并没有这么简单，每项因子对可靠性的贡献可能并不是线性或连续的，因子之间也并不完全独立，例如AFR与MTBF相关，而MTTR也受Replications和CopySet分布策略的影响。由于可靠性模型的具体推导计算过程超出本文篇幅，感兴趣的读者可以移步参考文献[4][5]。

1.3.3 请求错误率(Error Rate)/成功率(Success Rate)/可用率(Availability Rate)：

这三个指标在大多数服务中是客户使用感知最为明显的，通常关注的粒度为服务的接口级别，而服务可用性则是更多侧重评判服务整体的质量。一个常见的场景是，客户端定时监控某项服务请求的错误率，以此衡量服务的某项功能或者子集是否低于SLA中的预期目标。

以错误率计算方式为例：

错误率 = 1 - 成功率 = 时间片内导致系统产生错误的请求数 / 该时间片内的请求总数 * 100%

可用率：可用率在语义上不同于成功率，它要求服务请求的响应正确且有效，并且通常会排除非服务端导致的错误，例如客户端非法参数、权限拦截，服务外部前置链路的限流等等。

这三个指标通常以时间片进行周期计算，例如每1分钟错误率、每5分钟成功率等等

1.3.4 吞吐量(Throughput)：

指单位时间内系统能处理的请求数量，体现系统处理请求的能力，这是目前最常用的性能测试指标。吞吐量指标一般包括QPS（Query Per Second，每秒处理请求数），TPS（Transaction Per Second ，每秒处理事务数）等。

QPS指系统每秒能处理的请求（查询）数，通常用于衡量服务器能抗多少流量：

QPS = 时间片内请求总数 / 时间片秒数

TPS指系统每秒能处理的事务数。这里事务是指一个完整的业务处理和响应过程，可能对系统发起多个QPS中定义的请求：

TPS = 时间片内事务总数 / 时间片秒数

以上计算通常针对网站或者业务系统，对于数据库（例如MYSQL）等其他类型服务而言，除了有更区别细化的定义，还会关心 IOPS（Input/Output Per Second，磁盘每秒读写次数）等SLI。

1.3.5 响应时间/延迟（Latency）：

指系统在收到用户的请求到响应这个请求之间的时间间隔，系统的延迟指标通常与服务的性能、吞吐量等指标相关。
该指标通常会以时间片平均或者百分比的方式计算，并且与采点方式、点位选择强相关：

平均值：此方法通过计算所有请求的平均响应时间，判断是否低于设定阈值。但这只能作为一种较为宏观的评估方式，对于波动型的系统状态或者对半的响应时间分布情况，会掩盖许多问题。

百分比：我们也经常会在SLA中看见p95或者是p99这样的延迟声明，其中p指的是percentile（百分位）。当系统的p95 延迟为1秒，意味着 95% 的请求响应时间小于 1 秒，而剩余 5% 的请求则超过 1 秒。

1.3.6 其他

此外，SLA中通常还会涉及如下指标：

故障频率和恢复：通常涉及服务可用性中提到的MT类型指标，例如代表故障平均恢复时长的MTTR等，部分SLA会单独针对这些指标做出承诺，以便故障发生时客户能有明确的修复耗时预期。

服务支持：通常包含服务提供商提供的技术支持、客户服务等方面的指标。例如，在运营云服务时，可要求服务提供商提供24小时客户服务、及时响应客户请求等。例如，某云服务商提供8:00-24:00的在线服务支持，并提供全天24小时的服务热线。

安全性：为了证明服务提供方会采取预防性措施来减少非安全操作和数据泄露，可量化、可控制的安全指标（如加密可靠性、防病毒更新和补丁等）是许多云服务厂商都必须面对的问题。

业务绩效目标：该指标通常关联服务提供方或者客户业务方的绩效标准。在公司内部的双方合作部门SLA签订中，常见的形式是服务周期内xx业务无x级以上故障。

其他特殊服务/中间件的定制指标

1.4 制定SLO时需要考虑什么

1.4.1 制定并量化统计SLI

在制定服务等级目标（SLO）时，准确统计和量化服务等级指标（SLI）是首先考虑的。如何有效采集和计算SLI，将直接影响SLO的合理性和可达成性，一般需要考虑如下方面：

了解客户群体：明确服务的目标客户群体，在制定 SLI 时，需要提供简明、清晰且无歧义的定义，使客户能够快速理解并达成共识。我们不应追求 SLI 的数量和复杂度，而应重点关注客户真正关心的业务价值和服务使用体验。例如，对于电商平台，下单成功率就是一个关键 SLI。

反映系统性能和架构：SLI 指标应该反映系统的实际性能和可用性，同时采集和计算过程尽量减少对系统的侵入，对于通用型指标可以组装为SLI规则和模版。例如，选择可以通过现有监控工具轻松获取的响应时间或错误率指标。

计算和采集：优先选择可以简单采集且能够正确、准确量化的指标。SLI 的统计可以在用户端（Client-side）和服务提供方（Server-side）进行，常见的统计方式包括客户端埋点数据上报、服务端日志采集分析、探针巡检、时序数据库指标采集等。目前各大厂或云服务厂商都有成熟的中间件或产品方案，例如ARMS；或是基于开源的Prometheus、HertzBeat等等二次开发搭建，进行在线或离线的指标采集和计算聚合。然而，无论采用何种方式，指标采集过程都应避免对服务性能和可用性产生负面影响。确保监控工具和策略设计规范，避免在采集数据时影响服务质量本身。

1.4.2 SLO计算和聚合模型

SLO的通用计算模型一般由SLI、服务周期、服务拓扑链路组成。根据服务自身场景定义出不同维度的SLI并采集计算后，可以汇集出SLO的情况。SLO的计算和聚合规则通常如下：

小周期评判：将服务周期（通常是自然月）拆分为多个小周期，以“服务可用性99.95%”这一SLO为例来说，周期性地计算小周期中的服务可用时长是否达成99.95%占比，如果未达到，则标记此周期不可用。考虑到SLI的数据分析粒度和趋势平滑性，小周期的设定时长通常不高于30s。

计算达成时间占比：计算整个服务周期N内，达标小周期时间的占比，从而得到服务的实际SLO水位：

SLO = ∑ SLI达标小周期时长 / 服务周期总时长

SLO拓扑聚合：如果服务涉及到多条链路，每条链路可拆分多个子服务，并对应有其SLI、SLO，则需要聚合出服务的总SLO