When embarking on your SRE journey, it can seem daunting to decipher all the acronyms. What are SLOs versus SLAs? What’s the difference between SLIs and SLOs? In this blog post, we’ll cover what SLI, SLO, and SLA mean and how they contribute to your reliability goals.
What’s the Difference Between SLI, SLO, and SLA?
Below are the definitions for each of these terms, as well as a brief description. Definitions are according to the Google SRE Handbook.
SLI: “a carefully defined quantitative measure of some aspect of the level of service that is provided.”
SLIs are a quantitative measure, typically provided through your APM platform. Traditionally, these refer to either latency or availability, which are defined as response times, including queue/wait time, in milliseconds. A collection of SLIs, or composite SLIs, are a group of SLIs attributed to a larger SLO. These indicators are points on a digital user journey that contribute to customer experience and satisfaction.
When a developer sets up SLIs measuring their service, they do them in two stages:
- SLIs that will directly impact the customer.
- SLIs that directly influence the health and the availability or the latency and performance of certain services.
Once you have SLIs set up, you move into your SLOs, which are targets against your SLI.
SLO: “a target value or range of values for a service level that is measured by an SLI. A natural structure for SLOs is thus SLI ≤ target, or lower bound ≤ SLI ≤ upper bound.”
Service level objectives become the common language that companies use that allows teams to set guardrails and incentives to drive high levels of service reliability.
Today many companies operate in a constantly reactive mode. They’re reacting to NPS scores, churn, or incidents. This is an expensive, unsustainable use of time, and resources, let alone the potentially irrecoverable damage to customer satisfaction and the business. SLOs give you the objective language and measure of how to prioritize reliability work for proactive service health.
SLAs: “an explicit or implicit contract with your users that includes consequences of the meeting (or missing) the SLOs they contain.”
Service level agreements are set by the business rather than engineers, SREs, or ops. When anything happens to an SLO, SLAs kick in; they’re the actions that are taken when your SLO fails and often result in financial or contractual consequences.
#devops #site reliability engineering #site reliability #site reliability engineer #site reliability engineering tools #service level agreements
