ITIL blisko nas czyli zarządzanie zmianą i konfiguracją

Jadwiga Gnybek Jadwiga_Gnybek@nofer.lodz.pl

W 39 numerze gazety PLOUG omówiliśmy proces zarządzania incydentami i problemami. Dziś czas na kolejne dwa procesy przebiegające przez sam środek biurka administratora systemu informatycznego. Omówimy dziś zatem czym jest i do czego służy proces zarządzania zmianą i konfiguracją.

 

Zarządzanie zmianą i konfiguracją infrastruktury informatycznej to podstawowe procesy zapewniające równowagę pomiędzy potrzebą wprowadzania zmian do systemów informatycznych, a wymogiem ich stabilnej i ciągłej pracy.

Oczywiście wszyscy mamy głębokie przekonanie, że planujemy i panujemy nad wprowadzanymi w systemach informatycznych zmianami. W najprostszej formie polega to na rejestracji poważniejszych prac prowadzonych na systemach: wersjonujemy więc produkowany software i staramy się informować użytkowników aplikacji o planowanym grafiku prac. Nie od dziś jednak wiadomo, że liczba wprowadzonych zmian i aktualnych konfiguracji rośnie w postępie geometrycznym w stosunku do liczby eksploatowanych systemów. Skalę trudności zwiększa również wzajemna wymiana informacji pomiędzy systemami, a więc ich wzajemna co do ciągłości pracy zależność. Ale abstrahując od wielkości administrowanej przez nas infrastruktury informatycznej, wszystkie wymienione wcześniej czynności stanowią element procesu zarządzania zmianą i procesu zarządzania konfiguracją.

Czym jest więc Zarządzanie Zmianą?

Zgodnie z definicją metodyki ITIL, celem procesu Zarządzania Zmianą jest wdrożenie zatwierdzonych zmian sprawnie i przy zachowaniu ryzyka możliwego do zaakceptowania z punktu widzenia zarówno istniejących, jak i nowych, przyszłych usług IT.

Innymi słowy proces ten wymusza na nas myślenie perspektywiczne. Jeśli wiemy, że system nasz wymaga zmiany, musimy dobrze zastanowić się w jaki sposób wykonać ją jak najbezpieczniej z punktu widzenia ciągłości pracy systemu. Musimy zadać sobie szereg niepopularnych w gronie informatyków pytań:

  • Czy wprowadzana przez nas zmiana może mieć wpływ na inne systemy?
  • Czy wiemy w jakim stopniu wpłynie ona na dostępność i wydajność innych systemów (aplikacji)?
  • Czy ewentualne negatywne skutki wprowadzanej zmiany są akceptowalne przez użytkowników systemów – zarówno tych podlegających zmianie jak i tych mogących w skutek tej zmiany ucierpieć?
  • Czy dokładnie wiemy kto i kiedy będzie wprowadzał zmiany na systemach informatycznych eksploatowanych w naszej firmie?
  • Kto podejmuje ostateczną decyzję – wprowadzamy zmianę czy nie?
  • Czy wiemy kogo o to zapytać?

Do czego nam proces?

Oczywiście znać odpowiedź na te pytania to połowa sukcesu. Trzeba jeszcze mieć pewność, że ilekroć nosimy się z zamiarem wprowadzenia na naszym systemie jakiejkolwiek zmiany, pytania te sobie zadamy, znajdziemy na nie odpowiedź i (co najważniejsze) do odpowiedzi tej się zastosujemy.

Wprowadzanie zmian na systemach informatycznych wzajemnie ze sobą połączonych (a więc wzajemnie od siebie zależnych) zależy jeszcze od jednego niezwykle ważnego elementu – od konsekwencji w działaniu. Sukces osiągniemy jedynie wtedy, gdy za każdym razem będziemy mieć pewność, że każdy administrator, każdego z eksploatowanych w naszej firmie systemów będzie za każdym razem postępował dokładnie według tego samego schematu. I właśnie do tego potrzebny jest nam proces.

Wiemy już zatem, że proces zarządzania zmianą to zbiór zachowań mających na celu uniknięcie negatywnych skutków, jakie wywołać może zmiana wprowadzana na jednym z eksploatowanych w firmie systemów. Teraz musimy jeszcze zadbać o odpowiednią świadomość wśród wszystkich uczestników (aktorów) tego procesu. Musimy mieć bowiem stuprocentową pewność, że administrator poddawanego zmianie systemu nie tylko wie, że powinien zadbać o interesy systemów „ościennych”. Musimy mieć również pewność, że administrator ów wie, z jakimi systemami modyfikowana aplikacja wymienia dane.

