tezvyn:

How do you set SLOs for a service from scratch?

AI-drafted, machine-checkedSource: interviewintermediate
WHAT IT TESTS

a disciplined, user-centric process for defining reliability targets.

OUTLINE

identify critical user journeys, pick SLIs that reflect user happiness, measure current performance, set achievable targets with buffer, iterate.

WHAT THIS TESTS This evaluates whether you can run a principled, user-centered process to set reliability targets, and whether you ground SLOs in data and user impact rather than arbitrary aspiration.

A GOOD ANSWER COVERS Begin by identifying the critical user journeys, the few interactions that define whether the service is working for users, such as load the page or complete checkout. For each, choose SLIs that reflect user happiness: availability as the ratio of successful to valid requests, and latency as the fraction served under a threshold. Specify each SLI precisely, what counts as a valid event, what counts as good, and where it is measured, ideally close to the user. Next, measure the current baseline from historical metrics or logs so targets are reality-based. Set initial SLO targets that are achievable and meaningful, often near recent performance, deliberately below 100 percent to leave an error budget. Treat the first SLO as a hypothesis and revisit it after observing a few cycles.

COMMON WRONG ANSWERS Choosing round numbers like 99.99 percent with no basis. Measuring system internals like CPU or memory as SLIs instead of user-visible behavior. Aiming for 100 percent, which leaves no room to change. Defining SLIs vaguely so they cannot be measured consistently.

LIKELY FOLLOW-UPS How do you handle a service with no historical data? How do you choose the right latency threshold? When do you tighten or loosen an SLO? How does this feed an error budget policy?

ONE CONCRETE EXAMPLE For a checkout service, the critical journey is completing a purchase. You define availability as successful checkout responses over valid checkout attempts, measured at the load balancer, and latency as the percentage of checkouts under five hundred milliseconds. Logs show recent availability around 99.93 percent, so you set an initial SLO of 99.9 percent monthly, leaving a deliberate error budget, and schedule a review after one quarter to adjust based on user complaints and burn rate.

Read the original → sre.google

Get five bites like this every day.

Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.