If you work for a business, there’s a possibility that you’ve heard the terms SLO, SLA, and/or SLI before.
The commonality that these terms share is that they can be used to be a little more precise to measure the actions taken to meet business goals when it comes to serving users.
In this article, we’ll briefly describe what SLA’s are, SLO’s, and SLI’s and how they relate along with how are they different. By the end, you should have a better idea of what each one means and be able to use them more accurately.
We’ll start first with SLA.
SLA is short for Service Level Agreement.
Here’s how Atlassian describes SLA:
An SLA (service level agreement) is an agreement between provider and client about measurable metrics like uptime, responsiveness, and responsibilities.
Basically, an SLA lists out the promises that a provider — or a business — give to their customers along with any penalties that are fair to assess if the provider doesn’t meet the SLA requirements.
The stipulations within SLA’s can include 99.999% uptime (or some other variable amount of 9’s), 300 milliseconds response time, certain throughputs, and more.
Another agreement within an SLA could even be that a customer service team must respond to customer inquiries within 12 hours.
These details within SLA’s can also vary during different periods; for example, during a holiday season, perhaps the SLA’s can be tightened to give customers less pause on the services that will be provided.
SLA and SLO is sometimes mentioned interchangeably in casual conversation, but their true meaning is a bit different.
SLO is short for Service Level Objective, and it is a specific promise that a provider or a company provides for a certain metric. Thus, SLA’s contain one or more SLO’s.
Let’s say that you’re a company, Bossperson Enterprises, providing a really robust database solution specific for bosses (you’re free to use this fantastic business idea, if you’re wondering).