Czym jest CMDB?

Charakterystyka CMDB

Rozumiemy więc, jak działa CMDB, jej rolę w zarządzaniu konfiguracją oraz jak odnosi się do zarządzanie zasobami i różni się od niego. Ale jak wygląda funkcjonalność CMDB na bardziej praktycznym poziomie?

Podstawowe cechy funkcjonalne CMDB to:

Płynnie działające pulpity nawigacyjne ze wkaźnikami CI i analizami ułatwiające śledzenie stanu CI, ich relacji, wpływu zmian, wzorców prowadzących do incydentów lub problemów oraz kosztów — wyrażonych jako pieniądze i zasoby — budowania i utrzymania każdej usługi w organizacji.

Funkcje zgodności zapewniające szczegółową dokumentację i wgląd audytorom nie tylko w aktualny stan CI, ale także ich historyczne zmiany, kontrole i bilanse, incydenty, itp.

Tworzenie CI i terminowe wypełnianie ich danych, obsługiwane przez trzy różne metody: ręczne wprowadzanie, integracje (oparte na interfejsie API, SCCM) i narzędzia wykrywania, które przeprowadzają automatyczne skanowanie wszystkich adresów IP w sieci organizacji w celu skutecznego zbierania informacji o oprogramowaniu i sprzęcie gromadzenie inwentaryzacji każdego fizycznego i wirtualnego urządzenia w firmie.

Obsługa połączonych zbiorów danych, w tym normalizacji i uzgadniania CI i ich danych.

Mapowanie usług IT (zazwyczaj graficzna ilustracja relacji i zależności).

Kontrole dostępu umożliwiające przekazywanie różnych poziomów dostępu różnym osobom lub zespołom w razie potrzeby oraz śledzenie zmian z powrotem do ich źródła w przypadku pytań lub incydentów.

Korzyści z CMDB

Podstawowymi problemami rozwiązywanymi przez CMDB są odizolowane dane i nieaktualne informacje. Przed wdrożeniem CMDB, większość organizacji ma dane rozproszone po różnych systemach z różnymi właścicielami, co utrudnia zobaczenie z lotu ptaka wszystkich CI i ich współzależności, jeszcze bardziej utrudniając zrozumienie, które informacje są, a które nie są aktualne.

Uniemożliwia to zespołom zrozumienie ważnego kontekstu przy podejmowaniu decyzji, które mogą mieć wpływ na ocenę ryzyka i raportowanie, utrudniać podejmowanie decyzji, spowodować powolne rozwiązywanie problemów, i ostatecznie kosztować firmę zarówno pod względem finansowym, jak i reputacji.

Na przykład powiedzmy, że dane CI A są przechowywane w jednym dziale, a CI B w innym. Prawidłowe funkcjonowanie CI B zależy od CI A. Ale kiedy dział CI A decyduje się przenieść go do trybu offline w związku z przerwą techniczną, nie ma wglądu we wpływ, jaki wywiera na CI B.

W najlepszym wypadku może to spowodować zamieszanie między zespołami. W najgorszym, może przekształcić się w poważny incydent. A wszystkim, co jest potrzebne, aby uniknąć tego scenariusza, jest dobra CMDB.

Forrester identyfikuje trzy przypadki użycia, w których CMDB jest dziś niezwykle ważna:

Planowanie

Menedżerowie technologii potrzebują danych CMDB do planowania, zarówno na wysokim poziomie z architekturą firmy i zarządzaniem ofertą, jak i na bardziej szczegółowym poziomie z zarządzaniem zasobami i wydajnością.

Księgowość

Dział finansowy IT wymaga ewidencji aplikacji lub kodów usług w celu alokacji wyciągów rozliczeniowych i właściwego zarządzania finansami biznesowymi.

Operacje

CMDB usprawnia szereg podstawowych praktyk ITSM, w tym zarządzanie zmianami, zarządzanie incydentami, i zarządzanie problemami.

