The difference between SLOs, SLIs, and SLAs
As mentioned earlier, site reliability engineers use three metrics to monitor and measure the performance of IT systems and ultimately increase their reliability: They draft service-level agreements (SLAs), service-level indicators (SLI), and service-level objectives (SLO). These related service-level metrics not only help companies create a more reliable system but also gain more trust with customers.
Learn what the different concepts mean in practice, how they depend on each other, and why they are so important for successful site reliability engineering.
What are SLIs?
SLI stands for the service-level indicator. The Google SRE Handbook defines it as “a carefully defined quantitative measure of some aspect of the level of service that is provided.” This means that SLIs are used to measure the characteristics of a service to provide input for a service provider’s goal.
Product-centric SLIs gauge behaviors that would greatly impact the customer experience. In fact, there are four golden signals used as the most common SLIs: latency, traffic, error rate, and saturation.
When SRE teams set up SLIs to measure a service, they usually define them in two stages.
- They determine the SLIs that directly impact the customers.
- They determine SLIs that have a direct influence on the availability or latency, or performance of the service.
The formula used to calculate SLIs is SLI = Good Events * 100 / Valid Events – an SLI value of 100 is ideal, whereas a drop to 0 means that a system is broken.
It is important to create SLIs that match the users’ journey. This means that one single SLI is not able to capture the entire customer experience as a typical user might care about more than one thing when using the service. At the same time, creating SLIs for every possible metric is not advisable as you would lose focus on what is really important.
As a rule of thumb, site reliability engineers try to find the most important pain points along the user’s journey that could then lead to a total redesign of a system.
Once the SLIs are set up, an SRE connects them to SLOs, which are key threshold values against each SLI quantifying the availability and quality of service.
What are SLOs?
SLOs or service level objectives are used as an objective measure for a service’s reliability or performance goals. The Google SRE Handbook says that they “specify a target level for the reliability of your service” and “because SLOs are key to making data-driven decisions about reliability, they’re at the core of SRE practices.”
While SLIs are product-centric, SLOs are customer-centric. SLOs are measured by SLIs, so the two have an intricate dependency. The natural structure of their relationship is defined as follows: Lower bound SLOs ≤ SLI ≤ Upper bound SLOs.
However, choosing the right SLOs is a complex task. Usually, targets should never be based on the current but a historic system performance. Sometimes, SRE teams also make the mistake to aim for perfection by choosing targets that are way too high. There is also no need to specify absolute values. However, it’s a good idea to keep a safety margin in SLOs by setting a historical average. When adopting SLOs, it’s important to start slowly and then work your way up as their adoption requires a cultural change.
SLOs should be seen as a unifying tool that creates a common language and shared goals across different teams. And you are much more likely to succeed if all key stakeholders are on board. However, many companies are focused on product innovation and don’t see the connection between business performance and reliability. Common roadblocks are siloed data and the wrong assumption that once SLOs are created, they don’t need to be regularly re-evaluated or adjusted.
What are SLAs?
SLAs or service-level agreements are contracts on service availability and performance. Just like SLOs, SLAs are a customer-centric metric. In the Google SRE Handbook, an SLA is defined as “an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain.”
An SLA kicks in as soon as an SLO fails. Typically, you can expect penalties and financial consequences for not meeting the deliverables. If your company breaches a term agreed in the SLA, it usually needs to reimburse its customers.
SLAs help establish transparency and trust between the service and its users. In a way, they’re a lot like SLOs but for external, not internal use. Compared to SLOs, SLAs are not as conservative, meaning that the value of reliability is always slightly lower than the historical average of an availability SLO. This can be regarded as a safety measure in case the average is too high due to very few incidents in the past.
In conclusion, site reliability engineers need to work with all three metrics to create a stable, reliable infrastructure. After collecting SLIs (the metrics in the monitoring system), they define thresholds of these metrics based on internal SLOs in order to prevent a breach in external SLAs.
Learn more
