Service Levels: Understanding SLIs, SLOs, and SLAs

#systemdesign #sre #computerscience

Overview

This article covers Google Site Reliability Engineering (SRE) book material and Google Cloud material about service levels: SLIs, SLOs, and SLAs.
What are service levels? Their indicators, objectives, agreements and consequences.
Which metrics to gather, how to gather, and why?
Which objectives to set, and why?
When can we turn an SLO into an SLA?
Why is it so important, if you really want to reduce churn and customer's disappointment?

The measured quality of a service, expressed as a quantified target that matches user needs. It can be: availability, latency, throughput, error rate, data freshness, and more.
Even correctness can be measured: the proportion of requests that returned the right answers.
Why do we need service levels? Measurement is the key, saying "reliable system" isn't enough, we need to measure and verify it constantly.

SLI is the quantitative indicator, the metric, and it has observed values for those metrics.
SLIs examples: p99 = 200ms; correctness (right responses) = 99.7%; availability = 99.9% (three 9s);
Another good example is: data freshness = data that is less than 10 seconds old (current time - data timestamp) => 99 of 100 = 99%

What we want to achieve in our system: The target we want the SLI to achieve.
It should be reliable enough to meet user needs, but not so tight that it becomes expensive and hard to maintain.
Generally people think the harder or bigger the SLO, the better, but this is not the idea, we will discuss it soon after covering basics.
SLO example: SLI: Latency - SLO: p99 < 200ms

An agreement with the customers about metrics the system will deliver, and the consequences if the agreed service level isn't met.
SLA example: SLA: 99.9% availability - if it falls below this, the customer receives 10% credit.
Target without contractual consequence = SLO.

For that use a monitoring system such as Prometheus.
Don't rely only on backend metrics, also track frontend. Since user experience and user satisfaction are our objective we should also track metrics and cover problems that happen only on frontend. For example, slow page TTFB (time to first byte), and other issues.
Common metrics and interpretations:
- p50 = median latency (50% of requests are faster than this)
- p99 = tail latency (99% of requests are faster than this)
- Why is p99 called "tail" latency? Because p99 measures the latency near the end of the distribution, where the slowest 1% of requests are.
- more variance = more tail latency effect
- Avoid variance, Google researched that users prefer slightly slower responses than high variance response times and unpredictability.

Create a SLI template with default settings. It is especially useful when starting with service levels to help understanding.
Example:
- Perform metrics aggregation every 1 min
- Aggregation region = all tasks of entire cluster
- Measure every 10s
- Data-access latency = time to last byte
- Which routes to monitor and measure? Features critical flow; the most important ones for users
These I've told you are examples, don't follow them blindly.
Google SRE book mentions it as examples. I believe it's a good start.

As we've discussed earlier the SLOs can be multiple, and they are based on the SLIs.
Common indicators are: availability, latency, throughput, correctness, data freshness...
But having multiple indicators is not the point, the key is understanding your users and their needs. And only then setting SLOs to match their expectations and increase customer satisfaction.
There are a lot of things to consider on user behavior and research you should do to achieve this, since this is not the focus of this post I'll limit myself in this topic here.

Don't create SLOs only because they are on top of indicators easy to measure and objectives easy to achieve.
It's better to have only a couple of SLOs that really match user expectations than easy and useless ones.
If you see that it is a good strategy to "categorize" users and identify needs for these categories, then you can see which ones to focus on. This is especially good when user needs vary a lot.

Insisting that SLOs be met 100% of the time kills innovation and software delivery, and is pretty expensive.
Keep it simple, don't build complex SLI aggregates.
Have as few SLOs as possible (just enough to meet user needs - understand your customers.)
Don't expect user needs will be easy to match, find the right balance.
Perfection can wait, find a good margin not too tight but good enough for users.
Keep a safety margin internally tighter than the public one.
SLA requires time, and analysis of the difficulty to meet it across time. If you can't ensure it, don't create one.
Research, run experiments and tests to understand your users' needs.