SLA

SLA (Service Level Agreement) - umowa o poziomie usług, która definiuje mierzalne parametry jakości świadczenia usługi między dostawcą a odbiorcą. SLA opisuje, co dokładnie jest dostarczane, jak jest mierzone (np. dostępność, czas reakcji, czas usunięcia awarii), jakie są progi akceptacji oraz jakie konsekwencje obowiązują przy niespełnieniu warunków. W praktyce SLA porządkuje oczekiwania, ogranicza spory interpretacyjne i stanowi punkt odniesienia dla operacji, wsparcia i raportowania. Dobrze zdefiniowane SLA nie jest "marketingową obietnicą" - jest kontraktem opartym na wskaźnikach i procedurach.

Definicja i rola SLA

SLA określa poziom usługi, który dostawca zobowiązuje się utrzymać w czasie. Najczęściej dotyczy usług IT (chmura, hosting, support, integracje), ale występuje też w usługach biznesowych (BPO, call center, logistyka, utrzymanie infrastruktury). Kluczową funkcją SLA jest przełożenie jakości na parametry weryfikowalne - dzięki temu obie strony mogą oceniać realizację umowy na podstawie danych, a nie wrażeń.

W dojrzałych organizacjach SLA jest spięte z procesami operacyjnymi - monitoringiem, obsługą incydentów, zmianą, raportowaniem, a często także z modelami SLO (Service Level Objective) i budżetem błędów. Bez tego SLA bywa deklaracją bez realnej możliwości utrzymania, a w praktyce prowadzi do konfliktu między oczekiwaniem a zdolnością dostarczenia.

Co zwykle obejmuje SLA?

SLA jest zwykle zbiorem punktów, które odpowiadają na pytania: "co mierzymy, jak mierzymy i co się dzieje, gdy wynik jest gorszy". Typowe elementy SLA to:

• Zakres usługi - co jest objęte SLA, a co jest wyłączone (np. konkretne środowiska, funkcje, interfejsy).
• Definicje - precyzyjne znaczenie pojęć (incydent, awaria, czas niedostępności, okno serwisowe).
• Metryki i progi - np. dostępność 99,9%, czasy reakcji i naprawy, przepustowość, limity.
• Okres pomiaru - miesięcznie, kwartalnie; oraz sposób agregacji (średnia, percentyle, sumy).
• Sposób pomiaru - narzędzia, źródła danych, punkt pomiarowy (np. od strony klienta czy od strony serwera).
• Procedury eskalacji - kto i kiedy reaguje, jak zgłaszać incydenty, jakie są kanały komunikacji.
• Konsekwencje - kredyty serwisowe, rabaty, kary umowne lub inne formy kompensacji.

Najczęstsze metryki w SLA

SLA najczęściej operuje kilkoma kategoriami wskaźników. Warto je rozróżniać, bo "dostępność" to nie to samo co "czas reakcji", a oba pojęcia bywają mylone.

• Dostępność (Availability) - procent czasu, w którym usługa jest dostępna w okresie rozliczeniowym.
• Czas reakcji (Response Time) - czas od zgłoszenia do podjęcia pierwszego działania (np. potwierdzenie przyjęcia, rozpoczęcie diagnozy).
• Czas usunięcia awarii (Resolution Time) - czas do przywrócenia działania usługi lub dostarczenia obejścia.
• Latencja i wydajność - np. czasy odpowiedzi API, percentyle P95/P99, przepustowość.
• Utrata danych i RPO/RTO - w usługach krytycznych: maksymalna utrata danych (RPO) i czas odtworzenia (RTO).

Jak liczy się dostępność w SLA?

Najczęściej spotkasz wzór:

Dostępność = (czas całkowity - czas niedostępności) / czas całkowity * 100%

Kluczowe jest, co uznaje się za "czas niedostępności" i czy istnieją wyłączenia (np. zaplanowane okna serwisowe, awarie po stronie klienta, siła wyższa). Bez tego dwie strony mogą liczyć dostępność inaczej.

Przykład: ile wynosi dopuszczalny downtime przy 99,9%?

Załóżmy miesiąc 30 dni (43 200 minut):

• 99,9% oznacza 0,1% niedostępności
• 0,1% z 43 200 minut = 43,2 minuty niedostępności w miesiącu

W praktyce różnica między 99,9% a 99,99% jest ogromna operacyjnie - bo wymaga innej architektury, redundancji i procesów obsługi incydentów.

SLA vs SLO vs SLI - na czym polega różnica?

Te pojęcia często występują razem, ale oznaczają różne warstwy:

• SLI (Service Level Indicator) - wskaźnik, który mierzymy (np. odsetek poprawnych odpowiedzi HTTP, czas odpowiedzi P95).
• SLO (Service Level Objective) - cel wewnętrzny organizacji (np. 99,95% dostępności), zwykle bardziej ambitny niż SLA.
• SLA (Service Level Agreement) - zobowiązanie kontraktowe wobec klienta (np. 99,9% dostępności) oraz konsekwencje niedotrzymania.

Wskazówka: dojrzałe zespoły ustawiają SLO wyżej niż SLA, aby mieć margines operacyjny. Różnica między SLO a SLA działa jak bufor na incydenty i zmienność.

Rodzaje SLA: klient, usługa i wielopoziomowe

W praktyce spotkasz różne konfiguracje SLA:

• SLA klienta (Customer-based SLA) - parametry dopasowane do konkretnego klienta lub segmentu.
• SLA usługi (Service-based SLA) - jeden zestaw parametrów dla danej usługi, dla wszystkich odbiorców.
• SLA wielopoziomowe (Multi-level SLA) - część wspólna + poziom specyficzny dla klienta lub lokalizacji (np. różne godziny wsparcia).

Dlaczego SLA bywa źle rozumiane?

• Mylenie SLA z "gwarancją braku awarii" - SLA dopuszcza awarie, ale definiuje granice i sposób kompensacji.
• Nieprecyzyjne definicje - brak jednoznacznego pomiaru prowadzi do sporów.
• Brak rozróżnienia incydentów - inne progi powinny obowiązywać dla awarii krytycznej niż dla drobnej usterki.
• SLA bez procesu - jeśli nie ma monitoringu i obsługi incydentów, SLA jest tylko deklaracją.
• Złe bodźce - jeśli rozliczasz wyłącznie "czas zamknięcia", rośnie pokusa zamykania bez realnej naprawy.

Jak ustalać SLA w praktyce?

Ustalanie SLA powinno wynikać z realnej zdolności dostarczania usługi i akceptowalnego ryzyka. Dobra procedura obejmuje:

• Identyfikację krytycznych procesów klienta i skutków niedostępności.
• Dobór metryk (SLI) i sposobu pomiaru, który jest akceptowany przez obie strony.
• Ustalenie progów dla różnych klas incydentów (np. P1/P2/P3) i godzin wsparcia.
• Określenie wyłączeń, okien serwisowych i zasad komunikacji podczas awarii.
• Spisanie konsekwencji - kredyty serwisowe, rabaty, eskalacja, opcje rozwoju usługi.

Wskazówka: SLA nie powinno być "maksymalnie ambitne", tylko "utrzymywalne". Zbyt wysokie SLA bez kosztu w architekturze i operacjach zwykle kończy się erozją zaufania.

Przykład SLA: support i incydenty

• P1 (krytyczny) - reakcja do 15 min, przywrócenie działania do 4 h, komunikat statusowy co 60 min.
• P2 (wysoki) - reakcja do 1 h, obejście lub naprawa do 24 h, komunikat co 4 h.
• P3 (średni) - reakcja do 4 h, naprawa w kolejnym wydaniu lub do 5 dni roboczych.

Takie SLA działa dobrze, gdy klasy incydentów są jednoznacznie zdefiniowane, a proces eskalacji jest realny i testowany.

Wskazówki praktyczne

• Ustal jedną metodę pomiaru i jedno źródło prawdy - inaczej dostępność będzie "inna" dla klienta i dostawcy.
• Raportuj SLA wraz z kontekstem - liczba incydentów, ich klasa, czas trwania, trend w czasie.
• Rozdziel SLO od SLA - wewnętrzny cel powinien być wyższy niż zobowiązanie kontraktowe.
• Unikaj SLA bez wyłączeń - okna serwisowe i warunki brzegowe muszą być jawne.
• Dbaj o komunikację - dla klienta często ważniejsze od samej awarii jest to, czy wie co się dzieje i kiedy będzie poprawa.
• Testuj procedury - symulacje incydentów i postmortemy ujawniają luki w realnej zdolności utrzymania SLA.

SLA (Service Level Agreement) to kontraktowy opis jakości usługi w kategoriach mierzalnych wskaźników, sposobu pomiaru oraz konsekwencji niedotrzymania poziomu. Największą wartość daje wtedy, gdy jest osadzone w realnych procesach operacyjnych i powiązane z wewnętrznymi celami (SLO) oraz miernikami (SLI). Dobrze zdefiniowane SLA zmniejsza ryzyko nieporozumień, poprawia przewidywalność współpracy i ułatwia zarządzanie jakością usługi w czasie.