基于 SLA 的测试

问题缘起

在信通院发布的《云原生测试白皮书》正文第 9 页，提到“基于 SLA 的测试”。有社区伙伴提问，什么是基于 SLA 的测试？之前并未细想过这个概念。带着 QA 刨根问底的职业病，是时候借此契机搞明白这个问题了。

对于不熟悉的问题，我的习惯是先做关键词拆解：基于，SLA，测试。所以先来研究什么是 SLA，再研究 SLA 该怎么测。

什么是 SLA

服务级别协议（英语：service-level agreement，缩写 SLA）也称服务等级协议、服务水平协议，是服务提供商与客户之间定义的正式承诺。服务提供商与受服务用户之间具体达成了承诺的服务指标——质量、可用性、责任。

——维基百科

由此可见，SLA 是服务提供者和服务消费者之间的契约，规定了服务内容及度量指标要求。比如云厂商经常宣传高 SLA（也就是我们经常听到的的几个 9），来表达云服务的高可用性。这也解释了为什么我们通常听到 SLA 的场景是微服务和性能压测。往往在复杂的服务调用过程中会约束服务间协议，制定清晰的 SLA 项和度量指标，如常见的请求成功率、吞吐量、可用性、数据一致性等。

SLA 项必须是清晰可测的，否则就不能证明提供的服务满足 SLA 的定义。那么 SLA 测试都包含哪些内容，又该如何进行呢？

基于 SLA 的测试

由 SLA 的定义不难看出，基于或面向 SLA 的测试其实是一种测试方向或测试目标的描述，而非具体的测试方法或技术。

基于 SLA 的测试，就是针对 SLA 进行测试，确保服务能达到 SLA 的定义水平。这里其实包含两个视角：我是服务提供商，还是服务面向的客户。角度不同，所关心的测试也不同。

在云原生测试的语境下，这两个视角是云厂商和云用户。云厂商自己会做面向 SLA 的测试，来保证提供的云服务满足需求，而云厂商的用户则不需要关心这点。云用户关心自己的微服务架构的应用软件，要考虑微服务内部的 SLA。

除了上面的正向理解，再补充一点：在云厂商视角中，因为云系统应用间的依赖关系极其复杂，而且任何产品的 SLA 都无法做到 100%，因此，如果一个对 SLA 要求很高的产品依赖了一个 SLA 比较低的产品，就需要有面向失败的设计。Design for failure is the key to success in the cloud.（可参考文末推荐阅读获取更多信息）

基于 SLA 的测试包含 XX 吗？

可能由此讨论引发出更多问题：基于 SLA 的测试是否包含混沌工程？是否包含性能测试？是否包含微服务测试？……

上面提到，基于 SLA 测试的目的是为了验证 SLA 的约束被满足，但不局限测试种类和方法，具体该采用什么测试方法，应取决于 SLA 的内容约定了什么。

因此比较严谨的描述应该是：基于 SLA 的测试可以包含混沌工程，可以包含性能测试或性能工程，可以包含 XX……也可以被混沌工程、性能工程或 XX 所验证和度量。

推荐阅读

1. 如何提升系统可用性？
   

2. 什么是云原生？
   

3. 面向失败的设计
   

4. 《云原生测试白皮书》