Welcome to Engineering for a Reliability with Google Cloud.
Hi! I am Riccardo,
Developer Advocate in Google.
I work with customers on reliability topics.
In this episode, we're going to explore the Art of SLOs,
and why it may be useful for your organization.
♪ [music] ♪
Wait, what is Art of SLOs?
It's a workshop that will teach you how to choose SLIs and SLOs
for your workloads.
But first, what are SLIs and SLOs?
Well, you might've heard about or even read the SRE books
available for free on
Here you'll find plenty of information
on how Google operates reliable services.
One of the main takeaways of that
is reliability is a key feature of your service,
and that you should measure it and set targets for it.
At this point, you might ask yourself,
"Okay, but how do I choose
what reliability target metrics and thresholds
are appropriate for my application?
I mean, you don't want to be paged every time a VM reboots, right?
You only want to be paged when you believe that your service
is not meeting your user expectations.
To get there, you need a way to measure your service's ability
to keep your users happy,
in a way to set targets for what's reliable enough.
Let's delve into it.
An SLI is a measure of how reliable a service is.
For example, if your service provides an API,
you may choose Latency or Availability,
but for a Data Processing pipeline,
you may look more at data Freshness or Throughput.
An SLO describes when a service is reliable enough to meet user needs.
An Error Budget is just a complement of the SLO,
so if your team chooses that 99% is Reliability target,
the Error Budget will be 1%.
That 1% is the acceptable level of unreliability.
You allocate the Error Budget to maximize your development velocity,
while maintaining the reliability of your service.
Okay, but what is the right target, what is enough?
Setting the right SLO in practice is really hard.
This is why we have created a workshop to teach you.
We came up with a sample online game,
played by millions of users all over the world
dividing to Vampire clans.
We also have a Leader Board to check if you are in the top ten.
There are plenty of business Critical User Journeys:
Log in, Monetization, Battles, Profiles, Leader Board Generation.
All things your players care about.
And how do you use this?
Each Journey is a pragmatic and self-contained exercise
where you will need to find what SLI you care about.
Let's say-- latency.
Okay, but latency between which two points in time?
You need to break your journey down
to the scope that you believe is most important for your user.
Your team initially will disagree on which is more important,
and the discussion that will come up, until you reach consensus,
is crucial.
As you likely trade-off
between business requirements and engineering constraints.
And now, where do we measure it?
At the Load Balancer or on the client app?
Your team will build up the muscles
to determine the right SLOs fo your journey.
And usually, after two or three iterations,
your team will get a lot better at this.
"Sounds good, Riccardo," you might be thinking,
"but how much does it cost?"
Nothing. It's all freely available under Creative Commons license.
You have slides and docs for the facilitator
who will moderate that workshop,
and a Participant Handbook that you can share with the team.
Further, the workshop has materials like Retrospective Exercise
to refine an existing SLO.
I hope I made you curious now.
Feel free to check it out, and let us know what you think.
[ringing]
Oh, sorry.
[ringing]
Sorry, folks. I've just been paged.
We're burning Error Budget
for our latency SLO in the European region.
I need to fix this ASAP to ensure that we stay within our SLO.
I knew I shouldn't have shot this video while on call.
Hah, wish me luck!
♪ [outro music] ♪