SLI, SLO, SLA, windows, and burn-rate arithmetic

An SLI is a quantitative measure of service behavior; an SLO is a target or range for an SLI over a stated population and time window; an SLA is an agreement whose consequences and measurement rules are contractual. They are related artifacts, not nested mathematical sets, and no universal rule requires an SLO to be exactly one “nine” stricter than an SLA.

For request-based availability, good events divided by valid events yields the SLI. The allowed bad-event ratio is 1 - SLO. Burn rate is observed bad-event ratio divided by the allowed ratio. Window type, missing data, low traffic, exclusions, late events, and aggregation policy are part of the definition rather than implementation trivia.

Модель и предпосылки

• Example: 99.9% over 30 days allows 0.1% bad events. One million valid events allows 1,000 bad events; a time-based approximation is 43.2 minutes only when every minute has equivalent weight.
• At a 30% bad-event ratio against a 0.1% allowance, burn rate is 300x and an otherwise uniform 30-day budget would exhaust in 30 days / 300 = 2.4 hours.
• Multi-window alerts combine a long window for budget significance with a short window for currentness; Google’s 14.4x 1h/5m example spends about 2% of a 30-day budget, not the entire budget in five hours.

Проверяемые утверждения

• C1. An SLI measures service behavior, an SLO targets an SLI over a window, and an SLA adds an agreement and consequences; they are not nested sets.
• C2. Request-based error budget is the allowed bad-event ratio times eligible events; time-based minutes are valid only for a time-based indicator or an explicit equal-weight approximation.
• C3. Burn rate equals observed bad-event ratio divided by the SLO-allowed bad-event ratio.
• C4. Multi-window, multi-burn alerts trade precision, recall, detection time, and reset time; threshold selection depends on the budget fraction and SLO window.
• C5. Feature freeze is an organization-specific error-budget policy decision, not an automatic mathematical property of an SLO.

Исполняемые сценарии

Define a request-based SLI. The team fixes the journey, eligibility, goodness, source, and window before calculating a percentage.

Error-budget units. A 99.9% request SLO permits 1,000 bad events per million, while 43.2 minutes is only a separate time-based approximation.

Fast-burn arithmetic. A sustained 30% bad-event ratio against a 99.9% SLO burns at 300x and would exhaust a uniform 30-day budget in about 2.4 hours.

Low-traffic and missing-data guard. A ratio from a tiny or incomplete sample is not treated as a stable population estimate.

Ошибки проектирования

• Не пишите SLA ⊆ SLO ⊆ SLI и не обещайте фиксированный разрыв в одну девятку.
• Не переводите event budget в downtime без явной time-based модели или распределения трафика.
• Не смешивайте calendar и rolling windows; reset и weighting дают разные стимулы.
• Не page-ите по p99 или remaining budget без определения user journey, eligible population и sustained window.

Границы гарантии

• Low-traffic services need synthetic checks, longer windows or event-count guards; a short ratio can be statistically unstable.
• Client-side SLIs often better represent experience, but measurement loss and privacy require an explicit policy.
• SLA language, credits, exclusions and jurisdictions require legal review and need not equal the internal SLO calculation.

Связанные материалы

Официальные и первичные источники

1. Google SRE Book: Service Level Objectives
2. Google SRE Workbook: Implementing SLOs
3. Google SRE Workbook: Alerting on SLOs
4. Google SRE Workbook: Example Error Budget Policy