ITblog

W ostatnim poście dot. zarządzania IT (SLA. Teoria dążenia do doskonałości), wspomniałem o przełożeniu SLA na koszty, co za tym idzie zwiększeniu nie tyle samych kosztów ale ryzyka biznesu na jaki są narażone usługi telekomunikacyjne i IT. Jednak żaden biznes, żaden sukces nie jest tego ryzyka pozbawiony.

W dzisiejszym przykładzie chciałbym pokazać koszty związane z zachowaniem wysokiego SLA firmy hostingowej HostMe Ltd. (jakiekolwiek podobieństwo jest przypadkowe), posiadającej 100 serwerów i 100 klientów (1 serwer na jednego klienta). Zakładam, że serwerownia firmy HostMe spełnia wszystkie standardy bezpieczeństwa i infrastruktury (klimatyzacja, autoryzowany dostęp, procedura pożarowa, UPS’y i generatory, redundancja łącz). Posiada też wykwalifikowaną kadrę monitorującą działanie serwerów i kontaktującą się z serwisem w przypadku awarii.  Firma nie gwarantuje natomiast backupu danych. Skupię się na jedynie na zarządzaniu i analizie w przypadku awarii serwerów.

Firma reklamuje swoje SLA na poziomie 99,8% uptime.

Wszystkie serwery zostały zakupione z trzyletnią gwarancją i serwisem NBD (Next Business Day), co oznacza że firma serwisująca jest w stanie naprawić serwer w ciągu następnego dnia roboczego. Koszt takiej gwarancji w przeliczeniu na jeden serwer wynosi 100 euro. Z kilkumiesięcznego doświadczenia działania firmy wynika, że awaryjność ich serwerów wynosi 5% w skali roku, gdzie w skład tych 5% awaryjności wchodzą: 80% awarie dysków twardych, 60% awarie układów pamięci, 20% awarie kart sieciowych i płyt głównych (karty sieciowe są zintegrowane na płycie) i 20% awarie zasilaczy (jak widać, dane te nie sumują się do 100%, bo jeden serwer może mieć więcej niż jedną awaryjną cześć: wadliwe zasilacze palą płyty i pamięci, wadliwa płyta może zniszczyć pamięć, etc).
5% w skali roku to 5 serwerów nieczynnych przez minimum 24 godziny, nie wliczając weekendów (gdzie w przypadku awarii w piątek serwer będzie online dopiero w poniedziałek, wyjątek: piątek po 5PM).  Przyjmując, że trafiło się 5 awarii, z czego jedna w weekend, 5 serwerów było nieczynnych przez 168 godzin w skali roku, co daje 1.92% całego czasu uptime. Z punktu widzenia firmy HostMe Ltd., ich SLA wynosi 98.08% dla całej serwerowni, z punktu widzenia klienta, którego serwer pechowo przestał działać, otrzymujemy wynik 99.73% lub 99.18%, gdy awaria miała miejsce w piątek przed godziną 5PM (naprawa po 3×24 godzinach w poniedziałek; jeśli awaria ma miejsce w piątek po 5PM, sobotę lub niedzielę - serwis przyjmuje zgłoszenie w poniedziałek, co daje w najgorszym przypadku 4×24 godziny czekania na rozwiązanie problemu; z wcześniejszych kalkulacji wykluczam ekstremalny przypadek piątku po 5PM).
Nie jest aż tak źle! Choć dla firmy końcowej płacącej w końcu niemałe pieniądze za dobrą usługę, 72 godziny braku obecności ich strony www w Internecie to dość znaczny problem dla PR’u, działu sprzedaży, a co za tym idzie i dla zarządu firmy. Brak poczty to już problem wszystkich pracowników klientq.

Co można zatem zrobić by poprawić ten wynik? Doświadczeni powiedzą, że najlepszym rozwiązaniem jest zakup serwera cache działającego jako frontend, który przechowuje wszystkie strony klientów, a w przypadku awarii po prostu udostępniający ostatnią dostępną statyczną treść. To rozwiązanie jest dobre, ale tylko dla WWW/FTP. Inne to cluster z DNS round robin i temu podobne. Sprawdźmy jednak czy da się poprawić nasz wynik bez zakupu dodatkowego serwera.

