Jak wybrać CMDB i utrzymać wiarygodną wiedzę o środowisku IT

Baza konfiguracji może zawierać wiele rekordów, a mimo to nie pomagać podczas awarii lub planowanej zmiany. Dzieje się tak, gdy dane są nieaktualne, relacje niejasne, a odpowiedzialność za ich sprawdzanie pozostaje nieustalona. Wybór oprogramowania CMDB warto więc powiązać z planem utrzymania informacji, którym zespół będzie ufał. Porównanie rozwiązań powinno pokazać zarówno sposób opisania środowiska, jak i pracę potrzebną do zachowania jego aktualnego obrazu.

Jaką wiedzę powinna dostarczać baza konfiguracji

CMDB, czyli baza danych zarządzania konfiguracją, gromadzi informacje o elementach środowiska IT oraz ich relacjach. Jej przydatność wynika z możliwości odniesienia tych informacji do konkretnej usługi i decyzji operacyjnej. Zanim firma zacznie porównywać produkty, powinna wskazać pytania, na które zespół potrzebuje odpowiedzi. Może chodzić o ustalenie właściciela usługi, ocenę zakresu planowanej zmiany albo sprawdzenie, które komponenty należy uwzględnić w analizie awarii.

Rejestr wyposażenia i baza konfiguracji mogą wykorzystywać część tych samych informacji, ale służyć innym zadaniom. Wiedza o tym, kto użytkuje komputer, przydaje się przy wydawaniu sprzętu. Przy analizie działania aplikacji ważniejsze mogą być powiązania z bazą danych, serwerem lub usługą uwierzytelniania. Warto ustalić, jakie informacje firma już posiada, a jakie musi dopiero opisać. Samo wprowadzenie listy urządzeń nie tworzy jeszcze wiarygodnej mapy zależności.

Na początek wybierz jedną usługę o czytelnym zakresie. Może to być wewnętrzna aplikacja wykorzystywana przez określony dział. Wspólnie z osobami ją utrzymującymi opisz elementy potrzebne do działania i ustal, które zależności są potwierdzone. Oznacz miejsca wymagające sprawdzenia. Ten niewielki model pozwoli porównywać narzędzia na konkretnym przykładzie, zamiast budować szczegółowy opis całego środowiska przed ustaleniem zasad, które mają nim kierować.

Relacje powinny mieć jednoznaczne znaczenie. Powiązanie opisane ogólnie jako „związane z” może być za mało precyzyjne, aby ocenić skutki wyłączenia komponentu. Uzgodnij nazwy relacji oraz sposób ich interpretowania przez zespół. Następnie poproś inną osobę o wyjaśnienie modelu bez pomocy autora. Jeśli uczestnicy rozumieją zależności inaczej, problem dotyczy również zasad opisu danych i nie zostanie rozwiązany wyłącznie przez atrakcyjniejszy widok graficzny.

Określ granice wiedzy o usługach zewnętrznych. Firma może znać dostawcę i punkt kontaktu, nie mając dostępu do szczegółów jego infrastruktury. W takim przypadku warto opisać zależność na poziomie przydatnym do własnej obsługi. Tworzenie domniemanych komponentów mogłoby wprowadzać w błąd podczas analizy. Baza powinna pomagać rozpoznawać zarówno znane powiązania, jak i obszary, w których przed decyzją potrzebne jest dodatkowe potwierdzenie.

Jak oceniać system przez jakość danych i obsługę zmian

Publikowany w serwisie ITManager ranking systemów CMDB ułatwia rozpoznanie produktów do dalszego porównania. Opisy funkcji warto odnieść do przygotowanego modelu usługi oraz sposobu aktualizacji informacji w firmie. Sama możliwość utworzenia wielu typów rekordów nie przesądza o użyteczności rozwiązania. Istotne jest również to, czy zespół potrafi odnaleźć właściwy element, zrozumieć jego powiązania i ustalić, na ile aktualny jest dostępny opis.

Dostawcą platformy OXARI jest Infonet Projekt. Opisany na stronie ITManager moduł CMDB umożliwia definiowanie własnych typów elementów konfiguracji, modelowanie relacji i powiązanie danych z ServiceDesk. Takie rozwiązanie można uwzględnić przy wyborze narzędzia łączącego wiedzę o środowisku z obsługą zgłoszeń. W ocenie warto wykorzystać własny model usługi, aby sprawdzić znaczenie powiązań oraz zakres pracy potrzebnej do ich późniejszego utrzymania.