Innymi słowy: musimy nie tylko wiedzieć o co pytać, ale również kogo pytać. A do tego potrzebny nam jest już nie tylko proces, ale i baza danych zawierająca informacje o wzajemnych powiązaniach eksploatowanych przez naszą firmę systemów oraz listę osób władnych podejmować decyzje o przerwach w pracy poszczególnych systemów lub mogących ocenić i zaakceptować wynikające ze zmiany na naszym systemie ryzyko braku wydajności lub dostępności w innym powiązanym z naszym systemie.

Baza taka zgodnie ze standardami ITIL nosi nazwę CMDB = Configuration Management DataBase. To właśnie w tej bazie przechowywać powinniśmy logiczny model infrastruktury IT wraz z drzewem zależności poszczególnych elementów konfiguracji, czyli wszystko co potrzebne do oceny potencjalnego „pola rażenia” zmiany na „naszym” systemie.

Co to jest Zmiana?

Mówiąc bardzo teoretycznie – zmiana to proces przejścia z jednego zdefiniowanego stanu do innego. Bardziej precyzyjnie – zmiana to dodanie, modyfikacja lub usunięcie zatwierdzonego i utrzymywanego elementu konfiguracji. Oczywiście w tym miejscu niezbędnym jest wprowadzenie definicji elementu konfiguracji. Elementem konfiguracji w rozumieniu ITIL jest bowiem sprzęt, elementy sieci, oprogramowanie technologiczne, aplikacje, środowisko, systemy, urządzenia przenośne oraz elementy powiązane, a więc usługi oraz dokumentacja tych wszystkich wymienionych tu elementów.

Co stanowi cechę elementów konfiguracji w rozumieniu ITIL? Ich udokumentowanie na poziomie CMDB. Innymi słowy, elementem konfiguracji naszego systemu jest to, co jako taki element zdefiniujemy. Wszystko to czego w bazie konfiguracji nie ma, z dużym prawdopodobieństwem nie będzie podlegało procesowi zarządzania zmianą i procesowi zarządzania konfiguracją. Łatwo tu zauważyć pewien subtelny konflikt interesów. Im bowiem dokładniej opiszemy nasze systemy, tym skuteczniej będziemy nad nimi sprawować kontrolę. Z drugiej jednak strony patrząc, definiowanie wielu elementów konfiguracji jest uciążliwe i przysparza nam pracy w przypadku wprowadzania zmian w systemie. Oczywiście, nie należy z tym wszystkim przesadzać. Złoty środek to zarejestrowanie tylu elementów konfiguracji, aby procesy zarządzania zmianą i konfiguracją nie utrudniały nam pracy, a jedynie pozwalały na sprawowanie nad nią skutecznego nadzoru. Brzmi prosto, ale w praktyce zastosowanie tej zasady wymaga wielkiego wyczucia i doświadczenia. Co więcej – od należytego wypośrodkowania pomiędzy poziomem uporządkowania i poziomem świadomego chaosu zależy, czy budowane przez nas procesy będą pomocne czy tylko uciążliwe. Innym aspektem tych dylematów są koszty. Wszystkie prace wspomagające wprowadzenie zmiany – np. związane z inwentaryzacją środowiska i nanoszeniem do niej korekt – kosztują. Kosztuje nasz czas, a więc i pieniądze naszej firmy. Pamiętajmy zatem, że kontrola nie jest sztuką samą w sobie. Kontrola służy określonemu celowi. Jeśli koszty kontroli przewyższają koszty jej braku, lepiej dajmy sobie z tym spokój.

Ale wróćmy do teorii. Warto pamiętać, że wszystkie opisane w ITIL procesy wzajemnie się ze sobą zazębiają, a każdy z nich ma jasno i jednoznacznie określone cele. Jednym z celów procesu Zarządzania Zmianą jest minimalizacja liczby incydentów i problemów wynikłych ze źle wprowadzonych zmian. To ważne, gdyż według danych zebranych przez Gartnera, aż 2/3 wszystkich incydentów jest pochodną źle przygotowanych, nieprzemyślanych, nie przetestowanych zmian. A obsługa każdego incydentu kosztuje. Jest zatem o co walczyć.

Od czego zatem zacząć?

