Czym jest SLA?

SLA, czyli Service Level Agreement to rodzaj umowy, w którym operator chmury publiczny gwarantuje nam pewien poziom nieprzerwanego działania swoich usług. Pomiar ten zazwyczaj wyrażany jest w procentach rocznej, miesięcznej lub dziennej dostępności usługi gwarantowanej przez dostawcę. I choć oczywiście chcielibyśmy, aby świadczony nam serwis działał cały rok nieprzerwanie, to choćby ze względu na konieczność wykonywania cyklicznych prac serwisowych, a nie tylko na potencjalne awarie, żaden dostawca nie zapewnia stuprocentowej dostępności swoich usług w umowach.

Poniższa tabela przedstawia typowe wartości SLA, które zazwyczaj gwarantują dostawcy chmurowi dla swoich usług:

Availability %	Downtime per year	Downtime per day (24 hours)
99% („two nines”)	3 days 15 hours 39 minutes 29 seconds	14 minutes 24 seconds
99.5% („two and a half nines”)	1 day 19 hours 49 minutes 44 seconds	7 minutes 12 seconds
99.9% („three nines”)	8 hours 45 minutes 56 seconds	1 minute 25 seconds
99.95% („three and a half nines”)	4 hours 22 minutes 58 seconds	43 seconds
99.99% (“four nines”)	52 minutes 35 seconds	8 seconds

Wydaje się proste? Niestety w przypadku chmury publicznej nie jest to takie proste jakby wynikało z tej tabeli. SLA nie jest zależne od prostego stwierdzenia „działa” lub „nie działa”.

Co wpływa na SLA?

Pamiętajmy przede wszystkim, że usługi w chmurze, niezależnie od tego czy jest to Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS) czy jakakolwiek inna usługa „as-a-service” tak naprawdę nie działa ona w oderwaniu od innych usług chmurowych. Przykładowo,  aby poprawnie działała maszyna wirtualna nie tylko muszą być dostępne zasoby sprzętowe takie jak vCPU czy pamięć, ale także usługa sieciowa, za pomocą, której łączymy się z wirtualnym serwerem. Z jednej strony sama usługa sieciowa może być prosta (VNET), lub skomplikowanym połączeniem usługi vWAN i VPN Gateway. Zarówno VNET, vWAN jak i VPN Gateway mają inaczej liczone SLA i inne parametry wpływają na jego podwyższenie lub obniżenie.  

Odpowiedni poziom SLA to kwestia odpowiedniej konfiguracji i doboru usług. W Microsoft Azure znajdziemy wiele parametrów które mają zwiększyć nam niezawodność działania usługi. W przypadku sieci może być terminowanie połączenia czy usługi w różnych regionach (region) czy strefach (availability zone). Tak jak i w tradycyjnych sieciach, także i w chmurze podnoszenie poziomu niezawodności wiąże się z dodatkowymi kosztami, które musimy ponieść.

Inaczej realizowane jest SLA w usługach przechowywania danych, czyli tych z rodziny Storage. Gwarantowane parametry dotyczą zarówno czasu dostępu do danych, stopy nieudanych transakcji, jak i gwarancji, że przechowywanych informacji nie utracimy. W tym ostatnim aspekcie pamiętajmy jednak, że mamy do dyspozycji wiele mechanizmów redundancji jak Zone Redundant Storage (ZRS) czy Geo Redundant Storage (GRS) i w zależności od oczekiwanego stopnia redundancji powinniśmy zakupić odpowiednie usługi tego typu.

Umowy dotyczące gwarantowanego czasu działania usługi należy dokładnie przeczytać i zrozumieć, ponieważ w chmurze publicznej spotkamy się z konkretnymi określeniami związanymi choćby z definicją cyklu pomiaru nieprzerwanego działania usługi. Większość dostawców mierzy ten cykl w okresach miesięcznych, natomiast bardzo ważne jest sprawdzenie, kiedy ten okres się zaczyna i kończy. To wcale nie musi być pierwszy dzień miesiąca. W szczególnych przypadkach, sposób pomiaru może się różnić także pomiędzy różnymi usługami w ramach jednej chmury publicznej. Okres ten jest bardzo ważny, gdyż tylko niespełnienie przez dostawcę chmury wskazanych w SLA parametrów uprawnia nas do uzyskania rekompensaty. A pamiętajmy, że operatorzy chmur mają tak ustawione okienka prac serwisowych, aby nie zbliżyć się niedostępnościami usług do granicy SLA.

Co się dzieje, gdy SLA zostanie przekroczone?

Oczywiście, należy nam się rekompensata. Ale nie znaczy to, że dostaniemy gotówkę do ręki lub jako zwrot na kartę, z której usługa została opłacona. Jeżeli płatność za usługę już nastąpiła na koniec okresu rozliczeniowego, to w ramach rekompensaty możemy dostać pulę kredytów, które obniżą nam przyszły rachunek. Sposób wyliczania kwoty zwrotu to zupełnie inna historia i dostawcy stosują odpowiednie wzory do przeliczania należnej klientowi kwoty. Nie zawsze jest tak, że wystarczy policzyć koszt minuty działania usługi i przemnożyć go przez liczbę minut jej niedostępności. Są to bardziej skomplikowane działania, różniące się między sobą w zależności od dostawcy. Na koniec pamiętajmy, że to nie jest tak, że operator chmury sam przyjdzie do nas, uderzy się w pierś i wypłaci nam rekompensatę. To po naszej stronie należy udowodnienie, że usługa była niedostępna lub nie spełniała założonych parametrów. Dlatego warto, oprócz narzędzi monitoringowych dostępnych w chmurze, zatroszczyć się o odpowiednie monitorowanie usług z naszej strony.