前言

对于跨服务通信，而服务所有者归属不同团队所管理，服务等级协议提供了服务间沟通期望机制，也称之为期望管理，服务等级协议是提供某种级别服务可靠性和性能的承诺，对于业务双方是一种约束，双方在这样的约束下开展后续的工作，服务等级协议还可用于企业与用户之间法律或者合同协议，本章节更多讨论内部之间服务等级协议，如什么是服务等级协议，服务等级协议作用。

1、服务等级协议

谈到服务等级协议，一般离不开几个关键词分别是SLA、SLO、SLI这三个关键词有同一共同点，那就是和服务有关，如果脱离服务那就变得毫无意义，服务是一切提供给客服有用功能的服务或者上层产品，这里多数指的是软件服务，这三个目标让其客户或者业务方都能对服务可用性、性能达成共识，如果您的服务出现故障，多久可以快速响应，对速度和功能做出的承诺，因此需要SLA、SLO、SLI，帮助我们遵守这些承诺内部目标及如何行动。

服务等级协议(SLA)

SLA服务等级协议是提供企业与客户之间关于可衡量指标的协议，如正常运行时间、响应能力等，通常情况下该协议由企业的业务团队和法律团队共同参与制定，它们代表对客户做出的承诺以及如果未能兑现承诺的后果，包括经济赔偿、服务信用等。

SLA挑战

众所周知、SLA难以衡量，对于报告和满足协议，通过团队难以衡量所做出的承诺，随着业务不断的演化，并不总是能够所有事项保持一致，很多细微的差别难以考虑到。

例如：SLA承诺团队将在24内小时解决客户提出的问题，但是很多问题可能需要客户及时协助，提供问题描述、背景、截图等，便于团队帮助诊断问题，那么规定客户在这段时间内及时响应，或者对24内小时的定义更加描述清楚，防止出现该歧义。

SLA作用

SLA服务等级协议是企业和付费客户之间的协议，免费向客户提供服务不太可能希望或为该免费客户提供SLA，更多是为了付费客户做出承诺。

SLA实战

SLA服务等级协议其实包括两部分，首先是服务等级目标SLO、其次是未达服务等级目标SLO时，要做出的后果，如经济赔偿、信用等等。

SLA是一个很好的工具，可以帮助合理配置资源。理想情况下SLA状态是：增加额外资源来改进系统所带来的收益小于该资源投给其他服务所带来的收益。

举个例子：某服务可用性从99.9%提高到99.99%所需要的资源和带来的收益之比，是决定该服务是否应该提供4个9的重要依据，说白了平衡收益和成本比，请记住，服务可用性越高，运营成本就越高，是成正比的。

服务等级目标 (SLO)

SLO服务等级目标是SLA关于特点指标的协议，如正常运行时间、响应时间、服务吞吐量等，如果说SLA是与客户之间的正式协议，那么SLO是对内部业务方做出的承诺，SLO用于设定业务方的期望，并依据该SLO和内部团队衡量自身的目标。

SLO挑战

SLO不像SLA那样令人讨厌，但是如果SLO描述含糊不清、过于复杂或无法衡量时，它们可能会产生其他同样的问题，SLO的定义是只有最重要的指标才能够获得SLO状态，便于简单明了，语言阐明，并且和SLA一样，始终要考虑延迟等问题。

SLO作用

SLO不仅对SLA需要，SLO对于组织内部业务方都有用，如内部业务系统，CRM、财务系统这些可能与外部系统同样重要，因此为了建设系统的稳定性，同样也离不开SLO，SLO不仅是是是业务目标的重要部分，而且能够使内部团队对目标更加明确的重要部分。

SLO实践

SLO一般有三部分组成，分别是SLI、持续时间、目标。

• SLI ：例如，包含 HTTP 代码 200 的响应数与响应总数的比率、QPS、每分钟告警数。
• 持续时间 ：指标的衡量时间段。此时间段可以基于日历（例如，从一个月的第一天到第二个月的第一天），也可以是滚动窗口（例如，过去 30 天）。
• 目标 ：例如，您希望在给定持续时间内满足的良好事件占事件总数的目标百分比（例如 99.9％）。

