SLA, SLO, SLI — co to jest i jak zarządzać niezawodnością?

SLA to kontrakt z klientem. SLO to cel wewnętrzny. SLI to metryka. Error Budget to równowaga. Poznaj framework zarządzania niezawodnością usług technologicznych.

SLI → SLO → Error Budget → SLA

SLI

SLI (Indicator) — Co mierzymy?

% requestów zakończonych sukcesem (HTTP 2xx) w ciągu ostatnich 30 minut

Narzędzia: Prometheus, Datadog, CloudWatch

SLO

SLO (Objective) — Jaki jest nasz cel?

99.9% requestów zakończonych sukcesem w 28-dniowym rolling window

Narzędzia: Wewnętrzne dashboardy, Nobl9, SLO24

Error

Error Budget — Ile możemy sobie pozwolić?

0.1% = 40 minut awarii na 28 dni. Gdy zużyte — freeze deployment, focus na reliability

Narzędzia: Error Budget dashboardy, burndown alerts

SLA

SLA (Agreement) — Co gwarantujemy klientom?

99.9% uptime miesięcznie lub credit 10% faktury za każdy % poniżej progu

Narzędzia: StatusPage, contract templates, credit system

Tabela dostępności — ile to godzin?

Poziom SLA	Roczny downtime	Miesięczny downtime	Dla kogo?
99% (two nines)	87.6 godzin	7.3 godziny	Niekrytyczne systemy wewnętrzne, early-stage startupy
99.9% (three nines)	8.7 godzin	43.8 minut	Standardowy SaaS B2B, platformy e-commerce
99.95%	4.38 godzin	21.9 minut	Premium SaaS, enterprise tier
99.99% (four nines)	52.6 minut	4.38 minut	Systemy finansowe, healthcare, enterprise krytyczny
99.999% (five nines)	5.26 minut	25.9 sekund	Infrastruktura telekomunikacyjna, systemy krytyczne

Priorytety incydentów P0-P3

P0 — Critical

Odpowiedź: 15 minutRozwiązanie: 1 godzina

System całkowicie niedostępny, wpływ na wszystkich klientów

Przykład: Całkowita awaria API, login niemożliwy

P1 — High

Odpowiedź: 30 minutRozwiązanie: 4 godziny

Poważna degradacja usługi, wpływ na znaczącą część klientów

Przykład: Payment flow broken, data export nie działa

P2 — Medium

Odpowiedź: 2 godzinyRozwiązanie: 24 godziny

Częściowa degradacja, istnieje workaround

Przykład: Wolne generowanie raportów, błędy w konkretnym module

P3 — Low

Odpowiedź: 8 godzinRozwiązanie: 72 godziny

Drobny problem, minimalne/brak wpływu na produktywność

Przykład: Błąd literówki, niedziałająca animacja, edge case

FAQ — SLA, SLO, SLI

Co to jest SLA (Service Level Agreement)?

SLA (Service Level Agreement) to umowa między dostawcą usługi a klientem, definiująca minimalne gwarantowane poziomy jakości usługi — dostępność systemu, czas odpowiedzi, czas rozwiązania incydentów. SLA jest dokumentem zewnętrznym (kontrakt z klientem) i zazwyczaj zawiera kary umowne (credits) gdy nie jest spełniony. To formalne zobowiązanie: 'Gwarantujemy 99.9% uptime w miesiącu, a jeśli nie — otrzymasz zwrot proporcjonalny do przestoju.'

Czym różni się SLA od SLO i SLI?

SLI (Service Level Indicator) to metryka mierząca aktualny poziom usługi — np. % requestów z latency poniżej 200ms, uptime w danym oknie. SLO (Service Level Objective) to wewnętrzny cel tej metryki — 'chcemy utrzymać 99.9% uptime' — ustalany przez team inżynierski i używany do zarządzania niezawodnością. SLA to zewnętrzny kontrakt z klientem — zazwyczaj bardziej liberalny niż SLO, bo naruszenie SLA powoduje kary finansowe. Hierarchy: SLI (miara) → SLO (cel wewnętrzny) → SLA (kontrakt zewnętrzny).

Co oznacza 99.9% uptime SLA?

99.9% uptime (three nines) to max 8.7 godzin przestoju w roku (lub 43.8 minut miesięcznie). 99.99% (four nines) — max 52 minuty przestoju rocznie (4.38 min/miesiąc). 99.999% (five nines) — max 5.26 minut przestoju rocznie. Im więcej 'dziewiątek', tym wyższy koszt infrastruktury i tym trudniejszy do osiągnięcia. Większość SaaS B2B gwarantuje 99.9% (three nines). Systemy krytyczne (banking, healthcare) wymagają zazwyczaj 99.99%.

Co to jest Error Budget?

Error Budget to 'budżet błędów' — ilość przestoju lub błędów którą możesz sobie pozwolić w danym oknie czasowym, by nie naruszyć SLO. Jeśli SLO = 99.9% uptime miesięcznie, error budget = 0.1% = 43.8 minut awarii/miesiąc. Koncepcja z Google SRE: jeśli error budget jest 'zielony' — team może szybciej wdrażać zmiany i features. Jeśli error budget jest 'czerwony' — należy zamrozić wdrożenia i skupić się na niezawodności. Error budget definiuje równowagę między szybkością a niezawodnością.

Jak mierzyć compliance z SLA?

Kluczowe elementy: monitoring 24/7 (Datadog, New Relic, Grafana, PagerDuty), jasna definicja co liczy się jako 'downtime' (planned maintenance exclusions?), rolling window vs. calendar month, process raportowania do klientów, automated alerts gdy zbliżamy się do limitu error budget. Ważne: SLA monitoring powinien być niezależny od systemu który monitoruje — użyj zewnętrznych narzędzi (StatusPage, Pingdom) aby uniknąć konfliktu interesów.

Czytaj dalej