SLA (Service Level Agreement)
SLA (Service Level Agreement)
Zasada realizmu: SLA to nie jest obietnica, że system nigdy się nie zepsuje. To kontrakt, który mówi: „Wiemy, że systemy czasem padają, więc ustalmy, jak szybko go podniesiemy i ile nam zapłacicie, jeśli się spóźnimy”.
Czym jest SLA?
SLA (Service Level Agreement), czyli umowa o gwarantowanym poziomie świadczenia usług, to fundament relacji w świecie IT i outsourcingu. Definiuje ona mierzalne parametry usługi, takie jak dostępność (uptime), wydajność oraz standardy wsparcia technicznego.
Bez dobrze skonstruowanego SLA, klient kupuje „kota w worku”, a dostawca ryzykuje nieograniczone roszczenia w przypadku awarii.
Kluczowe wskaźniki w SLA
Większość umów SLA opiera się na kilku krytycznych metrykach:
1. Dostępność (Uptime)
Wyrażana w procentach w skali miesiąca lub roku. Legendarny standard „pięciu dziewiątek” (99.999%) oznacza, że system może być niedostępny tylko przez ok. 5 minut w skali roku.
| Dostępność | Dopuszczalny przestój (miesięcznie) | Kontekst biznesowy |
|---|---|---|
| 99.0% | ~7 godzin 18 minut | Systemy wewnętrzne, mniej krytyczne. |
| 99.9% | ~43 minuty 49 sekund | Standard rynkowy dla większości aplikacji SaaS. |
| 99.99% | ~4 minuty 23 sekundy | Bankowość, e-commerce o wysokim obrocie. |
2. Czasy reakcji i rozwiązania (Response & Resolution Time)
Definiowane zazwyczaj w zależności od priorytetu błędu:
- Critical (P1): Np. reakcja w 15 minut, rozwiązanie w 2 godziny.
- Minor (P3): Np. reakcja w 1 dzień roboczy, rozwiązanie w tydzień.
3. Okna serwisowe (Maintenance Windows)
Czas, w którym dostawca może prowadzić prace konserwacyjne (zazwyczaj w nocy lub w weekendy), a który nie jest wliczany do czasu niedostępności.
Trójca SLA: SLA vs SLO vs SLI
W nowoczesnym podejściu (SRE - Site Reliability Engineering) rozróżniamy trzy pojęcia:
- SLA (Agreement): Co obiecujemy klientowi? (Kontekst prawny/biznesowy).
- SLO (Objective): Jaki cel stawiamy sobie wewnętrznie? (Np. 99.95%, by zawsze mieć zapas względem SLA 99.9%).
- SLI (Indicator): Co faktycznie mierzymy? (Np. czas odpowiedzi serwera z ostatnich 5 minut).
Konsekwencje: Kredyty serwisowe (Service Credits)
SLA bez kar jest tylko „listem intencyjnym”. Najczęstszą formą rekompensaty są kredyty serwisowe – dostawca zwraca klientowi procent miesięcznego abonamentu za każdą godzinę lub procent naruszenia progu dostępności.
Rola Analityka w definiowaniu SLA
Analityk biznesowy pełni rolę mediatora między marzeniami biznesu a brutalną rzeczywistością technologii i budżetu:
- Analiza kosztów przestoju: Jeśli godzina awarii kosztuje firmę 100 000 PLN, to warto zapłacić za SLA na poziomie 99.99%. Jeśli 100 PLN – wystarczy 99.0%.
- Weryfikacja mierzalności: Analityk musi upewnić się, że parametry wpisane w SLA da się obiektywnie zmierzyć za pomocą narzędzi monitoringu.
- Definiowanie priorytetów: Co jest błędem krytycznym (blokującym sprzedaż), a co tylko kosmetycznym?
Typowe błędy i pułapki
- ❌ “Efekt Arbuza”: Z raportów wynika, że wszystko jest zielone (wskaźniki techniczne w normie), ale klient jest “czerwony” z wściekłości, bo kluczowa funkcja nie działa, choć serwer „stoi”.
- ❌ Brak wyłączeń: Zapominanie o wyłączeniu awarii spowodowanych przez siłę wyższą lub błędy po stronie klienta (np. padnięcie łącza internetowego w biurze klienta).
- ❌ Obiecywanie 100%: W IT nie istnieje 100% dostępności. Ktoś, kto to obiecuje, prawdopodobnie nie czytał drobnego druku w swojej własnej umowie.
Podsumowanie
SLA to narzędzie zarządzania ryzykiem. Pozwala obu stronom spać spokojniej – dostawca wie, jakie ma obowiązki, a klient wie, na co może liczyć i co dostanie, gdy sprawy pójdą źle. Dobrze wynegocjowane SLA to nie bat na dewelopera, ale fundament profesjonalnej współpracy.
Powiązane pojęcia:
Kliknij w pojęcie, aby przejść do jego definicji w słowniku
Inne pojęcia ze słownika
Diagram Czynności (Activity Diagram)
Behawioralny diagram UML służący do modelowania przepływu sterowania i danych w systemie lub procesie biznesowym. To taki flowchart na sterydach.
Czytaj więcej →Acceptance Criteria (AC)
Szczegółowe warunki, które musi spełnić dana funkcjonalność, aby mogła zostać uznana za poprawną i zaakceptowana przez Product Ownera.
Czytaj więcej →RFP
Dokument sporządzany przez organizację w celu ogłoszenia przetargu na zakup produktu, usługi lub rozwiązania, określający wymagania i kryteria oceny ofert.
Czytaj więcej →
Latarnia Analizy