如何跟踪实际的服务水平目标

服务健康是根据多个服务级别目标定义的，这些目标以用户为中心，而不是以操作为中心。

例如，要确保您的服务在没有过多维护工作的情况下运行得足够好，有一些关键问题；

• 你的应用程序目前运行在什么服务水平？
• 企业期望什么样的服务水平？
• 您如何监控实际的服务水平？
• 如果它低于预期的服务水平，你该怎么办？

这些为您提供了明确的指导，说明您应该如何定义目标服务级别，如何监控实际服务级别，以及当您的应用程序出现服务丢失时该如何处理。
操作通常使用服务级别协议(SLA)，对系统健康状况进行评级。他们可能会设定99%的服务可用性目标，这听起来不错，但也提出了一些非常重要的问题。

1. 从业务上来说，为什么只有99%？如果你能做到99%，那么你肯定能做到100%，并一直保持系统可用。
2. 从IT管理的角度来看，如果您违反了SLA会发生什么？我们如何知道它是否下降到98%，我们如何回到容忍范围内？

SRE做的事情不同。服务健康是根据多个服务级别目标定义的，这些目标以用户为中心，而不是以操作为中心。因此，通用的99%可用性SLA被特定的目标SLO所取代，例如：

• 99.9%的请求将被成功处理，-SLO 1
• 90%的响应将在半秒内返回，-slo2
• 99%的响应将在2秒内返回。-SLO 3

这些SLO跟踪用户体验，目标是定义一个足以让客户满意的可靠性水平。
如果应用程序开始产生错误或需要很长时间来响应，那么用户将记录投诉或切换到另一个产品。SLO旨在定义在此之前需要采取行动的阈值。这总是低于100%，因为100%实际上是不可能的。
让我们把一些实用性，采取28天的测量窗口。在此期间有40,320分钟用于监视响应时间。99%的目标使你在突破前有403分钟的时间（这是40,320分钟的1%）。这大约是每个月7个小时，当您的响应时间服务水平可能会让用户无法接受时，这看起来确实很多。但是三个9是99.9%，这让你一个月只有40分钟（这是40,320分钟的0.1%）。四个九一个月只允许你4分钟，五个九只是傻傻的。
现代分布式系统有多个运动部件，它们跨越多个内部和外部服务。对于大多数应用程序来说，四个9非常难以实现，而且非常昂贵。
您可能会考虑跨多个云或混合云和数据中心交付的双运行服务，并保持全球同步的实时数据。这将使您的体系结构变得非常复杂，并显著增加您的运行成本。而且可能没有必要有那些严格的服务水平。

如果一个网页的响应时间超过几秒钟，用户只会点击F5。下一个请求可能会到达不同位置的不同服务器，然后返回。偶尔出现的问题不会影响绝大多数用户体验，所以它们不太值得再增加9个。

错误预算

SLO需要是可实现的目标，并且它们是在涉众、业务产品所有者、dev团队和SRE团队之间达成一致的。SLO给你的是一个窗口，在那里超出容忍范围是可以的，这就是你的错误预算。
错误预算只是100%减去你的SLO。因此，如果一个SLO目标是99.9%，那么你在这段时间内有0.1%的误差预算，这是你在28天内的40分钟。您需要错误预算，这样您就可以轻松地更改系统。绝大多数服务问题是由更新或配置更改引起的，因此错误预算有效地控制了产品的发布速度。这就是为什么需要在产品所有者、dev团队和SRE团队之间达成三方协议。
一个新产品可能有一个较低的SLO，因为业务想要快速移动和试验。这意味着大量的发布，伴随着大量的风险，他们将不得不接受较低的SLO，因为这是开发团队需要继续前进的。
拥有许多快乐但要求很高的用户的长期产品可能会有更严格的slo。业务部门同意尽量减少新特性的发布，以保持应用程序的稳定。太多的问题将耗尽您在此期间的错误预算。当这种情况发生时，需要有一个商定的政策来让服务恢复容忍度。
在SRE中，错误预算政策是一个正式的文档，它定义了当SLO中出现漏洞时会发生什么。同样，这是在业务和IT团队之间达成一致的，策略指定了如何做出反应来尝试和维护SLO。
有两种方法来定义在任何违反错误预算政策的地方发生的事情。
如果在一个时期结束时SLO中有一个小的漏洞，这可能意味着重新确定特性开发的优先级。因此，开发团队还将在下一个时期致力于可靠性问题。
如果SLO在中期被攻破，这可能意味着功能冻结。因此，dev只能在这段时间的剩余时间里处理可靠性问题。
严重的SLO漏洞可能意味着完全的变更冻结。因此，除了关键的安全补丁之外，在此期间没有新的版本。
在SLO和错误预算之间，SRE为您提供了一个结构，以使用户满意，并为产品提供业务所需的速度。错误预算策略是确保您能够平衡这些关注点的契约。

有两种方法来定义在任何违反错误预算政策的地方发生的事情。

1. 如果在一个时期结束时SLO中有一个小的漏洞，这可能意味着重新确定特性开发的优先级。因此，开发团队还将在下一个时期致力于可靠性问题。
2. 如果SLO在中期被攻破，这可能意味着功能冻结。因此，dev只能在这段时间的剩余时间里处理可靠性问题。
3. 严重的SLO漏洞可能意味着完全的变更冻结。因此，除了关键的安全补丁之外，在此期间没有新的版本。

在SLO和错误预算之间，SRE为您提供了一个结构，以使用户满意，并为产品提供业务所需的速度。错误的预算政策是骗局