Od ustalenia podstawowych ról oraz zadań. Proces Zarządzania Zmianą określić powinien przede wszystkim:

  • kto i jaką zmianę może wnioskować,
  • kogo należy poinformować o zmianie,
  • kto powinien taką zmianę zaakceptować,
  • kto ma koordynować wszystkie prace do wdrożenia w środowisku produkcyjnym i odnotowania zmiany w Bazie Konfiguracji,
  • jak należy postępować w przypadkach nagłych.

Z czego wynika konieczność zmian?

Konieczność zmiany może wynikać ze zlokalizowania problemu, który – jeśli zostanie rozwiązany – może wygenerować prośbę o zmianę czyli RfC = Request for Change. W tym przypadku zmiana zainicjowana jest przez pracę procesu Zarządzania Problemem, który opracowując rozwiązanie, przekształca problem w znany błąd, jednocześnie przekazując RfC do procesu Zarządzania Zmianą. Warto pamiętać, że problem może, ale nie musi prowadzić do zmiany w systemie. Nie każde rozwiązanie problemu znajduje swój koniec na biurku programisty. Czasem rozwiązaniem problemu jest zmiana rutynowych procedur obsługi aplikacji. Niemniej jednak, jeśli problem wygenerował już RfC to oznacza ni mniej ni więcej, że konieczność zmiany przynajmniej jednego elementu konfiguracji musi przejść przez proces Zarządzania Zmianą. Można zatem z dużym prawdopodobieństwem stwierdzić, że zmiany powstają głównie jako rezultat problemów. Trzeba jednak pamiętać, że pewna liczba zmian wynika z proaktywnego poszukiwania korzyści biznesowych, takich jak redukcja kosztów, czy poprawa jakości działania systemu. Trzecim powodem powstawania konieczności wprowadzania zmian jest oczywiście rozwój. Zwiększanie się wymagań użytkowników w stosunku do funkcjonalności systemu, co musi pociągać za sobą zmiany w konfiguracji lub w kodzie systemu.

Ale na tym nie koniec. Czwartym powodem wprowadzania zmian w systemie jest nie omawiany jeszcze proces Zarządzania Pojemnością Usług (Capacity Management). Proces który dba o to, aby system nasz nie wyczerpał dostępnych mu zasobów, co w praktyce oznaczać może pogorszenie wydajności lub dostępności systemu. Czynnikami mającymi wpływ na parametry pojemnościowe systemu jest liczba jego użytkowników, wielkość danych przechowywanych i przetwarzanych przez system, no i oczywiście dynamika zmian wszystkich parametrów mających wpływ na wydajność i dostępność systemu.

Kto tym wszystkim rządzi?

Wydawałoby się, że najważniejszym decydentem w procesie Zarządzania Zmianą jest Manager zmiany (Change Manager). Jako właściciel procesu jest odpowiedzialny za ustalenie jego przebiegu i bieżący monitoring. Do niego trafiają zapotrzebowania na zmianę. Manager zmiany ocenia wpływ zmiany na usługi, ocenia koszty wprowadzenia zmiany, korzyści i ryzyka jakie pociąga za sobą implementacja, buduje uzasadnienie dla biznesu, zatwierdza potrzeby zmian do realizacji, wreszcie zarządza i koordynuje ich wdrożenie.

Prawda to, ale nie do końca. Procesem zarządzania zmianą rządzą właściciele biznesowi wszystkich poddanych procesowi systemów oraz administratorzy odpowiedzialni za poprawną tych systemów pracę. Nie jest bowiem aż tak ważne to, kto rządzi procesem. Najważniejsze jest to, kto podejmuje decyzje o wdrożeniu lub zaniechaniu wdrożenia zmiany. Proces nie działa bowiem po to, aby tylko działać. Proces ten działa po to, by działały oddane naszej opiece systemy informatyczne.

Zapamiętajmy:

Proces Zarządzania Zmianą stawia przed sobą bardzo szczytny cel – jego zadaniem jest bowiem minimalizowanie niekorzystnego wpływu zmian wprowadzanych na eksploatowanych produkcyjnie systemach informatycznych.

Proces Zarządzania Konfiguracją – po co i dlaczego?

Jak już wiemy, baza konfiguracji czyli CMDB zawiera wszystkie istotne informacje o zasobach IT i ważnych relacjach zachodzących pomiędzy nimi. Celem procesu zarządzania konfiguracją jest więc dostarczanie logicznego modelu infrastruktury informatycznej. Aby to osiągnąć, proces ten koncentruje swoje wysiłki na:

  • identyfikacji i opisaniu informacji o wszystkich zasobach znajdujących się w organizacji,
  • weryfikowaniu zapisów konfiguracji z rzeczywistym środowiskiem produkcyjnym,
  • poprawą wszelkich stwierdzonych błędów,
  • współdziałaniu z pozostałymi procesami.

