Polski informatyk w Irlandii
Kilka osób w komentarzach do poprzedniego postu nt. metod oszczędzania papieru w mojej firmie, zapytało mnie o szczegóły tego rozwiązania - konkretnie czy jest to coś stworzonego przez nas/dla nas czy też gotowiec, który można zakupić.
Po kilku tygodniach poszukiwania i wypytywania udało mi się znaleźć firmę, która dostarczyła to rozwiązanie. jest to firma SafeCom z Danii. Ich stronę możecie znaleźć pod adresem http://www.safecom.dk/.
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.
Kilka tygodni temu metoda drukowania dokumentów w naszych budynkach w Dublinie uległa znacznemu przeobrażeniu. Firma wyłożyła “kilka euro” i dodała do wszystkich drukarek moduł czytnika kart magnetycznych, tak by można było się do drukarek … logować za pomocą naszych badges. Od tego momentu przestaliśmy drukować “do drukarki”, ale drukujemy “do serwera”.
Jak to działa?
W standardowej i znanej wszystkim wersji drukowania do drukarki, komputer komunikuje się z drukarką poprzez serwer druku, czyli lokalny albo zdalny spooler. Jednak czy używasz drukarki podpiętej bezpośrednio do komputera czy poprzez sieć, zawsze komunikujesz się (prawie) bezpośrednio z drukarką. Wymaga to instalowania sterowników dla każdej drukarki z osobna, na której chcesz drukować.
A teraz, wyobraźmy sobie inny scenariusz. Zamiast klikać na drukarkę, wybierasz serwer, na który twoje dokumenty mają być “wydrukowane”. Później idziesz do najbliższej drukarki, logujesz się za pomocą karty magnetycznej (której dane są zintegrowane z Active Directory) i ściągasz z serwera swoje dokumenty na tę właśnie drukarkę.
Schemat dla obu scenariuszy wygląda podobnie, poza drobnym szczegółem w postaci czytników kart magnetycznych bądź chipowych zainstalowanych na każdym urządzeniu.
Jest kilka bardzo znaczących zalet przemawiających za takim rozwiązaniem. Przede wszystkim daje to możliwość drukowania na najbliższej drukarce, bez konieczności znajomości ich nazw, portów, serwerów wydruku i instalowania sterowników. W każdym miejscu budynku (a nawet w innych) gdzie jest dostęp do sieci po prostu drukujesz do serwera, który raz zapamiętany na komputerze nie ulega zmianie.
Poprzez taką metodę drukowania można bez obaw drukować poufne dokumenty - ich wydruk wymaga indywidualnej, niepowtarzalnej i identyfikowalnej poprzez Active Directory karty magnetycznej.
A najważniejsze: oszczędza się dużo papieru! Jeśli zapomni się o dokumencie, który właśnie się wysłało na drukarkę - paper się nie zmarnuje, bo to wymaga obecności drukującego przy drukarce.
Jedynym mankamentem takiego rozwiązania jest konieczność używania tych samych sterowników do wszystkich drukarek, co w rezultacie sprowadza się do wykorzystywania tego samego modelu w całej firmie. Dla innych modeli (np. kolorowych czy wielkoformatowych) konieczne jest tworzenie nowych kolejki.
Od kilku tygodni wokół drukarek nie ma już cudzych druków, poufnych dokumentów, nieodebranych albo zapomnianych papierów. Pozbyliśmy się problemu “gdzie jest ta drukarka”. Rewelacja!
A Wy? Jak drukujecie w swoich firmach?
Dziś natknąłem się na informację, która z jednej strony mnie rozśmieszyła, a z drugiej poważnie zaniepokoiła. W tejże informacji było użyte następujące sformułowanie:
SLA is lower this week due to [...] impacting our system performance.
Ktoś pomylił sobie słówko availability z pojęciem SLA, które oznacza Service Level Agreement. I to ostatnie jest porozumieniem między klientem a usługodawcą o poziomie świadczonych usług, więc nie może ulegać zmianie bez re-negocjacji z klientem!
SLA jest wyznacznikiem świadczenia usług, jest poziomem którego dotrzymywanie jest bardzo ważnym elementem jakości tychże usług. W najgorszym przypadku jest celem, do którego usługodawcy dążą. Tym bardziej SLA, które zmienia się co tydzień jest wielkim nieporozumieniem!
P.S. Jeśli ktoś myśli, że to był Eircom, jest w błędzie 
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.
| Uptime | Daily | Monthly | Yearly |
| 95% | 72.00 minutes | 36 hours | 18.26 days |
| 99% | 14.40 minutes | 7 hours | 3.65 days |
| 99.9% | 86.40 seconds | 43 minutes | 8.77 hours |
| 99.99% | 8.64 seconds | 4 minutes | 52.60 minutes |
| 99.999% | 0.86 seconds | 26 seconds | 5.26 minutes |
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!
Ostatnie komentarze