ITIL blisko nas, czyli zarządzanie ciągłością dostępnością

Jadwiga Gnybek Jadwiga_Gnybek@nofer.lodz.pl

 

Za nami już lwia część procesów ITIL. W poprzednim numerze gazety omówiliśmy zarządzanie zmianą i konfiguracją. Teraz czas na coś trudniejszego, czyli zarządzanie ciągłością i dostępnością.

 

Zarówno ciągłość pracy systemu, jak i jego dostępność są pojęciami intuicyjnie zrozumiałymi. Kłopot pojawia się, gdy staramy się uszczegółowić co to znaczy, że system pracuje na przykład z zadawalającą dostępnością lub że pracuje w sposób ciągły. Sprawa niewiele poprawia się jeśli zapytamy, czy dostępność naszego systemu osiąga zadawalającą klienta wartość 95%. A już dramat zupełny rozpoczyna się w momencie, gdy zaczynamy dyskutować dlaczego tylko lub aż 95%. Ale spróbujmy zmierzyć się z tym problemem systematycznie.

Czym jest więc zarządzanie ciągłością?

Zarządzanie ciągłością, a właściwie w pełniej nazwie Zarządzanie Ciągłością Usług IT (Continuity Management), to – bardzo mądrze mówiąc, proces stanowiący wsparcie dla procesu ciągłości biznesu (Business Continuity Process). W bardziej przystępnej formie można by to zdefiniować jako zbiór działań podejmowanych w celu przywrócenia pracy systemu, jeśli praca ta na skutek awarii została przerwana. Najważniejszym parametrem tego procesu jest zatem nie tyle fakt umiejętności przywrócenia systemu do życia, ale gwarantowana prędkość realizacji tych działań. Teraz już jakby jesteśmy bliżej domu.

Zakładając, że zadaniem systemów informatycznych jest wspieranie procesów biznesowych (takich jak sprzedaż czy produkcja), ciągłość pracy staje się w dość oczywisty sposób jednym z ich podstawowych parametrów. W nowoczesnych procesach biznesowych, komputer i uruchamiane na nim systemy informatyczne stanowią wszak podstawowe narzędzie pracy dla – jeśli nie większości, to dużej części pracowników. Dlatego też czas, w jakim informatycy są w stanie przywrócić do pracy dotknięty awarią system, staje się parametrem krytycznym – nie tylko dla informatyki i informatyków, ale również menedżerów zarządzających biznesowymi działami.

Jak zapanować nad ciągłością?

Awarie jak wiadomo są, i w najbliższym czasie nadal będą zdarzeniem losowym, o nie dającym się przewidzieć przebiegu. Podstawowym zadaniem, jakie stawia przed sobą proces zarządzania ciągłością jest to, aby tego samego nie można było powiedzieć o usuwaniu skutków awarii. O ile przyczyn awarii może być wiele, o tyle ich skutków jest zwykle znacznie mniej. System jest niedostępny dla użytkowników całkowicie lub częściowo. Dla tak prosto zdefiniowanych skutków wystarczy tylko nakreślić kilka scenariuszy przywracania częściowej lub całkowitej sprawności, z jednoznacznym określeniem maksymalnego czasu, jaki na przywrócenie systemu do życia będzie potrzebny.

Innym sposobem podejścia do tematu minimalizacji strat, jakie firma może ponieść z powodu awarii systemu informatycznego, jest budowa scenariuszy minimalizujących wpływ awarii poprzez alternatywne scenariusze realizacji procesów biznesowych. Oczywiście, nie jest to sprawa prosta, a czasem nawet niemożliwa. Zawsze jednak pamiętać warto, że świadomość poziomu ryzyka i wypracowane zawczasu mechanizmy zarządzania tym ryzykiem, mogą być wartością samą w sobie. Dają one bowiem poczucie profesjonalnego panowania nad firmą znajdującą się w sytuacji kryzysu. Innymi słowy: nie da się zapanować nad losowymi przyczynami powstawania awarii, ale da się zaplanować skuteczne i szybkie metody usuwania jej skutków.

Na czyjej to wszystko głowie?

Zarządzanie Ciągłością pokazuje (jak mało który proces ITIL), jak istotną dziedziną aktywności jest utrzymywanie w produkcji systemów informatycznych. Szczególnie dobitnie odzwierciedla to lista ról tego procesu. Trzeba bowiem pamiętać, że standardową sytuacją obsługiwaną przez ten proces jest sytuacja kryzysu. Stąd oczywistym jest już fakt, że role w procesie zarządzania ciągłością rozdzielane są nie tylko pomiędzy pracowników działu informatyki. Zapewnienie odpowiednio szybkiej zdolności decyzyjnej procesu wymaga zaangażowania do realizacji zadań najwyższych szczebli zarządzania firmy z jej prezesem na czele. W sytuacji rozległego zawału systemów informatycznych, kluczowe decyzje powinien często podejmować zarząd firmy. Szybką realizację zadań wymagających często uruchomienia dodatkowych zasobów finansowych i ludzkich, też trudno by było scedować li tylko na pracowników działu informatyki.

