How would you set an SLO for a new service that has no historical reliability data, and how do you keep that SLO from becoming a number nobody acts on?
technical-conceptual · Senior level · cloud-devops-security
What the interviewer is really asking
Probes whether the candidate can pick meaningful user-centric SLIs, set an initial target without prior data and iterate, and — critically — wire the error budget to actual decisions (release gating, prioritization) so the SLO drives behavior rather than sitting on a dashboard.
What to say
- Start from the user journey, not the resource: pick SLIs that reflect what the user experiences on the critical path — request success rate and latency of the key operation — measured at the point closest to the user.
- Set a defensible starting target and iterate: with no history, derive an initial target from user expectations and dependency limits, ship it explicitly as provisional, then tighten or loosen as real data arrives rather than agonizing for the perfect number up front.
- Wire the error budget to decisions: define what happens when the budget burns — slow or freeze risky releases, reprioritize reliability work — because an SLO that changes no behavior is just a vanity metric.
What to avoid
- Defaulting to '99.99% because higher is better' with no link to what users need or what the architecture can deliver — over-tight SLOs burn budget on nothing and erode trust in the target.
- Choosing SLIs based on what's easy to measure (CPU, host uptime) rather than what the user actually feels.
- Treating the SLO as a reporting number with no error-budget policy, so it never influences a single release or prioritization decision.
Example answers
Strong: With no history I anchor on the user: SLIs for success rate and latency of the critical journey, measured close to the user. Without data the target is a hypothesis, so I'd set a provisional one from user expectations and our dependencies' limits — say 99.9% — ship it labeled provisional, and tune it as real numbers land. The part that actually matters is the error-budget policy: when the budget's burning we slow risky releases and pull reliability work forward. Without that link the SLO is just a dashboard nobody acts on.
Weak: I'd set the SLO at 99.99% to start since that's a strong reliability target and we can always relax it later. We'd track availability on the dashboard and report it each month so leadership can see how the service is doing.