Service Level Agreement (za wikipedią: SLA /ang./, jest to umowa utrzymania
i systematycznego poprawiania ustalonego między klientem a usługodawcą poziomu jakości usług informatycznych poprzez stały cykl obejmujący: uzgodnienia, monitorowanie usługi informatycznej, raportowanie, przegląd osiąganych wyników).
W praktyce, rozliczanie umów z określonym parametrem SL (Service Level) realizowane jest w cyklach miesięcznych lub maksymalnie kwartalnych. Dłuższe okresy dla SLA wprowadzają bardzo duży margines błędu. Chodzi o to, że SL wyrażone w % jest średnią czasu działania. 99% w skali miesiąca to zupełnie coś innego niż 99% w skali roku.
W tym drugim przypadku jest to 78 godzin kiedy serwis może nie działać. Realizacja awarii może się dokonać w jednym tygodniu, a to oznacza że serwis będzie niedostępny jednym ciągiem przez ponad 3 dni! W pozostałe dni w roku serwis będzie dział poprawnie a tym samym warunki SLA zostaną dochowane.
W pierwszym przypadku dla SLA miesięcznego taka awaria może trwać nie więcej niż 7 godzin i 12 minut.
Rozliczenie
Podstawą rozliczenia jest zawsze raport lub protokół z systemów monitorowania dołączany do comiesięcznej faktury. Jeśli takiego raportu nie otrzymujemy (nawet na wyraźnie życzenie) oznacza to, że dostawca nie realizuje zapisów umowy.
W przypadku wątpliwości zawsze można skorzystać z istniejących w sieci systemów monitorowania, tak aby na własną rękę sprawdzić czy dostawca poważnie traktuje umowę. Przykładem jest np. http://monit24.pl.
Na podstawie protokołu lub raportu o ile jest taka potrzeba następuje wyliczenie kary lub bonifikaty.
Przykładowy raport dostępności serwisu webowego, wykreowany na podstawie zewnętrznego systemu monitoringu.
Widać tutaj wyraźnie, że czas nie działania serwisu wynosił 1h 33minuty i 18 sekund, lub 0.216% ogólnego czasu w miesiącu.
Czas poprawnego działania to 99.784%
Na podstawie tej informacji, zapisy w umowie decydują o tym w jaki sposób należy rozliczyć dany okres. Często stosowaną metodą jest umieszczenie odpowiedniej tabeli w umowie hostingowej:
| Procent poprawnych Transmisji testowych |
Kara umowna |
| Większy lub równy 99,60% |
0% |
| 99,4%-99,6% |
10% |
| 99,2%-99,4% |
15% |
| 99,0%-99.2% |
25% |
| 98,0%-99.0% |
35% |
| 96 %-98% |
50% |
| 92%-96% |
70% |
| 90%-92% |
110% |
| Mniejszy lub równy 90% |
140% |
* przykładowa tabela określająca poziom kar.
W tej sytuacji, o ile serwis był objęty umową na poziomie 99.6% oznacza to że warunki zostały dochowane i usługodawca powinien otrzymać pełne zapisane w umowie wynagrodzenie.
Interfejsy Usługowe
Oprócz zewnętrznego systemu monitorowania, do procesu raportowania umowy można nakładać obowiązek utworzenia tzw. interfejsów usługowych.
Interfejs usługowy jest wirtualnym obiektem, który zawiera w sobie stan wszystkich elementów systemowych niezbędnych do poprawnego funkcjonowania serwisu/usługi.
Aby można było definiować interfejsy usługowe dostawca koniecznie musi dysponować rozbudowanym, wewnętrznym systemem monitoringu (np. SCOM 2007, HP OpenView, inne pozwalające łączyć ze sobą stany różnych obiektów).
Dobrym przykładem może być klasyczna architektura, w której działa jeden serwer aplikacyjny/webowy oraz jedna baza danych. Możemy utworzyć interfejs usługowy,
w skład którego wejdzie monitoring :
- dostępności bazy danych,
- spójności bazy danych,
- weryfikacji kont dostępowych do bazy danych,
- miejsca na serwerach baz danych,
- dostępności serwisu webowego (otwarty port 80 oraz poprawny status HTTP na żądanie pobrania),
- działanie procesu serwera web (apache/IIS),
- monitoring ogólnego stanu serwera baz danych (CPU/RAM/HDD),
- monitoring ogólnego stanu serwera WEB (CPU/RAM/HDD),
- symulacja przeglądarki i przejście określonej ścieżki na serwisie,
- dostępność urządzeń sieciowych,
- dostępność LoadBalancerów.
Tak zdefiniowany interfejs usługowy może posłużyć do zaraportowania stanu konkretnej usługi w formie logicznej zmiennej zawierającej stan true/false i może być objęty osobnym poziomem gwarancji. Forma zero/jedynkowa jest konieczna aby automatyka raportowania mogła zakwalifikować stan jako działa/nie działa.
W obrębie jednej usługi hostingowej można oczywiście wykreować znacznie więcej definicji interfejsów usługowych opisujących wirtualne usługi – wszystko w zależności od potrzeb i wymagań.
Można zatem zbudować system wynagrodzenia dostawcy w całości oparty o tzw. success fee. Oznacza to, że po zdefiniowaniu wirtualnych interfejsów usługowych, dla przykładu:
1. dostępność systemu webowego : 99.9 %
2. dostępność systemu płatniczego: 99.9%
3. dostępność systemu zamówień: 99.9%
dostawca otrzyma uzgodnione wynagrodzenie wyłącznie wtedy jeśli poszczególne interfejsy usługowe zachowają dostępność powyżej określonego SLA.
Tym samym, zleceniodawca usługi będzie miał pewność, że wszystkie elementy jego serwisu funkcjonują poprawnie bez szczegółowej analizy skomplikowanych alarmów systemów monitorowania (i rozważania na tematu klastrów, redundancji, etc).
Upraszczając w ten sposób komunikację na linii dostawca <-> klient zachowujemy przejrzystość realizacji warunków umowy.