SLOs and Error Budgets

The Hierarchy

 SLI: the MEASUREMENT — indicator of user experience
      success_ratio of valid requests under 300ms
 SLO: the TARGET on that measurement
      99.9% of requests < 300ms, over rolling 28 days
 SLA: the BUSINESS contract with penalties (looser than SLO —
      you promise clients less than you hold yourself to)

 the translation discipline:
 pick SLIs USERS FEEL: availability, latency, freshness,
 correctness. CPU is not an SLI; it's a cause-indicator.

Choosing Targets Honestly

 not everything deserves 99.99%:

 service class        availability   latency budget
 batch report gen     95-99%         minutes ok
 internal admin       99%            1s ok
 customer API         99.9%          p99 < 500ms
 checkout/payments    99.95-99.99%   p99 < 300ms

 each extra nine costs real money (redundancy, ops rigor);
 UNMEASURED ambition defaults everyone to gold-plating.

 the 28-day window matters:
 long enough for monthly cycles, forgiving of brief blips,
 and matches business-quarter arithmetic naturally.

The Error Budget in Action

 budget = failures ALLOWED by the SLO:
 99.9% over 28d → 43 minutes of full-downtime equivalent.

 [budget remaining > threshold]──► ship features fast
 [budget burning fast]─────────► slow down deliberately
 [budget exhausted]────────────► reliability work only;
                                  feature-freeze until recovered

 this converts the velocity-vs-stability FIGHT into ARITHMETIC:
 both sides accept numbers negotiated IN ADVANCE.
 product owns spending priorities; SRE owns the floor.

 burn-rate math powers alerting (own lesson):
 page when consuming budget ≥14× rate (fast) or 6× (slow) —
 alerts become budget-arithmetic instead of threshold folklore.

Operating the Program

Practice	Detail
ownership	each service’s SLO has a named owner + reviewed targets
dashboards	compliance %, budget remaining, burn rate visible
reviews	quarterly: targets still right? budget spent wisely?
honesty	count IMPLICIT errors too (timeouts client-side)
scope	start with 3-5 critical user journeys, not 200 services

 the implicit-error point is where programs die quietly:
 server-side 200s that timed out client-side never appear
 unless CLIENT-measured SLIs exist. measure at the edge.

Interview Framing

“Engineering wants to ship faster; support says quality is slipping” scored shape: SLI/SLO/SLA hierarchy defined with felt-by-users SLIs, target-setting table by service class with cost-of-nines reasoning, error-budget GOVERNANCE mechanics (freeze rules, burn-rate alerting), implicit-error measurement caveat, start-small rollout advice. This question tests whether reliability can be NEGOTIATED like an adult — budgets are the treaty.