【51CTO.com快译】想适当地管理和监测应用程序，您需要一个目标来定义您所处的位置以及工作做得如何，以便您可以不断调整和改进。这个参考点名为服务级别目标(SLO)。花时间定义明确的SLO将使服务所有者以及依赖您服务的内外用户的日子过得更轻松。
然而在定义SLO之前，您需要一个客观的量化指标，以便查看它以确定应用程序的性能或可靠性。这类指标就叫服务级别指标(SLI)。
服务级别指标(SLI)
要确定应使用什么指标用于SLI，一个好方法是从应用程序性能方面考虑什么直接影响用户的满意度。这可能包括应用程序的延迟、可用性和准确性等方面。另一方面，CPU利用率将是糟糕的SLI，因为您的用户并不真正关心服务器CPU在如何运行，只要它不影响您使用应用程序的体验。
此外，您选择的SLI将取决于您所运行的应用程序类型。若是典型的请求/响应类型的应用程序，您可能会关注可用性、请求延迟和每秒成功请求的容量。您可能会查看用于数据存储的数据的可用性和一致性。若是数据管道，您的SLI可能是否返回预期的数据以及处理数据需要多长时间，尤其是在最终一致性模型中。
服务级别目标(SLO)
SLO是在一段时间内为SLI测量的性能阈值。这是衡量SLI以确定性能是否符合预期的标准。良好的SLO将定义您应用程序所需的性能级别，但不会高于必要级别。这是一个关键点，需要随着时间的推移进行一番测试。如果您的用户对99%的可用性感到满意，就没有理由投入大量的资金以达到99.999%的可用性。
延迟的一些示例SLO可能是第95个百分位的延迟，它会告诉您用户发出的最慢5%请求的延迟。这比可能很容易因异常值而偏离的简单延迟平均值要好得多。
提供更细粒度的另一种选择是测量请求总数和超过合理阈值(比如1秒)的请求数。超过基准线的请求百分比将有助于确定您的用户不耐烦地等待数据返回、页面呈现或操作完成有多频繁。
一旦确定了实际的性能目标，您需要确定用于衡量的时间段。SLO的两个常见时间段是基于日历的度量，从一个设定的日期到另一个日期(比如一个月的开始和末尾)。另一种是滚动窗口，从当前日期回溯设定的天数。
服务级别协议(SLA)
服务级别协议(SLA)就是SLO，包含服务提供商和客户之间的附加协议，如果SLO未得到满足，就明确某种形式的后果。这通常出现在供应商和客户这两个不同的企业之间，违反SLA会面临经济后果。SLA也可以在公司内部使用，某些服务可能依赖由不同团队控制的其他服务，以便产品正常运行。
为何使用SLO?
您已对什么是服务级别目标有了清楚的了解，可能想知道为什么要花时间来创建和使用SLO。最明显的原因是，花时间弄清楚在性能方面真正重要的东西可以为您的团队大大简化工作，并在整个公司清楚地传达标准。您可以通过多种不同的方式来跟踪应用程序生成的指标，但如果您将其分解为什么对用户有明显的影响，就可以消除许多干扰和杂音。
在InfluxData，我们专注于时间序列数据。因此，我们拥有涵盖我们系统各方面的大量数据。虽然高度细化的指标有运营价值，但这些指标并不能很好地反映客户体验，肯定让服务所有者想要更多。因此，我们采取了检查每个微服务及使用者的方法，并确立合理的成功标准和可实现的目标。
由此得到的结果是我们可以应用于整个车队的一致测量，深入了解可用性和错误率，这充当客户体验的代理。这不仅有利于服务所有者，作为实现卓越运营和告知错误预算的一种手段，还便于深入了解我们在公司各层面的工程组织。
这些是我们运营的服务底层的仪表板背后的目标。您会看到很容易一目了然，提供了可用于警报和错误预算的实用指标，并表明该服务的目标是达到99.9%的可用性。通过在整个公司提供这些数据，我们可以加快服务的交付。反过来，这为在我们的平台上开发应用程序的客户带来了高速的“精彩时间”。
需要注意的重要一点是，SLO不必在首次实现时就完美无缺。SLO始终在不断完善中，随着您获得更多的数据，了解有关用户需求和期望的更多信息，可进行迭代。切记：实施SLO最重要的方面是监测应用程序方面的总体观念发生转变。
原文Understanding SLOs for monitoring applications，作者：Tim Yocum
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