W zarządzaniu zmianami CMDB może poprawić ocenę ryzyka, przewidując, którzy użytkownicy, systemy, i inne CIS mogą mieć wpływ. W branżach regulowanych może również pomóc w przestrzeganiu przepisów, pomagając zespołom zarządzać kontrolami i zapewniać przejrzystą ścieżkę audytu.

W zarządzaniu incydentami, CMDB może pomóc zidentyfikować zmiany, które doprowadziły do incydentu i uzyskać szybsze rozwiązanie. Zapisy incydentów mogą być powiązane z ich odpowiednimi CI, pomagając zespołom śledzić incydenty w czasie wraz z zasobami, na które mają wpływ.

W zarządzaniu problemami CMDB może pomóc w analizie przyczyn źródłowych, szybciej doprowadzając zespoły do sedna problemu. Może również wspierać aktywne zarządzanie problemami, pomagając zespołom zidentyfikować zasoby wymagające aktualizacji w celu zmniejszenia kosztów usług i nieplanowanych przestojów.

Ostatecznie CMDB powinna zmniejszyć złożoność, zapobiegać błędom, zwiększyć bezpieczeństwo, i wspierać płynne działanie praktyk ITSM, takich jak zarządzanie zmianami i incydentami.

Wyzwania związane z CMDB

Statystyki branżowe mówią nam, że tylko 25% organizacji uzyskuje znaczącą wartość z inwestycji w CMDB. Tak wysoki wskaźnik niepowodzeń owiał technologię dość problematyczną reputacją.

Dobrą wiadomością jest to, że przyczyny niepowodzenia można zapobiec i dzielą się na sześć przewidywalnych kategorii:

Kultura

Jak wszystko w organizacji, kultura i zaangażowanie zespołu są jednym z najważniejszych czynników wpływających na sukces nowych technologii i procesów. W niedawnym badaniu przeprowadzonym przez Harvard Business Review93% kadry kierowniczej stwierdziło, że największym wyzwaniem w transformacji cyfrowej opartej na danych są ludzie i proces. Dotyczy to projektów CMDB.

Trafność

CMDB są często nazywane „jedynym źródłem prawdy”, co czasami może prowadzić do tego, że organizacje próbują zbić wszystkie swoje dane w jedno, nie zastanawiając się nad przypadkami użycia odpowiednimi dla ich potrzeb.

Podobnie jak w przypadku każdego repozytorium danych, CMDB powinna zawierać skoncentrowane, przydatne dane obsługujące wewnętrzne procesy, takie jak zarządzanie zmianami. Używana CMDB musi mieć jasno określony cel wartości, właściciela i sposób aktualizacji danych odzwierciedlający wszystkie zmiany.

Centralizacja

Kiedy mówimy, że CMDB jest scentralizowanym miejscem do przeglądania danych aktywów, nie oznacza to, że wszystkie dane aktywów musi pozostawać wyłącznie w CMDB. To powszechne błędne przekonanie może spowodować wiele pracy dla zespołów, które próbują przenieść wszystkie swoje dane do tego „jedynego źródła prawdy”. Najlepszą praktyką jest tutaj łączenie danych z innych narzędzi, tak aby najbardziej odpowiednie narzędzie było używane do obsługi każdego przypadku użycia.

Na przykład często bardziej sensowne jest przechowywanie danych finansowych w narzędziu IT do zarządzania finansami (ITFM) i informacji o licencji oprogramowania za pomocą narzędzia do zarządzanie zasobami oprogramowania (SAM). Dane mogą być importowane i dublowane w CMDB, nawet jeśli nie stanowi ich podstawowej pamięci masowej.

Dokładność

Wiele organizacji ma trudności z opracowaniem i utrzymaniem prawidłowej CMDB. Najczęstszymi problemami są narzędzia wykrywania działające zbyt rzadko, brak reguł automatyzacji, lub poleganie na ręcznych wpisach. Typową odpowiedzią na te wyzwania jest wykrywanie oparte na wydarzeniach, wzmacniające tradycyjne oddolne wykrywanie.

