Baza danych zarządzania konfiguracją

Element konfiguracji (CI) to dowolny komponent, którym trzeba zarządzać, aby dostarczyć usługę. Może to być serwer, stacja robocza, przełącznik sieciowy, aplikacja, schemat bazy danych, licencja, umowa albo dokumentacja opisująca, jak to wszystko się łączy. Każdy CI ma atrybuty: właściciela, lokalizację, wersję, numer seryjny i status cyklu życia. W większości rozwiązań przechowuje też historię swoich stanów w czasie.

Cechą, która wyróżnia CMDB, jest to, że relacje mają taką samą wagę jak same elementy. Rekord CI mówi, czym jest komponent. Relacja mówi, że aplikacja płacowa działa na konkretnym klastrze, klaster zależy od macierzy dyskowej, a oddział łączy się przez określony router. Razem tworzą graf zależności, który odpowiada na pytania, na które płaska lista nie odpowie: jeśli to urządzenie ulegnie awarii, które usługi się zatrzymają i kto zostanie dotknięty?

W zarządzaniu usługami IT CMDB jest punktem odniesienia, do którego inne procesy zapisują dane i z którego je odczytują. Zarządzanie incydentami wiąże każdy incydent z zaangażowanymi CI, co przyspiesza triaż i pokazuje powtarzające się awarie tego samego komponentu. Zarządzanie problemami analizuje te skupiska, aby znaleźć przyczyny źródłowe. Najważniejszym źródłem zapisu jest zarządzanie zmianami: zatwierdzona zmiana rejestruje, które CI dotknie, a CMDB powinna odzwierciedlać nowy stan po jej zakończeniu.

Graf zależności zamienia rekordy w decyzje. Przed zatwierdzeniem zmiany można oszacować jej zasięg, idąc od dotkniętych CI wzdłuż relacji. Po incydencie ten sam przegląd pokazuje, co sprawdzić pod kątem skutków ubocznych. CMDB używana wyłącznie podczas audytów daje tylko ułamek tej wartości.

Oba narzędzia są powiązane, ale odpowiadają na różne pytania. Inwentaryzacja zasobów, kluczowy element zarządzania aktywami IT (ITAM), pokazuje, co organizacja posiada, gdzie znajduje się zasób i kto za niego odpowiada. Jej główni odbiorcy to finanse, zakupy i administracja obiektów. CMDB pokazuje, jak komponenty są ze sobą powiązane i co dzieje się po zmianie jednego z nich. Korzystają z niej zespoły zarządzania incydentami, problemami i zmianami.

W praktyce granica jest płynna. Wiele organizacji zaczyna od prostego spisu zasobów i dodaje relacje, gdy procesy zarządzania usługami dojrzewają. Prosty test: repozytorium, w którym nic nie łączy się z niczym innym, jest inwentaryzacją z dodatkowymi polami, bez względu na nazwę.

Większość CMDB łączy automatyczne wykrywanie z ręcznym prowadzeniem rekordów. Wykrywanie opiera się na agentach, skanowaniu sieci oraz integracjach z platformami chmurowymi i katalogowymi. Znajduje to, co faktycznie istnieje, i wychwytuje rozbieżności między zapisanym a rzeczywistym stanem. Umowy, definicje usług i inne elementy, których nie da się przeskanować, wprowadza się i utrzymuje ręcznie.

Gdy kilka narzędzi przechowuje każde część prawdy, CMDB je łączy lub uzgadnia. Dla każdego typu atrybutu wyznacza się jedno źródło autorytatywne, a konflikty rozstrzyga reguła, a nie dyskusja. Dokładność jest wynikiem procesu, a nie jednorazowego załadowania danych. Bez wyznaczonego właściciela szybko się pogarsza.

W Anexet Inventory karta stacji roboczej zestawia urządzenia i zainstalowane aplikacje wraz z typem urządzenia, producentem, wersją i datą instalacji. Takie rekordy są surowcem, z którego CMDB buduje swoje elementy konfiguracji.

1 / 2

• 
• 

Wzorzec porażki jest znany. Zakres początkowy obejmuje wszystko naraz, więc projekt tonie w pracach nad jakością danych, zanim cokolwiek dostarczy. Rekordy są aktualizowane tylko wtedy, gdy ktoś o tym pamięta. Z czasem baza przestaje odpowiadać rzeczywistości i ludzie przestają jej ufać. Wtedy jest technicznie żywa, ale praktycznie martwa. Poniższe praktyki odróżniają wdrożenia, które przetrwają.

CMDB to dane referencyjne, a nie kolektor. Rzadko sama obserwuje środowisko. Zamiast tego agreguje to, co zgłaszają narzędzia wykrywania, monitorowania i zarządzania. W zamian wzbogaca te narzędzia. Alerty monitoringu zyskują kontekst: czym jest dany host i której usłudze służy. Dochodzenia bezpieczeństwa zaczynają się od znanej mapy tego, co powinno istnieć. Planowanie odtwarzania wie, które komponenty przywrócić i w jakiej kolejności.

Jej ograniczenia wynikają z tej samej konstrukcji. CMDB nie wykrywa włamań, nie kontroluje urządzeń i nie zastępuje widoczności punktów końcowych. Mówi organizacji, jak powinno wyglądać jej środowisko, dzięki czemu inne mechanizmy kontroli mogą zinterpretować to, co widzą. Mechanizmy takie jak Data Loss Prevention działają tam, gdzie dane faktycznie się przemieszczają, co pokazuje tabela.

Zacznij od usług, których awaria kosztowałaby najwięcej, i zamodeluj komponenty, od których zależą. Utrzymanie modelu blisko rzeczywistości to podstawowa dyscyplina zarządzania konfiguracją, dlatego rozszerzaj zakres dopiero po zaliczeniu audytu dokładności.