Integracja procesów zarządzania zmianą i konfiguracją
Około 80% przerw w świadczeniu usług o krytycznym znaczeniu jest związanych z niewystarczającą kontrolą procesów zmian, w tym z nieprawidłową oceną ich wpływu na działalność przedsiębiorstwa. Tak wnioski płyną z danych raportów Gartnera.
Ryzyko zakłóceń w świadczeniu krytycznych dla biznesu usług IT, powstałych wskutek złej oceny ich wpływu na działania podejmowane przez firmę, można skutecznie minimalizować. Narzędziem służącym realizacji tego celu może być integracja procesów zarządzania zmianą i konfiguracją. W praktyce sprowadza się to do zapewnienia właściwego przepływu kluczowych informacji pomiędzy tymi procesami.
Zagadnienie integracji procesów zarządzania zmianą oraz konfiguracją (upraszczając na potrzeby niniejszego opracowania zagadnienie zarządzania konfiguracją jedynie do aspektu zarządzania elementami konfiguracji w CMDB), można byłoby ograniczyć do prostego założenia, iż każda zmiana stanu infrastruktury IT w organizacji, powinna znaleźć swoje odzwierciedlenie w bazie konfiguracji (CMDB), aby utrzymać jej aktualność. Czy jednak takie stwierdzenie wyczerpuje zagadnienie relacji pomiędzy dwoma analizowanymi procesami? Wydaje się, że nie. Diabeł, jak zwykle, tkwi w szczegółach… Co zatem wydaje się tu być ważne?
Analizując istotne aspekty integracji procesów zarządzania zmianą oraz konfiguracją, należy zastanowić się, jakich danych dostarczają sobie nawzajem analizowane procesy.
Po pierwsze zatem, aby przygotować i zaimplementować zmianę dowolnego fragmentu infrastruktury IT (jednego bądź wielu elementów konfiguracji), wymagana jest na każdym etapie realizacji tego procesu, aktualizowana na bieżąco wiedza na temat elementów konfiguracji, zaangażowanych w sposób bezpośredni bądź pośredni (co wynika z mapy relacji, tworzonej przez CMDB) w realizowany proces. Innymi słowy, bez przeprowadzenia analizy oraz znajomości relacji i sposobu oddziaływania na siebie poszczególnych elementów konfiguracji zaangażowanych w proces, co jest możliwe dzięki wykorzystaniu bazy CMDB, implementacja zmian w infrastrukturze IT, obarczona jest ryzykiem spowodowania większych szkód, niż oczekiwane korzyści z wdrażanej zmiany. Dokonywanie zmian w infrastrukturze IT, bez możliwości uprzedniego przeprowadzenia analizy skutków tej zmiany na otoczenie, w którym jest dokonywana, staje się zadaniem godnym wyczucia doświadczonego sapera. Aby nie być zostać obarczonym odpowiedzialnością za własne lub cudze błędy, warto poświęcić nieco więcej uwagi integracji procesów zarządzania zmianą oraz konfiguracją.
Po drugie. Po prawidłowym zaimplementowaniu zmiany wymagane jest niezwłoczne zaktualizowanie bazy konfiguracji. Co w praktyce oznacza „niezwłocznie”? Zależy to od kilku czynników, w tym między innymi od przyjętego sposobu aktualizacji zasobu bazy CMDB. Jeżeli proces zarządzania konfiguracją zakłada manualną, wykonywaną w sposób nieautomatyczny, aktualizację zasobu bazy CMDB w wyniku dokonania zmiany w infrastrukturze IT, bezwładność tego procesu zależeć może w dużej mierze od liczby dokonywanych zmian w środowisku. Z kolei przy automatycznej aktualizacji zasobu bazy konfiguracji istotne jest, jak często jest ona dokonywana. Skanowanie środowiska można uruchamiać nawet kilka razy w ciągu doby, jednak jest to zazwyczaj proces dość mocno obciążający zarówno infrastrukturę sieciową jak i same maszyny. W praktyce wykonywany jest on zazwyczaj poza okresem „produkcyjnym”.
Po trzecie. Na etapie audytowania zmian pod kątem poszukiwania tych, dokonanych bez wymaganej autoryzacji, jeśli aktualizacja zasobu CMDB dokonywana była w sposób manualny (odwzorowywała wyłącznie „legalne” zmiany), uruchomienie automatycznego skanowania środowiska, pozwala poprzez porównanie stanu bazy CMDB aktualizowanej manualnie ze stanem po dokonaniu automatycznego skanowania, na wskazanie zmian dokonanych bez autoryzacji.
Po czwarte. Opisane do tej pory przypadki, można powiedzieć, są proste, nie wymagają dodatkowego komentarza. Nie uwzględniają jednak bardzo często występującej sytuacji, gdy mamy do zrealizowania kilka zmian równolegle, „wykorzystując” te same elementy konfiguracji. Wówczas, o kolejności realizacji zmian decyduje ich priorytet. Analiza historii dokonanych zmian, a także spójna wizja zmian planowanych w przyszłości, co jest możliwe m.in. dzięki wykorzystaniu bazy CMDB, pozwalają na właściwe ustalenie priorytetów zmian. Oznacza to możliwość uniknięcia takich zjawisk, jak chociażby niepotrzebne dublowanie zmian tych samych elementów konfiguracji, wynikające z braku dostatecznej wiedzy nt. wpływu dokonywanych zmian na środowisko, którego dotyczą. Konsekwencja takiego działania może być wzrost kosztów i spadek efektywność działań.
Powołane przykłady wskazują jedynie na kilka ważnych punktów styku analizowanych procesów. Pokazują przy tym, jak ważny jest właściwy przepływ informacji pomiędzy tymi procesami oraz jakie konsekwencje mogą wynikać z sytuacji, gdy ten łańcuch wymiany danych zostanie zerwany bądź zachwiany.
Piotr Konieczny – Kierownik Projektu, Asseco Business Solutions