SLOs, SLIs, SLAs

"Our service is reliable" is not a claim; it's marketing. "Our service is reliable" with numbers — "99.9% of requests complete under 200ms, measured over a 30-day window" — is an engineering target. Without SLOs/SLIs/SLAs, nobody knows if the service is healthy. With them, you have objective thresholds, budgets, and escalation triggers.

Every interview about reliability or on-call goes here. Mix up the three acronyms and you've lost credibility.

An SLI should be user-visible — it correlates with what users actually experience. CPU usage is not an SLI; it's a technical metric that may or may not affect users. Latency and error rate are SLIs because a user feels them.

The four SLIs every service should track, from Google's SRE book:

• Availability. Requests that succeeded (2xx, 3xx, 4xx-that-are-expected) / total. Don't lump 4xx with 5xx — a user sending bad input isn't a service failure.
• Latency. P50, P95, P99 of successful requests. P99 matters because tail latency is user-visible frustration.
• Throughput. Requests/sec. Often a target, not a threshold — capacity planning.
• Correctness. Harder to quantify. "% of orders processed without manual intervention" — domain-specific.

The mistake: picking an SLO number that sounds good ("99.99%!") without understanding what it requires. See availability nines — 99.99% means 52 minutes of total downtime per year. Every extra nine is 10× harder to achieve.

The recipe:

1. Measure current behavior for 30 days → you probably get something like 99.87%.
2. Set SLO at current level or slightly better (99.9%). Gives engineering credit for where they already are.
3. Set SLA at 99.5% — comfortably looser than SLO. If SLO breaches, you have time before contractual penalties.
4. Review SLOs quarterly. If always met, tighten. If always breached, fix reliability or loosen — match reality.

Google SRE's key insight: 100% reliability is the wrong target. It forbids change — every deploy risks downtime. Instead, derive an error budget from your SLO.

SLO = 99.9% over 30 days → allowed downtime = 0.1% × 30 × 24 × 60 = 43.2 minutes/month. That's your budget. Spend it on deploys, experiments, infrastructure changes. If you've burned 30 minutes by week 2, you have 13 minutes left for the rest of the month — slow down deploys.

Error budget policy:

• Budget > 50% remaining → ship freely.
• Budget < 25% remaining → review risky changes more carefully.
• Budget exhausted → freeze feature work, focus on reliability until next window.
• Budget consistently under-used (say, only 10% burned most months) → you're over-engineering reliability at the expense of velocity. Loosen SLO or ship faster.

This turns reliability into a math conversation between dev and ops, not a personality conflict. "Have we met the SLO? Yes → ship. No → fix."

Distributed logging platform has strict availability SLOs (people depend on it when everything else is broken). Payment gateway publishes SLAs for enterprise tiers. Rate limiter's SLI is % of correct limit decisions (false positives and false negatives both count).