Tak więc w naturalny sposób wędrujemy w dół drabiny struktury organizacyjnej naszej firmy. Jeśli dyrektorzy podlegli zarządowi mają w strukturze niższy szczebel kierowniczy, zadania realizowane w obliczu kryzysu są dekomponowane na mniejsze moduły. Czasem na tym szczeblu organizacji powstają zespoły antykryzysowe, nakierowane na rozwiązanie konkretnych problemów. Na to wszystko trzeba jeszcze nałożyć sprawny system komunikacji i możemy powiedzieć, że firma nasza przygotowana jest do stawienia czoła kryzysowi.

Warto jednak w tym momencie uświadomić sobie, że opisanej powyżej struktury nie można utworzyć w firmie, która nie posiada świadomości realizowanych procesów biznesowych. Świadomość ta jest bowiem niezbędna do dwóch rzeczy: po pierwsze, do uświadomienia zarówno pracownikom jak i kierownictwu firmy, jakie miejsce i rolę w procesie biznesowym odgrywają oni sami i realizowane przez nich zadania. Po drugie, do wskazania czynników, które mogą działanie tego procesu zakłócić lub przerwać. Skąd już krok do analizy ryzyka, Planu Ciągłości Biznesu i Planu Ciągłości usług IT.

Plan Ciągłości Biznesu (Business Continuity Plan – BCP)

Plan utrzymania realizacji zadań, zaliczanych do kluczowych obszarów biznesowych (core business) oraz scenariusze działań, mających na celu w najkrótszym możliwym terminie przywrócenie do normalnej aktywności zarówno kluczowych jak i pomocniczych procesów przedsiębiorstwa.

Plan ciągłości usług IT (IT Service Continuity Plan – ITSC Plan)

Plan działań, mających na celu informatyczne wsparcie realizacji kluczowych obszarów biznesowych oraz scenariusze działań, mające na celu w najkrótszym możliwym terminie przywrócenie do normalnej aktywności systemów informatycznych wspierających realizację zarówno kluczowych jak i pomocniczych procesów przedsiębiorstwa.

A po co to wszystko?

Na pewno nie tylko ku uciesze informatyków. Tak, jak szeroki jest krąg zainteresowań procesu zarządzania ciągłością, podobnie szeroki wachlarz korzyści rozpościera przed firmą jego wdrożenie. Umiejętność oszacowania i zarządzania ryzykiem przerwania procesów biznesowych firmy jest bowiem dobrem, które wykorzystać możemy przy bardzo wielu okazjach. Jeśli bowiem ciągłość świadczenia wsparcia informatycznego dla procesów biznesowych jest istotnym elementem gwarantującym ciągłość realizacji kluczowych procesów biznesowych firmy, to przekłada się to bezpośrednio na zdolność firmy do realizacji zobowiązań zaciągniętych w stosunku do swoich klientów, a więc na zdolność do zarabiania pieniędzy.

I tu dochodzimy do sedna sprawy. Zdolność firmy do realizacji procesów biznesowych to zdolność do zarabiania pieniędzy, którą warto umieć wykazać w najróżniejszych okolicznościach. Zdolność ta może być brana pod uwagę podczas rozpatrywania oferty naszej firmy na realizację nowego dużego kontraktu, może też przydać się podczas negocjacji warunków ubezpieczenia od ryzyka prowadzenia działalności gospodarczej. Może pomóc nam przejść audyty instytucji dbających o przestrzeganie obowiązujących naszą firmę norm i uregulowań prawnych.

Patrząc na sprawę bardziej przyziemnie, określenie ryzyk zagrażających ciągłości pracy systemów informatycznych i zbudowanie wiarygodnych scenariuszy działań w sytuacjach kryzysowych, znacząco łagodzi i cywilizuje kontakty pomiędzy działem informatyki, a pozostałymi jednostkami organizacyjnymi firmy. Jednostki realizujące zadania biznesowe dowiadują się więcej o ograniczeniach, w jakich funkcjonują systemy informatyczne wraz z utrzymującymi je przy życiu informatykami. Ci ostatni natomiast poznają niuanse procesów biznesowych oraz wynikające z tego priorytety. A to właśnie one kształtować powinny zarówno kierunki bieżących działań informatyki, jak i kolejność działań podejmowanych w obliczu kryzysu.

Skutkiem ubocznym (choć jakże miłym), może być tu również pozyskanie budżetu na projekty podnoszące niezawodność infrastruktury informatycznej.

To tyle na temat pierwszego z omawianych dziś procesów zarządzania ciągłością; przyjrzyjmy się teraz bliżej zarządzaniu dostępnością.

Po co zarządzać dostępnością?

Zanim odpowiemy na to fundamentalne pytanie, zastanówmy się czym w świetle ITIL jest dostępność – oczywiście dostępność systemu informatycznego. W najprostszej definicji dostępność (Availability) to procent uzgodnionych godzin świadczenia usługi, w których usługa jest dostępna. Trzeba uczciwie przyznać, że przytoczenie tej definicji nie na wiele się zdało.