Sprawdzian importu powinien obejmować błędy spotykane w rzeczywistych źródłach. Przygotuj próbkę z powtórzonym identyfikatorem, brakującym właścicielem i dwiema różnymi nazwami tego samego elementu. Poproś o pokazanie, jak użytkownik rozpoznaje konflikt oraz jak go rozwiązuje. Wynik pozwoli ocenić, czy organizacja może kontrolować jakość informacji, zamiast bezkrytycznie przyjmować każdą kolejną aktualizację. Poprawnie zakończony import nie oznacza, że powstałe rekordy opisują środowisko bez sprzeczności.

Dla ważnych danych ustal źródło wiążące. Informacja techniczna może pochodzić z narzędzia zbierającego konfigurację, a właściciel usługi z ustaleń organizacyjnych. Gdy wartości się różnią, potrzebna jest reguła rozstrzygania i osoba odpowiedzialna za decyzję. Sprawdź, czy da się odróżnić informację potwierdzoną od wymagającej przeglądu. Pytanie o pochodzenie danych powinno być częścią wyboru narzędzia, ponieważ od odpowiedzi zależy późniejsze zaufanie do bazy.

Przetestuj również zastąpienie komponentu nowym. Ustal, jak aktualizowane są relacje, gdzie pozostaje historia i w jaki sposób wycofany element przestaje być traktowany jako czynny. Zespół powinien móc wyjaśnić zarówno obecny stan, jak i ważne wcześniejsze zdarzenie. Nieaktualne powiązanie może zaburzać analizę nawet wtedy, gdy sam rekord urządzenia zawiera poprawne parametry. Dlatego obsługa zmiany relacji jest równie istotna jak edycja pojedynczego pola.

Widok graficzny warto sprawdzić przy konkretnym zadaniu. Poproś uczestnika o wskazanie usług, które należy uwzględnić przed zmianą wybranego elementu, oraz osób odpowiedzialnych za ich potwierdzenie. Następnie wykonaj tę samą próbę z widokiem tabelarycznym lub kartą rekordu. Różne formy prezentacji mogą pomagać w innych czynnościach. Oceniaj, czy wspierają poprawne odczytanie modelu, a nie wyłącznie wrażenie, jakie robi rozbudowana mapa na prezentacji.

Jak utrzymać użyteczność CMDB po uruchomieniu

Pilotaż powinien obejmować wykorzystanie bazy w rzeczywistej pracy. Przeanalizuj planowaną zmianę i sprawdź, czy dane pomagają ustalić zakres konsultacji, testów oraz możliwych następstw. Później odtwórz sytuację z objawem awarii i poproś zespół o wyznaczenie kierunku sprawdzania. Baza dostarcza kontekstu, natomiast nie zastępuje technicznej diagnozy ani oceny ryzyka. Uczestnicy muszą wiedzieć, które zależności są potwierdzone, a które wymagają dodatkowego ustalenia.

Zapisuj braki ujawnione podczas prób. Może okazać się, że komponent ma poprawne parametry, lecz nie wskazano osoby odpowiedzialnej albo pominięto zależność ważną dla usługi. Takie obserwacje tworzą konkretny plan doskonalenia. Rozbudowę modelu warto prowadzić przez potrzeby wynikające z obsługi, zamiast dodawać kolejne kategorie danych bez wskazania zastosowania. Ograniczony zakres dobrze utrzymywanych informacji może być bardziej pomocny niż szeroka baza, której nikt regularnie nie weryfikuje.

Wyznacz odpowiedzialność za model oraz za poszczególne dane. Zmiana nazewnictwa relacji lub typów elementów powinna podlegać uzgodnionym zasadom, natomiast zespoły utrzymujące usługi potrzebują jasnego obowiązku aktualizacji swojej części. Częstotliwość przeglądu warto dopasować do znaczenia usługi i tempa zmian. W pilotażu ustal również, ile czasu wymaga aktualizacja typowego przypadku. Bez tej wiedzy trudno realistycznie zaplanować utrzymanie po zakończeniu wdrożenia.

Przy porównywaniu ofert uwzględnij przygotowanie danych, konfigurację, integracje i późniejszą pracę zespołu. Sprawdź eksport rekordów oraz relacji, aby wiedzieć, jakie informacje firma może pobrać na potrzeby dalszych analiz lub zmiany rozwiązania. Wybierz produkt, dla którego próby potwierdzają użyteczność modelu i możliwość jego utrzymania. Tak oceniona CMDB może stać się wspólnym punktem odniesienia podczas pracy nad usługami, ponieważ zespół rozumie zarówno zawartość bazy, jak i zasady jej aktualizacji.