Celem jest zachowanie 99.8% SLA dla klienta końcowego. Oznacza to maksimum 17.52 godzin braku dostępności serwera.

1. Gwarancja (SBD) - przy 17.52 godzinach maksymalnego downtime rozsądnym wydaje się upgrade typu gwarancji na SBD (Same Business Day), co oznacza usunięcie awarii najpóźniej w przeciągu 14 godzin (zgłoszenie do 5PM, rozwiązanie na drugi dzień po 7 AM). W przypadku awarii w piątek to wciąż oznacza czekanie do poniedziałku. Przy 5 awariach, jedna w weekend daje nam to wynik 1.35% downtime w skali roku, dla klienta będzie to 99.84% jeśli awaria miała miejsce w ciągu tygodnia, 99.29% w weekend. Jednak koszt takiego upgrade to dodatkowe 150 euro od serwera. 0.11% (taki jest zysk na SLA) kosztuje 15,000 euro w skali roku.
2. Gwarancja 4HRS - jest to najdroższy rodzaj gwarancji oferowany przez firmy serwisowe. Zapewnia rozpoczęcie usuwania każdej awarii w przeciągu 4 godzin od momentu zgłoszenia. W tym przykładzie niech będzie to 6 godzin (zgłoszenie, przyjazd technika, diagnostyka, usunięcie awarii) bo z doświadczenia wiem, że żadnego problemu nie da się usunąć w ciągu 4 godzin korzystając z firm serwisowych. 6 godzin przy naszym 5% współczynniku awaryjności to 99.66% uptime całej serwerowni i 99.93% dla klienta końcowego! Z takim wynikiem wiąże się jednak koszt dodatkowych 300 euro od serwera. W najlepszym przypadku nasze SLA rośnie o 1.58% kosztem 30,000 euro.
3. Części zamienne i koszty osobowe - 5% awaryjności: 80% awarie dysków twardych, 60% awarie układów pamięci, 20% awarie kart sieciowych i płyt głównych (karty sieciowe są zintegrowane na płycie) i 20% awarie zasilaczy, oznacza to nic innego jak 4 dyski, 1 płyta główna, 3 układy pamięci, 1 zasilacz w częściach zapasowych, czyli około 2000 euro. Do tego należy doliczyć min. 3 dodatkowe wyszkolone osoby (pokrycie 24h na zmianach, praca także w weekendy), które będą w stanie wymienić awaryjną część w przeciągu 4 godzin. Koszty osobowe: 3 x 30,000 euro + 2,000 euro = 92,000 euro. Zysk na SLA: 4 godziny downtime, 99.77% dla całej serwerowni, 99.95% dla klienta końcowego. 1.69% wzrost SLA w przypadku awarii w weekendy (i w nocy!) i jedynie 0.23% wzrost w ciągu normalnych godzin roboczych. Reasumując: najlepszy wynik 1.69% wzrostu SLA kosztuje 92,000 euro w skali roku.

Dotknąłem tylko wierzchołka tej góry lodowej jaką jest analiza związana z kosztami zarządzania poziomem jakości usług. Jak widać, zapewnienie 99.8% SLA to koszt minimum 30,000 euro (opcja pierwsza wydaje się być dobra, ale nie w weekendy!).

W praktyce jednak stosuje się zarówno jedno z rozwiązań, które wymieniłem powyżej, łączenie z serwerami cache, redundancją serwerów pocztowych (drugi MX), rozwiązaniami backup (disk image, taśmy) czy cluster. W wypadku zastosowania redundancji zmniejszamy ryzyko wystąpienia awarii, tym samym zwiększamy prawdopodobieństwo zachowania naszego SLA na ustalonym poziomie.

SLA jest w końcu tylko umową między firmą a usługobiorcą i to od firmy zależy ile zachowanie SLA będzie ją kosztowało.