ITblog

SLA, jako umowa między usługodawcą, a klientem może zawierać szereg uzgodnień dot. jakości usług. Jedną z nich jest, moim zdaniem bardzo ważna, definicja planowego downtime‘u.

Czym jest planowy downtime? Jest to czas, najczęściej w środku nocy, jaki jest wymagany przez administratorów systemów do instalacji nowego oprogramowania czy łatania już istniejącego, zmian konfiguracyjnych sprzętu i oprogramowania, które wymagają ponownego rozruchu i inne elementy, które w znaczny sposób zakłócą pracę serwisów, za które płaci klient (co oznacza obniżenie czasu dostępności usług).

Wiemy, że nasze systemy wymagają downtime’u od czasu do czasu. W przypadku Microsoftu, jest to min. raz w miesiącu (tzw. patch Tuesday), kiedy ukazują się krytyczne bądź ważne poprawki do systemów i aplikacji, które najczęściej wymagają restartu “łatanego” systemu. Przy założeniu, że byłoby to 10 minut w skali miesiąca na restart jednej maszyny daje to całkiem przyzwoity poziom 99.97717% dostępności w skali roku. To jest jednak sytuacja idealna, kiedy łatamy tylko system operacyjny. Gorzej jeśli po drodze mamy jeszcze Exchange, SQL, IIS i inne systemy. Czas potrzebny do zainstalowania wszystkich poprawek sięga wtedy 20 minut, 30 minut, etc, a nasz czas dostępności coraz bardziej się kurczy, a wydłuża się czas, kiedy aplikacja klienta nie działa.

Co zatem robić w przypadku, kiedy musimy poprawki instalować, a jednocześnie musimy zapewnić określoną przez SLA i bardzo wyżyłowaną dostępność na poziomie 99.99%? Można poradzić sobie dwojako: poprzez odpowiednią klauzulę w umowie o poziomie usług albo poprzez rozwiązania techniczne (clustering).

Opcja pierwsza dla klienta końcowego wygląda dość kuriozalnie: system nie działa, ale o tym wiem i się na to zgodziłem (planowy downtime) albo system nie działa, ale się na to nie godziłem (nieplanowany downtime) - tak czy inaczej, w obu przypadkach usługa kliencka jest niedostępna. To tak, jak kupić samochód i godzić się, że co miesiąc nasz silnik się wyłączy na 5 minut (lepiej byśmy nie byli wtedy na autostradzie).

Zawieranie klauzuli planowego downtime‘u w umowie SLA jest wg. mnie po prostu nieeleganckie i wprost pokazuje, że firma tnie koszty i nie chce inwestować w rozwiązania zapewniające ciągłą dostępność (jak wspomniany przeze mnie wyżej clustering). Jeśli jednak, usługodawcy zdecydują się na wykorzystanie technik HA (high availability), mogą szczycić się w umowach z klientami poziomem 5*9, czyli 99,999%, gdzie 0,001% jest już jedynie współczynnikiem ryzyka.

A co mają zrobić administratorzy i menedżerowie IT? Zasiąść za arkuszem kalkulacyjnym i zobaczyć czy ich firmę stać na rozwiązania HA i kiedy poniesiony koszt się zwróci. A zapewniam, prędzej czy później się zwróci.