Czym są SLA i SLO?

SLA (Service Level Agreement) to uzgodniony (często kontraktowy) poziom usługi – opisuje, co dostawca gwarantuje, w jakich warunkach i jak będzie to mierzone. W SLA liczy się precyzja: zakres usługi, okno pomiaru, wyłączenia, sposób raportowania oraz konsekwencje w razie niedotrzymania.

SLO (Service Level Objective) to cel jakościowy dla usługi, wykorzystywany operacyjnie przez IT/SRE. SLO opiera się o SLI (Service Level Indicator) – czyli konkretny wskaźnik, np. dostępność krytycznej ścieżki, odsetek poprawnych odpowiedzi API czy p95 czasu odpowiedzi. SLO jest zwykle bardziej „techniczne” i ma wspierać codzienne decyzje: kiedy stabilizować usługę, a kiedy przyspieszać rozwój.

Różnica w skrócie:

• SLA: zobowiązanie wobec klienta / biznesu (często „twardsze”).

• SLO: cel operacyjny, który pomaga dowieźć SLA i utrzymać przewidywalną jakość.

W dojrzałych zespołach SLO bywa połączone z koncepcją budżetu błędów: skoro cel to 99,9% dostępności miesięcznie, istnieje ograniczona „pula” dopuszczalnych zakłóceń. Gdy budżet szybko się zużywa, priorytetem staje się stabilność (np. refaktoryzacja, testy, automatyzacja), a nie kolejne wdrożenia.

Dobra SLA zaczyna się od pytania: dla kogo jest usługa i co jest dla niego krytyczne. Dopiero potem dobiera się metryki.

Kluczowe elementy SLA:

1. Zakres usługi – co obejmuje SLA (np. portal klienta, integracje, wsparcie), a co jest poza zakresem (np. urządzenia użytkownika, łącze po stronie klienta).

2. Godziny świadczenia usługi i wsparcia – 24/7 czy np. 8/5; osobno można opisać dostępność usługi i dostępność wsparcia.

3. Metryki i definicje – np. dostępność w % w skali miesiąca, czas reakcji i czas rozwiązania incydentów (z definicją priorytetów). Unikaj ogólników typu „szybko” czy „wkrótce”.

4. Metoda pomiaru – skąd dane (APM, monitoring syntetyczny, logi), jak liczona dostępność, jaki jest próg błędu (np. „błąd transakcji” to nie tylko 500, ale też time-out).

5. Wyłączenia – planowane okna serwisowe, siła wyższa, incydenty po stronie dostawcy internetu itp. (tu warto zachować ostrożność, aby wyłączenia nie „zjadły” sensu SLA).

6. Raportowanie i przeglądy – cykliczne raporty, format, interpretacja i tryb uzgadniania zmian.

7. Ścieżka eskalacji i odpowiedzialności – kto komunikuje status, kto zatwierdza działania awaryjne, kto jest właścicielem usługi end-to-end.

8. Konsekwencje – np. kredyty serwisowe; zapisy wymagają zwykle dopasowania do polityki firmy i konsultacji formalnej.

Praktyczna wskazówka: jeśli SLA opiera się wyłącznie na „uptime serwera”, a nie na dostępności kluczowej funkcji (np. logowania lub płatności), to w krytycznym momencie okaże się niewiarygodna biznesowo.

SLO powinno wynikać z realnych potrzeb użytkowników oraz możliwości systemu. Zbyt ambitne cele generują koszt i frustrację, zbyt niskie – ryzyko utraty klientów.

Sprawdzone podejście:

1. Wybierz krytyczne ścieżki użytkownika (np. logowanie, wyszukiwanie, checkout, API integracyjne).

2. Zdefiniuj SLI, które opisuje jakość z perspektywy usługi – np. odsetek udanych transakcji, p95/p99 czasu odpowiedzi, odsetek błędów. Średnia bywa myląca; percentyle lepiej oddają realne doświadczenie.

3. Ustal okno i segmentację – miesięczne SLO może ukrywać problem krótkich, częstych degradacji; czasem lepiej dodać drugi cel (np. tygodniowy) lub segmentować po regionie/wersji.

4. Oprzyj cel o dane historyczne – wybierz target, który jest ambitny, ale osiągalny; następnie planuj redukcję ryzyk i poprawę obserwowalności.

5. Połącz SLO z decyzjami operacyjnymi – gdy „spalanie” budżetu błędów przyspiesza, włącz tryb stabilizacji: ogranicz ryzykowne zmiany, zwiększ monitoring, priorytetyzuj naprawy przyczyn źródłowych.

Przykład: dla API krytycznego w integracjach SLI to „odsetek poprawnych odpowiedzi” oraz „p95 czasu odpowiedzi”. SLO może brzmieć: ≥ 99,7% poprawnych odpowiedzi tygodniowo i p95 < 400 ms. Taki zestaw lepiej chroni doświadczenie użytkownika niż sama dostępność.

SLA/SLO działają tylko wtedy, gdy są mierzone w sposób ciągły i zamieniane na działania.

Co warto wdrożyć:

• Observability: APM, logi, trace’y oraz monitoring syntetyczny (sprawdza krytyczne ścieżki) i RUM (rzeczywiste doświadczenie użytkownika).

• Dashboardy usługowe: widok per usługa, nie per serwer; metryki SLI, trend, naruszenia, wpływ.

• Alerting oparty o SLO: zamiast „setek alarmów” – alerty związane z ryzykiem naruszenia celu (np. szybkie zużycie budżetu błędów).

• Rytm przeglądów: tygodniowo operacyjnie (incydenty, burn rate), miesięcznie zarządczo (SLA, koszty, priorytety).

• Postmortemy i backlog usprawnień: każde naruszenie celu powinno kończyć się wnioskiem i działaniem zapobiegawczym (automatyzacja, testy, poprawa monitoringów, runbooki).

Optymalizacja to nie „podkręcanie procentów”, tylko szukanie równowagi: jakość, szybkość zmian i koszt. Dobrze ustawione SLO pomaga tę równowagę utrzymać bez eskalacji i reaktywnego gaszenia incydentów.

SLA i SLO porządkują zarządzanie jakością usług IT na dwóch poziomach: SLA definiuje zobowiązania wobec klienta lub biznesu, a SLO daje zespołom operacyjny mechanizm dowożenia jakości poprzez SLI i budżet błędów. Największą wartość przynoszą wtedy, gdy są mierzone na poziomie usług i kluczowych ścieżek użytkownika, a ich wyniki realnie wpływają na priorytety zmian oraz inwestycje w stabilność.