SLI vs SLO vs SLA: różnice i jak je ustawić

W skrócie: SLI to co mierzysz, SLO to jaki cel chcesz osiągnąć, SLA to zobowiązanie umowne. Te terminy z książki Google SRE są jednymi z najczęściej używanych zwrotów w prowadzeniu usług webowych - i często mylonych.

SLI - Service Level Indicator

Konkretna metryka, którą kwantyfikujesz niezawodność usługi. Przykłady:

• % requestów, które zakończyły się HTTP 2xx lub 3xx w ostatnich 30 dniach
• % requestów z response time poniżej 500 ms
• % poprawnie dostarczonych emaili (delivered, nie bounced)
• Stosunek udanych transakcji płatniczych do wszystkich prób

Kluczowe cechy dobrego SLI:

• Mierzalny - istnieje konkretna metoda zbierania danych
• Istotny dla użytkownika - odzwierciedla rzeczywiste doświadczenie klienta, nie wewnętrzną metrykę techniczną
• Specyficzny - "uptime" jest zbyt mglisty; "% udanych requestów do /api/v1/orders w oknie 5-minutowym" to SLI

SLO - Service Level Objective

Wewnętrzny cel, jaką wartość ma SLI osiągać. Wyrażany procentowo za okno czasowe.

Przykłady:

• "99,9 % requestów do /api/orders ma zakończyć się HTTP 2xx w 30 dni"
• "95 % requestów ma response time poniżej 200 ms w 7 dni"
• "99,5 % transakcji płatniczych przejdzie pomyślnie w miesiącu kalendarzowym"

SLO jest wyższy niż SLA, aby mieć buffer. Jeśli SLA mówi 99,9 %, wewnętrzny SLO powinien być np. 99,95 % - aby mieć rezerwę na nieoczekiwane incydenty.

SLA - Service Level Agreement

Zobowiązanie umowne wobec klientów. Definiuje co się dzieje, gdy nie dotrzymasz SLO - typowo:

• Service credits - zwracasz część miesięcznej opłaty (10-50% w zależności od wielkości naruszenia)
• Termination rights - klient może wypowiedzieć umowę bez sankcji
• Obowiązek reportingu - musisz publikować postmortem i raporty uptime

SLA ma konsekwencje prawne. SLO to cel wewnętrzny.

Error budget

Kluczowa koncepcja SRE: downtime, na który możesz sobie pozwolić bez naruszenia SLO.

Przykład: SLO = 99,9 % uptime w 30 dniach. To 0,1 % dopuszczalnego downtime. 0,1 % z 30 dni = 43 minuty miesięcznie. To twój error budget.

Praktyczne konsekwencje:

• Jeśli masz już 35 min downtime w miesiącu, zostaje 8 min do "naruszenia SLO". Zespół powinien być konserwatywny przy kolejnych deployach.
• Jeśli masz 5 min downtime, masz 38 min budget na ryzyka - możesz robić bardziej agresywne zmiany, testy A/B, eksperymenty.
• Error budget rozwiązuje konflikt między szybkością innowacji (dev team) a stabilnością (ops team). Obaj śledzą to samo liczbę.

Praktyczny przykład: API e-commerce

SLI: % requestów HTTP do POST /api/checkout, które zakończyły się 2xx, mierzone w bucketach 1-minutowych w ostatnich 30 dniach.

SLO: ≥ 99,9 % udanych requestów w oknie rolling 30-day.

SLA (dla klientów Enterprise):

• ≥ 99,5 % uptime w miesiącu kalendarzowym
• Przy 99,0-99,5 % = 10% credit z miesięcznej opłaty
• Przy 95,0-99,0 % = 25% credit
• Przy < 95,0 % = 50% credit + prawo wypowiedzenia umowy

Error budget: SLO 99,9 % oznacza 43 min downtime / miesiąc na budget. SLA daje jeszcze większy buffer przed ekonomiczną penalizacją.

Podsumowanie: tabela

Praktyczne błędy

• SLO zbyt ambitne. 99,99 % wymaga active-active redundancy w wielu regionach. Dla małej firmy nierealne.
• Tylko uptime SLO. Web może być "up" i mimo to nieużyteczny. Dodaj latency SLO i error rate SLO.
• SLA bez automatycznego pomiaru. Manualnie kalkulowany raport SLA jest niewiarygodny. Zainwestuj w automatyczne uptime tracking.
• SLO bez konsekwencji. Jeśli naruszenia SLO nikt nie obchodzi, nikt o nim nie pamięta. Linkuj do deploy freeze, on-call escalation, itd.

Wnioski

Framework SLI/SLO/SLA nie jest papierową biurokracją - to język, którym zespół engineering komunikuje się z business stakeholders o niezawodności. Bez tych terminów dyskusja o stabilności staje się subiektywna ("nasz web jest niestabilny"). Z nimi jest liczbowa ("w ostatnich 30 dniach osiągnęliśmy 99,87 % SLI, co jest poniżej naszego 99,9 % SLO - tu jest plan działania").

Mierz SLI w czasie rzeczywistym

ePulz.io zapewnia historyczny zapis uptime z rollupem 30/90/365-dniowym. Podstawa dla reportingu SLO.

Uruchom monitoring →