Niezawodność (Reliability) – zdolność zapobiegania awariom i umiejętność zapewniania ciągłości świadczenia usług, bez przestojów.

Możliwość utrzymania (Maintainability) – zdolność do przywracania usługi po awarii do stanu normalnego działania.

Możliwość świadczenia usług (Serviceability) – wsparcie, którego udzielają związani umowami dostawcy zewnętrzni, dostarczający komponenty infrastruktury IT.

Na początek spróbujmy zrozumieć, co oznacza, że system jest dostępny. Intuicyjnie rzecz biorąc oznacza to, że użytkownicy mogą z niego korzystać. Z pewnością to prawda. Czy jednak system działający stabilnie i wydajnie w środku nocy jest systemem dostępnym dla użytkowników pracujących w regularnych godzinach biurowych? Nie! W rozumieniu ITIL system informatyczny jest dostępny wtedy, gdy spełnia funkcjonalne i wydajnościowe wymagania użytkowników w godzinach przez tychże użytkowników wskazanych.

Zobrazujmy to na banalnym przykładzie. Trzynastego w piątek nasz ulubiony system działał nieprzerwanie od godziny 00:00 do 08:00, po czym wraz z pojawieniem się pierwszego użytkownika biznesowego uległ awarii, której usuwanie trwało do godziny 16:00. Następnie system działał bez przerw do godziny 24:00, co daje mu w obrębie doby dostępność na poziomie 67%. Z punktu widzenia użytkownika, system natomiast był niedostępny w 100%, ponieważ w „biurowych” godzinach pracy jego dostępność wynosiła 0%. Innymi słowy, system powinien być uznany za dostępny tylko wtedy, kiedy jego użytkownicy oczekują nieprzerwanej i wydajnej pracy. Oczywiście pojęcie pracy nieprzerwanej i wydajnej wymaga sprecyzowania – niemal dla każdego systemu z osobna. A nad zapewnieniem owej dostępności czuwa właśnie proces Zarządzania Dostępnością czyli Availability Management.

Jak widać, cele stawiane przed tym procesem znacząco niewolą fantazję informatyków. System informatyczny musi być już nie tylko wydajny i funkcjonalny, czyli jednym słowem działający. On ma być działający dokładnie wtedy, kiedy jego użytkownicy tego sobie życzą!

Czy to źle? To zależy. Każdy kij bowiem podobno ma dwa końce. Z jednej strony, wymusza to na informatyce cykl pracy dyktowany rytmem realizacji procesów biznesowych, co w zasadzie jest dość oczywiste i trudne do oprotestowania. Z drugiej strony, może być skutecznym argumentem w dyskusji na temat kosztów utrzymania systemów informatycznych w zestawieniu z dającymi się udokumentować oczekiwaniami użytkowników.

Powróćmy do omawianego wcześniej przykładu. Jeśli użytkownik naszego systemu zwykle pracuje w godzinach 8.00 – 16.00 , w tych też godzinach dział informatyki powinien zapewnić dostępność systemu niezbędnego danemu pracownikowi. Co zrobić, gdy pracownik ów z przyczyn nieznanych zaspał, przyszedł do pracy na 11-tą i przeprosiwszy szefa ustalił, że za karę będzie dziś pracował do 19-tej? Czy nasz system ma obowiązek być w pełni wspierany przez informatyków „po godzinach” i kto za te nadgodziny zapłaci? To – jakże podchwytliwe pytanie, stanowi czasem jedyną szansę dla pracowników informatyki na wyjście z pracy po przepracowaniu ustawowych ośmiu godzin. Zawsze bowiem znajdzie się jeden lub dwóch miłośników pracy po godzinach, którzy mogą być rozczarowani brakiem wsparcia dla używanych przez nich systemów informatycznych.

Jedno trzeba jednak nie tylko wiedzieć ale i głośno artykułować. Wsparcie systemów informatycznych kosztuje! Trzeba zatem świadomie zarządzać generowaniem takich zapotrzebowań. Z drugiej strony tego samego medalu, warto wiedzieć dokładnie, na jakim poziomie świadczona jest przez dział informatyki usługa polegająca na utrzymywaniu we właściwej kondycji systemów informatycznych. Każda przerwa w pracy sytemu w godzinach pracy pracowników jednostek biznesowych, to strata. Strata wynikająca z pracy niewykonanej przez pracowników, a opłaconej w pensjach. Starta związana z nie wywiązaniem się z oczekiwań klientów firmy lub z niemożności podjęcia kolejnych zleceń.

Stąd już blisko do genialnie prostej myśli. Celem działań procesu zarządzania dostępnością jest znalezienie złotego środka pomiędzy oczekiwaniami biznesu, a możliwościami informatyki. Pomiędzy kosztami i stratami wynikającymi z braku dostępności podstawowego (przeważnie) narzędzia pracy naszej firmy.

I to by na dzisiaj było wszystko. Następnym razem zastanowimy się po co to wszystko? Zajmiemy się bowiem umowami o świadczenie usług informatycznych, zawieranymi pomiędzy informatyką a biznesem.