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.

W analizie ryzyka dla swojego projektu oceniałem ostatnio możliwy do zaakceptowania czas downtime’u serwerów. Poza analizowaniem zajętości łącza, planowaniem zużycia pamięci, zajętości dysków (stosunek wielkości do czasu, skala: 6, 12, 24 miesiące) musiałem też przyjąć pewne akceptowalne wartości uptime. Niektórzy nazywają to po prostu SLA, ja nazywam to jedynie składową SLA (Teoria dążenia do doskonałości).

W celu dokładnej analizy ile czasu możemy poświęcić na downtime i jaki odpowiada temu poziom SLA przydatna może być poniższa tabelka. Oszczędza trochę czasu i liczenia.

Tabelka pochodzi z dokumentu Planning and architecture for Office SharePoint Server 2007, Part 2.

Firmy hostingowe, czy ogólnie usługodawcy IT, których uptime jest na poziomie 99.9% (czyli w środku tej tabeli) mogą pozwolić sobie na jedynie 86.4 sekund (minutę i 26.4 sekundy) dziennie niedziałającej usługi. Za taki poziom płaci się dużo. Wyobraźcie sobie zatem poziom 99.999% - 5.26 minuty w skali roku!