Co to jest element konfiguracji?

Element konfiguracji czyli Configuration Item to składnik infrastruktury IT związany z infrastrukturą, który jest lub powinien być pod kontrolą procesu Zarządzania Konfiguracją. Elementy konfiguracji mogą znacząco różnić się złożonością, rozmiarami i typem. Zależy to bezpośrednio od wielkości opisywanego środowiska i wpływu poszczególnych elementów na procesy ITIL. Przypominam bowiem, że jest bardzo miło mieć bazę opisującą wszystko. Jest to jednak stan bardzo kosztowny – zarówno na etapie tworzenia jak i utrzymania aktualności danych bazy. Dlatego też w zależności od sytuacji, elementem konfiguracji może być zarówno duży zintegrowany system klasy ERP, czy CRM, jak również pojedyncza kość pamięci, czy macierz dyskowa.

Trochę więcej o CMDB

Configuration Management DataBase czyli CMDB, to baza danych, która zawiera wszystkie istotne szczegóły o każdym uznanym za istotny elemencie konfiguracji oraz o ważnych relacjach pomiędzy nimi. Jednym z ważnych elementów CMDB jest Konfiguracja Podstawowa (Configuration Baseline) czyli konfiguracja produktu lub systemu określona w konkretnym momencie, która obejmuje zarówno strukturę, jaki i szczegóły produktu lub systemu i umożliwia późniejszą ich odbudowę (wycofanie nieudanej zmiany).

Aby rozsądnie gromadzić dane o konfiguracji naszej infrastruktury informatycznej, warto na początek zadać sobie kilka podstawowych pytań o cel i zakres zarządzania konfiguracją. Efektem tych rozważań powinno być określenie strategii, polityki, czy zakresu procesu zarządzania infrastrukturą. Rzeczą wtórną do tych ustaleń są przepisy wykonawcze zawarte w procedurach oraz dokumentach określających role i zakresy obowiązków osób uczestniczących w procesie. Warto pamiętać o tej właśnie kolejności. Z pewnością tworzenie procedur operacyjnych jest zadaniem nieco łatwiejszym niż określanie strategii firmy w stosunku do zagadnień zarządzania konfiguracją. Istnieje zatem naturalna ciągota do ominięcia pierwszego trudnego etapy pracy i skoncentrowaniu się na drugim, znacznie łatwiejszym.

Czy zarządzanie zmianą to jedynie inwentaryzowanie zdarzeń?

Niekoniecznie. Proces zarządzania konfiguracją zawierać może również działania związane z planowaniem migracji do nowszej wersji użytkowanego systemu, akcji wymiany sprzętu na nowy lub przesunięcia używanego i słabszego sprzętu do obsługi systemów charakteryzujących się mniejszymi wymaganiami. Proces ten może również zawiadywać systemem standardów stanowisk komputerowych i kategoryzacji użytkowników, bez zdefiniowania których upgrade’y sprzętowe i softwarowe mogą przyjąć charakter koncertu życzeń.

Co więc w zasadzie chcemy osiągnąć?

W idealnie wdrożonym i działającym procesie Zarządzania Konfiguracją, w ciągu całego cyklu życia elementu infrastruktury informatycznej (a więc od zamówienia, aż po jego wycofanie z użytku), wszystkie zmiany wykonywane na objętych procesem elementach są autoryzowane, a dane CMDB aktualizowane są na bieżąco. Działania kontrolne tego procesu powinny koncentrować się na zapewnieniu, że żaden element konfiguracji nie może być dodany, zmodyfikowany, zastąpiony lub usunięty bez właściwego udokumentowania tego faktu. Raport CMDB dotyczący wybranego elementu konfiguracji powinien odzwierciedlać wszystkie obecne i historyczne dane związane z danym elementem konfiguracji w całym jego cyklu życia. Oczywiście – modyfikacja bazy wynikająca z zarejestrowanych i autoryzowanych zmian, jest tylko jednym ze źródeł wiedzy o faktycznym stanie infrastruktury informatycznej. Ponieważ – bez względu na jakość wdrożonych procesów – nie można całkowicie wyeliminować zmian przeprowadzanych poza ich wiedzą, niezbędne jest prowadzenie okresowych inwentaryzacji potwierdzających aktualność danych bazy ze stanem faktycznym losowo wybranych elementów konfiguracji. Inwentaryzacje takie wykryć powinny zarówno nieautoryzowane instalacje oprogramowania jak i nie potwierdzone dokumentami przemieszczenia sprzętu w obrębie organizacji. Choć praktyka pokazuje, że zjawisk tych nie da się wyeliminować całkowicie, warto jednak dołożyć wszelkich starań w celu ich marginalizacji.