在定义和制定SLO时，如何定义持续时间和目标可能会很困难，在这个过程可以确定使用SLI并随时间绘制图表，如果无法确定要使用的持续时间和目标，SLO并不完善或者不一定完美，SLO是随着业务迭代的，以确保能够满足需求。

对于配置SLO时的几个最佳实践：

• 指定计算的时间窗口
• 使用一致的时间窗口(XX小时滚动窗口、季度滚动窗口)
• 要有一个免责条款，比如：95%的时间要能够达到SLO

对于服务首次配置SLO时，可以遵循以下原则：

• 测量系统当前状态

• • 设置预期(expectations)，而不是保证(guarantees)
  • 初期的SLO不适合作为服务质量的强化工具

• 改进SLO

• • 设置更低的响应时间、更改的吞吐量等

• 保持一定的安全缓冲

• • 内部用的SLO要高于对外宣称的SLO

• 不要超额完成

• • 定期的downtime来使SLO不超额完成

设置SLO时的目标依赖于系统的不同状态，根据不同的状态设置不同的SLO，如服务状态场景、高峰期均不同，视情况而定。

SLO重要性

为什么要有SLO，这里说其实SLO的重要性，不论是对于客户而言还是组织内部业务方来说，是可预期的服务质量，能够依据该SLO衡量和设计自身的目标，对于服务提供者而言，首先是我们自身能够预期服务的质量，还可进行风险控制，对于故障发生时，能够有足够的准备应对，采取适当的措施降低损失。

SLO治理

SLO配置完毕之后，是不是整个工作就结束了呢，显然不是，如何保证SLO能够达到预期呢，那么就需要有观测和治理，通过监控和策略SLI，通过数据对比SLI来看是否达到预期，对于不满足预期，这适当调整以满足目标需要，这个过程是持续的，直到满足目标为止，对于后续还需要定期抽样检测，防止SLO经过时间的演化不满足预期，这个过程可能业务也发生了变化，因此需要定期治理，一般来说服务越可靠，运营成本就越高。

服务等级指标(SLI)

服务等级指标SLI是对服务等级目标SLO遵守情况，也可以是对服务行为的直接测量，如果对于系统的SLA定义在99.95%时间内可用，那么对应的服务SLO可能是99.95%的正常运行时间，而对于SLI的正常运行时间实际测量的值也需要是99.96%或99.99%，SLO值应大于SLA的值，通常情况下，内部的SLO目标更紧于外部的，也是我们对该SLO的定义做出的承诺，一旦没有做到，那么SLA肯定也未满足，违背双方的约定。

SLI 挑战

SLI和SLO一样，SLI的的挑战在于保持它们的简单些，选择正确指标并进行跟踪采集、并不会通过跟踪太对不重要的指标让其工作变得过于复杂，故对该指标的定义能够简单、最核心、最适合、并非全部的，这就对提指标的定义提出更高的要求。

SLI重要性

所有的SLO衡量都要依据SLI这些来进行衡量，如果没有SLI，则就没办法真正用于SLO。

选择SLI

对于SLI是经过仔细定义的测量指标，它根据不同系统特点确定要测量什么，SLI的确定是一个非常复杂的过程确定，对于SLI的选择和确定，可以尝试从以下问题寻找答案：

• 指标：我们要测量的指标是什么？
• 状态：测量时的系统状态，如注意事项、高低峰期？
• 计算：如何汇总处理测量的指标、如计数、分布、平均值？
• 质量：测量指标能否准确描述服务质量，如该指标是否是最核心的？
• 可靠度：测量指标的可靠度？

对于快速识别系统或服务测量的指标的方法，大致可以分为Volume容量、Availability可用性、Latency延迟、Error错误率 和Ticket人工介入次数。

