How to define Service Level Objectives without historical data?

Question

Assuming I can define Service Level Indicators for a user journey are there any structured methods for setting a Service Level Objective within that SLA without any historical data to indicate what is realistic or feasible?

For Availability we can often turn to various mathematical approaches that enable us to understand the maximum theoretical availability of the system, although even this is tied back to historical data in the form of Mean Time between Failure (MTBF) and Mean Time to Recover (MTTR).

Answer 1

Without much data you are really guessing, the general thought I have heard before is to start at 80% SLO then work your way up as you have data to back up your goal. There really is not set way of figuring out a SLO without some data. Even taking and using a week's data would be good enough to give you a reasonable idea.

Answer 2

I think the short answer is: You shouldn't define SLOs, if you don't have historical data.

With that being said, SLIs can be defined without historical data and correlated with KPIs and support metrics.

Here is a concrete example:

• Hipster store is about to launch.
• Product management, dev and SRE wants to define SLOs.
• They should start by defining SLIs, e.g site availability, sign-up success rate, checkout success rate.
• PM/execs should agree to some kind of 'soft' launch and gradual rollout (if at all possible), e.g internal to employees -> partners -> single state/coast/country.
• As the 'soft' and gradual rollout progresses, they can correlate swings in the SLIs with changes to KPIs (e.g revenue) and support metrics.

At this point, the hipster store leadership would have some information about how much customer unhappiness/pain (e.g support metrics) and KPIs (e.g revenue) are correlated with SLIs. The SLOs are the bars. One or multiple can be set and alerts defined around them. Rinse and repeat.

A follow-up question is: How to alert and what to alert on before SLOs are set? I'd take the following article in consideration - https://www.oreilly.com/ideas/reduce-toil-through-better-alerting.