Dla nieznających tych terminów, oddolne wykrywanie ma miejsce, gdy aktywa są mapowane, zaczynając od infrastruktury i rozgałęziając się w CIS zorientowane na klienta. Wykrywanie oparte na zdarzeniach ma miejsce, gdy się dzieje coś — zdarzenie w systemie, problem itp. — powodującego komunikację między systemami. Następnie, na podstawie tego zdarzenia, system mapuje powiązane CI i ich połączenia.

Teraz nie wszystkie CI są możliwe do wykrycia. Na przykład zespół może chcieć mapować monitory w CMDB. Ponieważ monitory nie są możliwe do wykrycia przez zautomatyzowany system, należy je ręcznie wprowadzić za pomocą arkusza kalkulacyjnego (lub podobnej metody).

Kluczem do dokładności jest wykorzystanie mocy zarówno oddolnego wykrywania, jak i wykrywania opartego na zdarzeniach, aby uzyskać jak najwyraźniejszy obraz zasobów i ich połączeń.

Proces

W niektórych organizacjach panuje przekonanie, że CMDB służą do modelowania starszej infrastruktury i oprogramowania, zamiast nowego stosu chmury i infrastruktury zdefiniowanej programowo oraz hostowanych na nich nowoczesnych przepływów pracy.

Prawda jest taka, że nie powinniśmy pozwolić, aby debata na temat semantyki powstrzymywała nas od zbadania prawdziwej wartości śledzenia naszych CI — starszych i nowszych — w narzędziu dającym nam kompleksowy obraz naszych ekosystemów technicznych.

narzędzia

Wybór odpowiedniego narzędzia jest najważniejszy, aby uniknąć wspomnianych powyżej niefortunnych statystyk niepowodzeń. Niektóre narzędzia CMDB to niewiele więcej niż repozytoria zasobów — struktury danych naprawione w starszej infrastrukturze fizycznej i narzędziach do wykrywania, które powoli reagują na wszelkie zmiany. Aby odnieść sukces dzięki CMDB, potrzebne jest takie, który uwzględnia nowe typy aktywów i jest zdolne do szybkiej zmiany.

Wybór, czym zarządzać w CMDB

Nie ma jednej właściwej dla wszystkich odpowiedzi, którymi CI należy zarządzać w swojej CMDB. Przypadki użycia i cele każdej organizacji powinny określać poziom szerokości i głębokości, który ma sens dla ich konfiguracji CMDB. Ogólnie rzecz biorąc, sensowne jest rozpoczęcie wysokiego poziomu i prawidłowe korzystanie z usług, a następnie zastosowanie podejścia szerszego lub głębszego tylko tam, gdzie jest to potrzebne, aby osiągnąć swoje cele organizacyjne.

Uwzględniając to, CI mogą być szeroko pogrupowane jako obiekty techniczne lub nietechniczne.

Obiekty techniczne obejmują usługi biznesowe, usługi techniczne, aplikacje, oprogramowanie, bazy danych, kontenery, maszyny wirtualne, systemy operacyjne, sprzęt, sieci, porty itp.

Obiekty nietechniczne mogą być również modelowane w CMDB, jeśli mają być reprezentowane jako zależne lub znajdujące się pod wpływem innych zasobów w mapowaniu usług IT. Obiekty nietechniczne mogą obejmować użytkowników, klientów, organizacje, lokalizacje, umowy serwisowe, dokumenty itp.

Ponadto przy projektowaniu modelu CMDB powinny być brane pod uwagę usługi w chmurze. Obie oferty SaaS (np. aplikacje Google, Dropbox, Salesforce itp.) i oferty IaaS (np. DigitalOcean, Linode, Rackspace, Amazon Web Services itp.) mogą być w razie potrzeby reprezentowane jako CI.