• Volume（容量）：指服务承诺的最大容量是多少。如一个应用集群的 QPS、TPS、会话数以及连接数等等
• Availablity（可用性）：代表服务是否正常。如请求调用的非 5xx 状态码成功率，就可以归于可用性。
• Latency（时延）：响应是否足够快。这是一个会直接影响用户访问体验的指标。如用户访问响应市场、或对于任务类的作业，我们会看每个任务是否在规定时间内完成了。
• Error 错误：指错误率有多少？除了5XX之外，我们还可以把4XX列进来，服务可用性从业务和体验角度来说，4XX太多，用户也是不能接受的。
• Ticket 人工介入：是否人工介入或者介入次数，如某项工作或任务需要人工介入，那说明一定是低效或有问题的；再例如数据任务跑失败了，但是无法自动恢复，这时就要人工介入恢复；或者超时了，也需要人工介入，来中断任务、重启拉起来跑等等。

衡量SLI

对于我们确定能否满足SLO，是通过对指标衡量得出的，该指标就是服务等级指标。选择最佳指标是第一步也是非常重要的一步，一旦选错或该指标来不能作为代表来计算SLO，那么可能就变得毫无意义，例如每秒请求数、每秒错误数、平均响应时间、P99响应时间等等，该指标计算类型有计数器、分布、平均值，如下：

• 计数器：例如，在给定衡量点发生的错误数。此类指标会增加，但不会减少。
• 分布：例如，在给定时间段内填充特定衡量指标细分的事件数。您可以衡量 0-10 毫秒内完成的请求数、11-30 毫秒内完成的请求数，以及 31-100 毫秒内完成的请求数。结果是每个存储分区的计数，例如 [0-10: 50]、[11-30: 220]、[31-100: 1103]。
• 采用平均值：例如，系统的可衡量部分的实际值（例如队列长度）。此类指标会增加也会减少。

SLI实战

值得注意是并非所有的指标都是SLI，要能选择最佳最合适最核心的，不能滥竽充数。通常将SLI视为两个数字的比率：良好的事件除以事件总数，SLI的范围是0%到100%，其中0%表示全部都是无用，100%则表一切完好。

什么样的指标可以作为SLI、理想的SLI指标具备以下特征：

• 指标与用户满意度直接相关：如果服务的运行与期望不服务，失败或者缓慢，用户是不满意的，该指标的数据能够反馈出用户的满意度。
• 指标恶化与中断相关：在服务中断期间，哪些看起良好的指标也不是良好的SLI指标，在正常运行期间的表现不佳的指标也是SLI的错误指标
• 提供良好的指标信噪比：任务SLI指标大量出现突增或突降也不是良好的SLI指标
• 持续改善：随着指标改善，满意度会越来越高

在发生不良 SLI 的情况下，用户不满意未直接对应于负面事件（例如服务降级、缓慢或中断）。此外，SLI 独立于用户满意度波动。在良好 SLI 中，SLI 和用户满意度相关联，不同的满意度等级清晰，且不相关波动要少得多。

适当数量指标

通常情况下，每个服务具有多个SLI，特别是选择适当数量的指标，每个服务在不同的业务场景下提供服务时，例如读写分离，原因是这些行为会产生不同的运作方式，在这种情况下，最好选择适用每个服务指标。在某些写场景某个SLI指标可能并不能和用户的期望发生关联，这时就可采用多个SLI组合，例如在线教育系统，用户更多关心的是今天上课的流畅度，是否能够很顺利完成线上学习，而不是用户等待很久，用户并关系其他的内容。

对于SLI指标的选择，尽可能少的使用SLI来准确表示服务的容忍度，通过情况下，每个服务可以具备2到6个SLI指标，不能太对也不能少，太少可能错误有价值的内容，太多可能造成信息泛滥及干扰，甚至可以选择TOP3，逐渐改善，使其更好的满足期望值。

小结

SLA、SLO、SLI不仅仅是有用的抽象、如果没有它们，无法知道系统的可靠性及可用性，如果它们没有明确地和业务目标联系起来，那么久不知道所做的对业务是否有帮助，更无法为付费客户做出承诺，想要了解服务的可靠性，必须要衡量成功和不成功的比列，也就是SLI基础，并非每个可跟踪指标都应该是 SLI，SLI指标要用户满意度或业务目标关联起来，通过SLI构建SLO，使用SLO，少即是多，专注那些对用户最重要的，如果需要制定SLA、SLA应该比SLO更宽松些。