Jak szczegółowo?

To pytanie nieco retoryczne. Nie istnieje bowiem żaden wzór, który pomógłby nam w podjęciu tej decyzji. Jednocześnie liczba elementów objętych procesem Zarządzania Konfiguracją może być czynnikiem decydującym o przydatności i funkcjonalności procesu. Często mówi się więc, że Baza Konfiguracji, to „wszystko co chcemy kontrolować”. Na przykład: CMDB może rejestrować informacje o liczbie stacji roboczych, lub je zdekomponować i rejestrować oddzielnie dane o monitorze, jednostce centralnej, klawiaturze i myszy; możemy zejść jeszcze niżej, do poziomu karty sieciowej, twardego dysku, itd. Podobnie rzecz ma się w odniesieniu do elementów oprogramowania. Istotnym czynnikiem wpływającym na podjęcie tej decyzji będzie oczywiście koszt zdobycia i aktualizacji tych danych w odniesieniu do liczby sytuacji, w których informacja ta okaże się nam potrzebna.

Co oznacza Zarządzanie Zasobami?

Zarządzanie Konfiguracją często utożsamianie jest z Zarządzaniem Zasobami (Asset Management). To błąd! Zarządzanie Zasobami nie jest procesem ITIL, jest działaniem wynikającym z uregulowań prawnych nakładających na organizację inwentaryzację majątku trwałego o określonej wartości. Co i jak rejestrujemy w tym procesie, wynika bezpośrednio z uregulowań prawnych dotyczących prowadzenia rozliczeń księgowych. Ważna jest więc tu wartość zasobu i jego amortyzacja, wreszcie obecna lokalizacja i jednostka biznesowa, która jest jej właścicielem. Oczywiście w praktyce procesy te mogą się komunikować i wymieniać pomiędzy sobą wspólny dla obu procesów zbiór informacji. Trzeba jednak pamiętać, że informacje te nie są wystarczające dla procesu Zarządzania Konfiguracją. Poprzestanie na księgowych rejestrach środków trwałych nie zapewnia bowiem z całą pewnością należytego nadzoru nad skomplikowaną materią infrastruktury informatycznej. W oparciu o te dane na pewno nie dowiemy się, z jakiego oprogramowania (w jakiej wersji) korzysta zgłaszający awarię użytkownik. Nie sprawdzimy tu również, czy ma on uprawnienia do pracy z danym systemem. Bez CMDB trudno zatem będzie nam szybko i trafnie reagować na zgłoszenia użytkowników.

Po co to wszystko?

W informatyce – jak nigdzie indziej, sprawdza się stwierdzenie, że ciągłe zmiany są jedynym stałym elementem naszego otoczenia. Stąd też tak duża potrzeba usystematyzowania zmian wprowadzanych w infrastrukturze informatycznej i rejestrowania wynikających z tego faktu zmian w jej konfiguracji. Tak więc, siłą rzeczy procesy Zarządzania Zmianą i Konfiguracją powinny rozwijać się równolegle i wzajemnie ze sobą współdziałać. Podczas gdy proces Zarządzania Zmianą ustala jak wdrażać zmiany tak, by minimalizować ryzyko wystąpienia awarii – proces Zarządzania Konfiguracją dostarcza wiedzy o tym, jakimi zasobami dysponuje infrastruktura informatyczna naszej firmy.

Na koniec o zapobieganiu zamiast leczenia

Trudno ukryć, że Proces Zarządzania Konfiguracją spełnia de facto funkcje usługowe względem innych procesów, gdyż posiadanie aktualnej informacji o zasobach IT nie jest celem samym w sobie. Jest natomiast kluczowym narzędziem wspomagającym inne procesy, a konkretnie procesy ITIL, które pozwalają nam usystematyzować i uporządkować działania komórek informatycznych.

I na koniec niepopularna i powtarzana jak mantra myśl: bez względu na ilość użytych sił i środków, żadna organizacja nie jest w stanie zagwarantować całkowitej bezawaryjności eksploatowanych systemów informatycznych. Cóż nam zatem pozostaje? Minimalizować skutki, poprzez należyte przygotowanie się do usunięcia ewentualnych awarii.

Nic nas przed tym nie uchroni, ale sporo pomysłów może nam w tym pomóc.